Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR
toggle quoted message Show quoted text
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 switched in, to cause an interrupt to the hypervisor so that it can context switch in that VM. (As you recognize, for virtual external interrupts this is based on the hgeip / hgeie registers and hip.SGEIP / hie.SGEIE register bits.)
In contrast, for the VM currently switched in, a virtual timer interrupt can be directly reflected - based on hideleg - in either hip.VSTIP or vsip.STIP, i.e. the hypervisor can choose whether the pending interrupt goes to itself or directly to the guest. (In the latter case the hypervisor can also poll hip.VSTIP.) There's no need for an SGEI-like mechanism here.
The problem is that while a VM is context switched out, its vstimecmp is also switched out. Or, put differently, if there are N VM's currently assigned to a hart and one wants hardware to inform the hypervisor when a VM's virtual timer "fires", then there would need to be N vstimecmp registers, N associated htimedelta registers, N time comparators, and one would need the equivalent of the hgeip/hgeie registers (i.e. hgtip/hgtie), and hip.SGTIP and hie.SGTIE bits. In essence, the full analogue of what the H-extension provides for virtual external interrupts.
This obviously is a lot more expensive that the analogous support for virtual external interrupts. One can also observe that other architectures (using ARMv8 as an example) don't provide hardware support for sending virtual timer interrupts to the hypervisor for VM's not currently context-switched in. Instead the hypervisor can keep track of the stimecmp's for VM's, recognize when one of them "fires", and context switch in that VM. (I can't say specifically how ARMv8 hypervisors deal with this, but one could imagine a scheme similar to what RISC-V imagines for multiplexing OS-level timers onto the one hardware M-mode timer.)
Am I addressing your intended goal or do you have in mind a different goal behind your suggested arch changes?
On Thu, Sep 10, 2020 at 12:14 AM zhaosiqi (A) via lists.riscv.org <zhaosiqi3=huawei.com@...> wrote: