Siqi (zhaosiqi3@...) wrote:

Reading through the hypervisor extension v0.6, I noticed the new
register called hvip. The spec says that this register is intended
for the hypervisor to write to indicate pending interrupts for the
VS-mode. However, as how I understood the older version of the
hypervisor extension, this purposed has already been fulfilled by
writing to the vsip register. Why make another register? Am I missing
something?

The same question was raised not long ago on the RISC-V ISA Dev mailing
list. The following is clipped from that conversation.

--------------------

Jose Martins wrote:

Actually, the purpose of this new hvip register is not entirely clear
to me. In v0.5 it was possible to inject virtual interrupts in vs mode
through hip.

As a general rule, simple injection of interrupts into VS mode can now
be done only through hvip. Technically, VSSIP is an exception, because
its alias in hip is writable, but my advice is to ignore that quirk.

As you know, in draft 0.5 of the hypervisor extension, hip.VSEIP
was defined with an underlying software-writable bit, analogous to
mip.SEIP. At the time, this seemed the most consistent way to handle
injection of interrupts into VS mode. However, it caused a headache
for software, as I explained in December in a message to a RISC-V
working group:

(But beware: If, in the future, there are hardware sources for the
value of hip.VSEIP, a simple save and restore of hip could cause the
software-writable VSEIP bit to become spuriously set when it wasn't
before. The safe way to save hip would be as follows: After reading
the CSR, if the software-writable VSEIP bit is not supposed to be set,
clear the VSEIP bit from the hip value before saving it in your VCPU
control structure. If the hypervisor may ever set the software-
writable VSEIP bit, it must keep track of the intended state of this
bit, and furthermore this knowledge must be accessible to the code that
saves the CSRs on context switches.)

When contemplating additional hardware support for nested hypervisors,
it was realized there could be times when the software doing a context
swap might not know the location of the intended state of the software-
writable VSEIP bit, making it impossible to correctly swap hip.
Adding hvip solved this problem, by putting the information in a known
accessible place and eliminating a CSR bit with odd semantics. (The
odd semantics still exist for mip.SEIP, but with less consequences for
software.)

--------------------

- John Hauser