This issue is redundant with issue #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.

Wasn't #1317 resolved with PR #1319?

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.

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

From Section 2.6 of the base spec.

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.

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

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?

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.

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"?

Yeah I'll do that.

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?

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