Dear Paul Donahue, Thank you very much for your reply！ I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the

Dear Anup Patel, Thank you very much for your reply. I would like to continue to ask: If GEILEN is 0, CSR hgeip and hgeie will always be all zero. Then, hip.SGEIP is always 0. You said:

If GEILEN is zero then there are no guest external interrupts but software (i.e. hypervisor) can still inject external interrupts using hvip CSR. In other words, software-injected external interrupts

To whom it may concern, I have a question about guest external interrupt. The privileged ISA said: "GEILEN may be zero". If GEILEN is zero, is the implementation unable to receive guest external

For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory

To whom it may concern, I have a question about CSR hedeleg and hideleg. The ISA Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." I would

We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RV arch extensions that

For visibility: I opened a few issues in the GitHub repository. "a trap may occur between the PTE update and the memory access"? (#3) allow speculative G-stage D bit updates for VS-stage A bit

While, in general, CSR bits are either RW or RdOnly, there is one exception that I am aware of, and it is quite pertinent to your scenario (as was intended to be from the beginning) and that is the

This is more than just clarifying and naming. It also defines a specfic WARL control bit. in an existing, defined CSR. Individual WARL CSR bits can be RW, RdOnlyZero, or RdOnly1 (WARL *fields* can

The purpose of this e-mail is to start a discussion/debate around the issue that I raised in the tech-chairs meeting this week related the m-mode and the stability of the configuration. It is

There were two motivations. One to name the specified behavior and second to provide a control to select between the two specified behaviors. The specification for hardware updating of A/D bits

I would concur with Scott above. Clarifications to the spec belong in the spec itself, not inside an extension. If the Architecture Review Committee suggested otherwise, is it because the

This path was suggested by the Architecture Review Committee. As noted up thread, hardware updateable PTE A/D bits were already in the spec. This extension is coining a name, and providing a bit more

If these two are intended only as clarifications of what the privileged spec already says, then these clarifications should be made to the privileged spec, not here in this optional extension.

My understanding of the situation (caveat: not my area of expertise) is that mixed software and hardware A/D updates is not likely to work in a system (perhaps because software is using locks and

This is addressed by the step 2 and 7.a of the translation process: 2. If accessing pte violates a PMA or PMP check, raise an access-fault exception corresponding to the original access

John Ingalls wrote: It is not a lot of text so request you to compare the two to see if the edits may be considered significant. I feel the following may be considered as significant: 1.

I concur; it is not apparent from this spec what is different vs. the long-existing implementation option to have hardware A/D updating. Is it only the new CSR bits? This constraint appears new: >

> "The A and D bits are managed by these extensions as follows: ..." Does the scope of this extension include changing, constraining, or clarifying the behaviors already described in the Privileged