I wrote that the list is not necessarily complete because I was
thinking of extensions such as Smstateen and the AIA (Advanced
Interrupt Architecture), plus the constant risk of additions elsewhere
within the Privileged ISA itself.  But if it will make people more
comfortable, we can drop the caution about the list's possible
incompleteness, add a more conscious caveat statement that extensions
may add to the list, and rely on everyone working to keep this list
always complete and up-to-date in the Privileged ISA document.

On Wed, Aug 11, 2021 at 1:55 PM John Hauser <jh.riscv@...> wrote:

I wrote that the list is not necessarily complete because I was
thinking of extensions such as Smstateen and the AIA (Advanced
Interrupt Architecture), plus the constant risk of additions elsewhere
within the Privileged ISA itself.  But if it will make people more
comfortable, we can drop the caution about the list's possible
incompleteness, add a more conscious caveat statement that extensions
may add to the list, and rely on everyone working to keep this list
always complete and up-to-date in the Privileged ISA document.

Myself, when I read the text in question, I find the "list may be incomplete" to be nebulous and unbounded in what that could mean.  Whereas a statement that the list will grow over time (e.g. due to new arch extensions, but not limited to that) provides some explanation of how and why the list can change over time.

With both the existing and alternative text the need for everyone to keep the list complete and up-to-date exists.  If anything, mentioning "due to new arch extensions"

clues people in to what they have to worry about in maintaining the list.

Greg

On Wed, Aug 11, 2021 at 1:55 PM John Hauser <jh.riscv@...> wrote:

I wrote that the list is not necessarily complete because I was
thinking of extensions such as Smstateen and the AIA (Advanced
Interrupt Architecture), plus the constant risk of additions elsewhere
within the Privileged ISA itself.  But if it will make people more
comfortable, we can drop the caution about the list's possible
incompleteness, add a more conscious caveat statement that extensions
may add to the list, and rely on everyone working to keep this list
always complete and up-to-date in the Privileged ISA document.

Myself, when I read the text in question, I find the "list may be incomplete" to be nebulous and unbounded in what that could mean.  Whereas a statement that the list will grow over time (e.g. due to new arch extensions, but not limited to that) provides some explanation of how and why the list can change over time.

With both the existing and alternative text the need for everyone to keep the list complete and up-to-date exists.  If anything, mentioning "due to new arch extensions" clues people in to what they have to worry about in maintaining the list.

Paul Donahue wrote:
> Table 3.7 of the privileged spec lists the synchronous exception
> priorities. The hypervisor chapter adds guest page faults and virtual
> instruction exceptions but I don't see where it states how they are
> prioritized (either in a table or in prose). I have intuition about the
> priorities but it should be explicit.

I suggest adding a GitHub issue or two here:
https://github.com/riscv/riscv-isa-manual

For virtual instruction exceptions, would anybody assume their priority
is anything other than the same as illegal instruction exceptions?

> The explicitly incomplete yet normative list of virtual instruction
> exceptions also makes it harder to understand the exact virtual/illegal
> dichotomy.

You're not suggesting we drop the list from Section 5.6.1 and let
everyone work out all the specific cases themselves based on the
general rules from that section, are you?  I'm guessing not; rather,
it's the incompleteness you're objecting to.

I wrote that the list is not necessarily complete because I was
thinking of extensions such as Smstateen and the AIA (Advanced
Interrupt Architecture), plus the constant risk of additions elsewhere
within the Privileged ISA itself.  But if it will make people more
comfortable, we can drop the caution about the list's possible
incompleteness, add a more conscious caveat statement that extensions
may add to the list, and rely on everyone working to keep this list
always complete and up-to-date in the Privileged ISA document.

To be honest, I have my doubts about that last part, but we can give it
a try if that's what people prefer.

If we go the route of promising a complete list of virtual instruction
exceptions, can we count on you, Paul, to study the current list
carefully and report on any cases you see that might be missing?

    - John Hauser

Guest page faults get messier because they can either be for VS-stage PTEs (which are presumably higher priority than page faults in VS-stage) or for the final memory access (which would be lower priority than VS-stage page faults).  And I now realize that you can get access faults on G-stage PTEs which are accessed to translate the instruction-side VS-stage table walks, hoisting that data access fault above a VS-stage instruction page fault.  I think that it's fairly intuitive how it has to work (at least for somebody who understands the big picture) but specifying it will be quite messy.