Siqi, Thanks. That narrows down where we are differing. If the hypervisor has set hideleg bit 6 (so that VS-level timer interrupts can be received by VS-mode while V=1), then any new pending

Hi Greg, I understand your concern. In fact, the goal is not to provide more than one vstimecmp CSR. You are right that when a VM is context switched out, it's vstimecmp CSR is also switched out.

Siqi, Thanks for your clarification. If I understand correctly, your goal (analogous to SGEI as you mention) is to enable a pending virtual timer interrupt, even for a VM not currently context

OK - taking a step back, what about requiring: any extension spec that doesn't specifically discuss enabling and disabling should be prohibited from enabling or disabling.. I can't see any good use

The hypervisor spec specifically says that implementations should have writable misa so this isn't theoretical: "The hypervisor extension is enabled by setting bit 7 in the misa CSR, which corresponds

I thought there was already a speced requirement that, at reset, all extensions are enabled.: "At reset, theExtensions field shall contain the maximal set of supported extensions, and I shall be

I think that the general statement for misa should definitely be that it's UNSPECIFIED. For instance, implementations may want to power gate a vector unit when V is disabled and that becomes more

A potential second general requirement for all Priv extensions: - The hart reset state must be fully specified and should generally be UNSPECIFIED except for any key control/status bits that need to

I'm not sure, off-hand, if there is a many item list to be created or not. (Andrew probably has better thoughts on this.) But on the particular topic of this email thread, my leaning would be to say

Is there a checklist of requirements for priv specifications? if not should there be? If there is, would this be a requirement in that list to specify to some level of clarity (maybe indicating what

Hi Greg, Thanks for the comments. It seems the proposal is not explicit enough about the type of interrupt. So to answer your question, with vstimecmp, there is in fact a new type of interrupt types.

I don’t object, but I’m wondering: would different implementations actually be motivated to have different behavior w.r.t. hypervisor state when H is disabled then re-enabled? Put another way, do

(Compliance hat on): I'd like to dig into that a bit further. This has come up in the context of WARL registers, where changing the value of some CSR field1 causes some other CSR field2 value to

In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser. One thing that has changed is that now the architecture

Fair enough. I was thinking of a system where the DVFS would be under the control of M-mode software, but in some chips it could be done by a more autonomous DVFS controller of some sort. Sounds like

Scale factors don't work if the clock is constantly changing e.g. DVFS

Another option is to create memory-mapped registers for stimecmp/vstimecmp at addresses that are accessible to S-mode/VS-mode software.

One of the main reasons for making mtime/mtimecmp memory-mapped rather than CSRs is to support systems where the CPU(s) do not run at a constant clock frequency. In such systems, the mtime counter

zhaosiqi (Siqi) wrote: There is an informal group that is working on a proposal for a RISC-V "Advanced Interrupt Architecture", which includes replacements for the current PLIC. No document is

A few other small nits: - Besides by S-mode and M-mode, the stimecmp CSR is accessible by HS-mode; and is accessible by VS-mode as well (during which the vstimecmp CSR contents substitute for stimecmp