search

riscv / riscv-isa-manual

RISC-V Instruction Set Manual
https://riscv.org/
Creative Commons Attribution 4.0 International
3.61k stars 626 forks source link

Specify mtval for unaligned CMOs #1263

Open Timmmm opened 6 months ago

Timmmm commented 6 months ago

If you do cbo.zero with an unaligned address, it aligns the address. But if there's a memory exception what value should be written to mtval? IMO it should be the aligned address, but it isn't specified.

gfavor commented 6 months ago

This issue is redundant with issue riscv/riscv-isa-manual#1317 (outstanding but to be resolved soon as part of the adoc conversion and integration process). The two salient posts are: https://github.com/riscvarchive/riscv-CMOs/issues/55#issuecomment-1585188040 and https://github.com/riscvarchive/riscv-CMOs/issues/55#issuecomment-1585196234.

dkruckemyer-ventana commented 4 months ago

Wasn't #1317 resolved with PR #1319?

Timmmm commented 4 months ago

Doesn't seems like it to me because this is as clear as mud!

When a page fault, guest-page fault, or access fault exception is taken, the relevant *tval CSR is written with the faulting effective address (i.e. the same faulting address value as for other causes of these exceptions).

As far as I can see the RISC-V spec doesn't even define what "effective address" means anywhere; it just assumes you already know.

dkruckemyer-ventana commented 4 months ago

"The effective address is obtained by adding register rs1 to the sign-extended 12-bit offset."

From Section 2.6 of the base spec.

dkruckemyer-ventana commented 4 months ago

Other ways of computing effective address are also specified, e.g. for vector loads and stores, and the CMO spec defines how the effective address is calculated in each of the instruction definitions.

gfavor commented 4 months ago

It seems like this issue is ready to be resolved and closed?

Timmmm commented 4 months ago

Other ways of computing effective address are also specified

I really meant what is an effective address, not how to calculate it. Maybe that's obvious to old hands but it wasn't to me, and I suspect other people who are learning RISC-V before other ISAs. I looked it up and it seems to come from x86 which does define it, but the RISC-V spec shouldn't assume familiarity with x86!

It seems like this issue is ready to be resolved and closed?

I don't think this is clearly specified. We have:

When a page fault, guest-page fault, or access fault exception is taken, the relevant *tval CSR is written with the faulting effective address (i.e. the same faulting address value as for other causes of these exceptions).

and

A cbo.zero instruction performs stores of zeros to the full set of bytes corresponding to the cache block whose effective address is the base address specified in rs1.

But it still doesn't really say what happens if rs1 is not aligned, unless I missed it. Is the effective address the aligned or unaligned value?

allenjbaum commented 4 months ago

I read that as the unaligned address, i.e. the contents of the base register. The base of affected cache block is computed by "rounding" that address down so it has cache-block modularity

On Tue, May 28, 2024 at 11:11 PM Tim Hutt @.***> wrote:

Other ways of computing effective address are also specified

I really meant what is an effective address, not how to calculate it. Maybe that's obvious to old hands but it wasn't to me, and I suspect other people who are learning RISC-V before other ISAs. I looked it up and it seems to come from x86 which does define it https://stackoverflow.com/a/36704482/265521, but the RISC-V spec shouldn't assume familiarity with x86!

It seems like this issue is ready to be resolved and closed?

I don't think this is clearly specified. We have:

When a page fault, guest-page fault, or access fault exception is taken, the relevant *tval CSR is written with the faulting effective address (i.e. the same faulting address value as for other causes of these exceptions).

and

A cbo.zero instruction performs stores of zeros to the full set of bytes corresponding to the cache block whose effective address is the base address specified in rs1.

But it still doesn't really say what happens if rs1 is not aligned, unless I missed it. Is the effective address the aligned or unaligned value?

— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1263#issuecomment-2136589775, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTWLABCQVKD2FGQIK3ZEVWQZAVCNFSM6AAAAABEYLH3ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGU4DSNZXGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Timmmm commented 4 months ago

I think we can close this when the spec is clear enough that Allen doesn't need to say "I read that as..."!

I read the discussion on #1317 and I'm honestly still not sure what the intention is:

The original intent (which apparently was not captured in the spec) was that the effective address would be captured in *tval, just like a normal load or store.

But nobody says whether they are talking about the effective address of the instruction (unaligned) or the effective address of the cache block (aligned)!

I think Allen is right, based on this comment:

IMO, there's nothing terribly problematic with either reporting the base address of the cache line or reporting the effective address.

Also nobody addressed this comment:

One can also note that the standard meaning of "the faulting address" in the RV Priv arch is a specific address (i.e. the effective address except when misalignment cases come into the picture), and not just any address covered by the access (or part of the overall access) being faulted.

I'll make a PR with some clearer wording, based on the assumption that Allen is correct.

aswaterman commented 4 months ago

Are we not overcomplicating this? Can't we just change https://github.com/riscv/riscv-isa-manual/pull/1319/files#diff-d075eb7ab95af33cf1b35667fab40ee537a80e733a614458b0b068cdef85f449R384

to say "i.e. the address specified by rs1"?

Timmmm commented 4 months ago

Yeah I'll do that.

Timmmm commented 4 months ago

Although I suppose it is possible that the faulting address isn't the address specified by rs1, since the store can be decomposed into any number of memory operations, and PMPs could disallow access to part of the cache block theoretically?

aswaterman commented 4 months ago

I don't think that applies to CBOs in practice. And in any case, that is not relevant to the definition of "effective address".