*TVAL should capture the effective address on an exception

[dkruckemyer-ventana]

This is a clarification that needs to be added based on the following email thread:

https://lists.riscv.org/g/tech-privileged/topic/94419723

(I keep forgetting to update the spec, so capturing this change for posterity)

[JamesKenneyImperas]

I'm not sure that the clarification proposed here is the right thing to do. The question being asked is:

When a breakpoint, access-fault, or page-fault exception occur on a CMO instruction (cbo.clean, cbo.flush, cbo.inval, cbo.zero), is the full virtual address provided in the register identified by rs1 saved into xtval or can a block-size aligned version of the VA be used?

The response (in the email thread) 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.

I will add a clarification to the extension specification.

Normal loads and stores do not necessarily capture the given effective address in the tval register. For example, if misaligned addresses are supported and a misaligned access is made that straddles page boundaries where the first page allows access but the second does not then the address saved in tval will be the base address of the second page, not the input effective address. Specifically, the Privileged Specification says this:

If mtval is written with a nonzero value when a misaligned load or store causes an access-fault or page-fault exception, then mtval will contain the virtual address of the portion of the access that caused the fault.

To me it feels that it would be more consistent to report the lowest failing address in tval, which would be the block-size aligned VA.

I'm also wondering about the interaction of this feature with PMP, which allows fine-grained protections to be specified. For example, suppose that PMP regions are configured so that an entire cache line has access allowed by a low-priority region except for four bytes in the middle that have access denied by a high-priority region. What happens if cbo.zero is used on that line? The PMP specification says:

The matching PMP entry must match all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.

Does this mean that the cbo.zero must fail without updating state if the line which it writes is not contained in a single PMP entry?

Thanks.

[gfavor]

Note that the misaligned case that can occur for loads and stores, cannot occur for any of the CMO instructions. What David described applies for aligned ld/st's and for the first part of misaligned ld/st's, and hence is appropriate also for CMOs.

Regarding the PMP question, Yes. Just like for a ld/st that encountered the same situation. Further, there are no defined architecture semantics that allow for only partially executing RV instructions (until one talks about vector ld/st's).

Greg

On Thu, Apr 13, 2023, 4:28 PM JamesKenneyImperas @.***> wrote:

I'm not sure that the clarification proposed here is the right thing to do. The question being asked is:

When a breakpoint, access-fault, or page-fault exception occur on a CMO instruction (cbo.clean, cbo.flush, cbo.inval, cbo.zero), is the full virtual address provided in the register identified by rs1 saved into xtval or can a block-size aligned version of the VA be used?

The response (in the email thread) 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.

I will add a clarification to the extension specification.

Normal loads and stores do not necessarily capture the given effective address in the tval register. For example, if misaligned addresses are supported and a misaligned access is made that straddles page boundaries where the first page allows access but the second does not then the address saved in tval will be the base address of the second page, not the input effective address. Specifically, the Privileged Specification says this:

If mtval is written with a nonzero value when a misaligned load or store causes an access-fault or page-fault exception, then mtval will contain the virtual address of the portion of the access that caused the fault.

To me it feels that it would be more consistent to report the lowest failing address in tval, which would be the block-size aligned VA.

I'm also wondering about the interaction of this feature with PMP, which allows fine-grained protections to be specified. For example, suppose that PMP regions are configured so that an entire cache line has access allowed by a low-priority region except for four bytes in the middle that have access denied by a high-priority region. What happens if cbo.zero is used on that line? The PMP specification says:

The matching PMP entry must match all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.

Does this mean that the cbo.zero must fail without updating state if the line which it writes is not contained in a single PMP entry?

Thanks.

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

[JamesKenneyImperas]

Ok. If Hypervisor mode is implemented and the CMO ends up causing a stage 2 fault, presumably the address reported there has the same block offset as well.

Thanks.

[YenHaoChen]

Hello,

I want to understand the desired tval when a cache-block management instruction raises an exception. Should the tval be the original address or the lowest effecitve virtual address on the cache block boundary?

https://github.com/riscv-software-src/riscv-isa-sim/pull/1376

Best regards, YenHaoChen

[aswaterman]

IMO, there's nothing terribly problematic with either reporting the base address of the cache line or reporting the effective address. Since this was omitted from the ratified spec, is it not reasonable to allow either behavior (or really any address on the faulting cache line)?

@gfavor is it possible that "What David described applies for aligned ld/st's" is standard practice rather than something mandated? Just wondering if we need a clarification there. I suppose the spec says tval contains "the" faulting address, not "a" faulting address, which is justification enough.

[gfavor]

As mentioned above (https://github.com/riscv/riscv-isa-manual/issues/1317):

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.

I will add a clarification to the extension specification.

So the intent (not just a suggestion of common practice) is that the effective address is captured - the same as for other exceptions (modulo misalignment cases which don't apply to cbo's).

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.

[aswaterman]

Yeah, that works for me.

[gfavor]

And finally tieing back to the beginning of this thread (to net out a bunch of this thread), it would be helpful to readers to add a non-normative comment about the recorded tval address simply and always being the effective address - the same as what is captured in tval for loads and stores (barring misalignment cases - which don't exist for cbo's).

[aswaterman]

Yup. That would clear things up in an uncontroversial fashion.

[gfavor]

@wmat, almost at the end of the "Page Fault, Guest-Page Fault, and Access Fault Exceptions" section (before the non-normative note at the end), add the following one sentence paragraph:

When a page fault, guest-page fault, or access fault exception is taken, the relevant *tval CSR is written with the faulting effective address.

Following this should be the following as a non-normative note:

The recorded tval address is simply and always the same effective address as would be captured in tval for loads and stores.