Question about the condition of response for interrupt injected by hvictl

[myx922]

Hi @jhauser-us , I have some question about interrupt injected by hvictl. As spec says:

if hvictl fields VTI = 1 and IID ̸= 9:

• the major interrupt specified by hvictl fields IID, DPR, and IPRIO.

1. if this case hit, the condition of response for interrupt is VTI = 1, IID interrupt can be delegraded to VS mode, and current privilege mode is VS or VU, there's no need to set vsie[IID] to 1, right?
2. Continuing from question 1, if the core response the interrupt injected by hvictl, it must trap to VS mode, right?

Thanks.

[jhauser-us]

@myx922, for your first question, it sounds like you think there is an additional requirement that the major interrupt indicated by hvictl.IID is delegated or injected to VS-mode by hideleg or hvien. If so, that is incorrect. The contents of hideleg, hvien, hvip, vsip, and vsie are all ignored for this interrupt candidate (number 5 in the list of 5 possible candidates). All that matters is what the spec says that you quoted: hvictl.VTI = 1 and hvictl.IID != 9.

The rules from that AIA section ("Virtual supervisor top interrupt CSR (vstopi)") determine the value of vstopi at all times. Your second question is answered by the next section ("Interrupt traps to VS-mode"), which specifies how and when the value of vstopi leads to a trap to VS-mode. The value of vstopi has no effect on traps to privilege modes M and HS.

(But concerning the exact timing of an interrupt trap, see also what the Privileged ISA spec says in the section titled "Supervisor Interrupt Registers (sip and sie)", in the paragraph that begins, "These conditions for an interrupt trap to occur must be evaluated in a bounded amount of time ....")

[Baixyzz]

@jhauser-us ,from your response, I understand that if 'hvictl fields VTI=1 and IID=1', even if vsie [1]=0, an SSI will be injected into the VS level, and if the current privilege mode is VS mode and vsstatus SIE bit is 1, a trap is taken to VS mode. I am confused as to why injecting SEI into VS level using hvictl requires vsie [9]=1 and does not require hvictl VTI=1, but using hvictl to inject other interrupts do not require these two conditions.

[jhauser-us]

Setting hvictl.VTI = 1 allows major interrupts to be injected into VS level, even when the corresponding bits in vsip and vsie are hardwired to zeros. When hvictl.VTI = 1, attempts by VS-level software to access sip and sie are trapped and must be emulated by the hypervisor. It is for this combination of reasons that the values of the real vsip and vsie are mostly ignored when hvictl.VTI = 1.

Setting hvictl.VTI = 1 will result in some loss of performance because of extra trapping. A special case has been made to allow artificial SEIs (major code 9) to be injected with hvictl.VTI = 0. When hvictl.VTI = 0, the values of vsip and vsie are visible to VS-level software, so it's important that they be set correctly, even when an SEI is artificial from hvictl. Unlike many other major interrupts, we know that bit 9 in vsip and vsie can always be manipulated by the hypervisor (those bits cannot be hardwired to zeros by a hart implementation).

[Baixyzz]

@jhauser-us ,thank you for your reply. From your reply, I understand that the main purpose of the hvictl.VTI bit design is to ensure that vsip is not seen by VS-level software when hvictl is used to inject certain interrupts whose corresponding bits in vsip are hardwired to zeros. If so, I still have another confusion. If a major interrupt is hardwired to zero in the corresponding bit of vsip, it seems to indicate that the implementation does not support processing of this interrupt in VS-level. At this time, what is the meaning of using hvictl to inject such an interrupt?

[jhauser-us]

VS-level is S-level in a virtual machine. The question to ask is not what interrupts the implementation wants to support but what interrupts the software running in the VM expects to work.

Paravirtualization is a popular technique where the software in the VM is expected to know and/or adapt (at compile time or run time) to what the hardware actually supports. However, the RISC-V H extension is designed to provide VM support that goes beyond paravirtualization. The software in the VM may have been originally compiled for a different machine than the one currently running it.

[Baixyzz]

thanks