hyp 0.6 - relation between mip, hip and hvip?

[Jose Martins]

I'm going through the lastest hypervisor spec (v0.6) and I've got
confused on the relation between mip, hip, hvip, especially regarding
the vssip bit.

The spec clearly states that the vs interrupt pending bits on mip are
aliases of the bits in hip. Also, the spec states that hip.vssip is a
RW alias of hvip.vssip. So, does this must mean mip.vssip is also an
alias of hvip.vssip? Essentially, the same underlying bit register for
the three views?

What about the relation of vseip and vstip bits between mip and hvip?
As the only explicit statement mentioning these bits is regarding mip
and hip, I assume reading the register through mip has the same result
as reading it through hip. Although these are RO in hip (and following
the same logic as the s-mode interrupts bits and their relation
between mip and sip),
these seem to be writable through mip. But what is the effect of
writing these bits in mip? The spec says nothing on the effects of
mip.vseip and mip.vstip on the pending status of these interrupts as
read through hip. Or is it assumed these are also aliases of the same
bits in hvip?

Jose

[Jose Martins]

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.

Can someone enlighten me?

[Jose Martins]

Is there a better place for me to put this question?

On Saturday, 7 March 2020 18:20:18 UTC, Jose Martins wrote:

[John Hauser]

A while ago, Jose Martins wrote:
> The spec clearly states that the vs interrupt pending bits on mip are
> aliases of the bits in hip. Also, the spec states that hip.vssip is a
> RW alias of hvip.vssip. So, does this must mean mip.vssip is also an
> alias of hvip.vssip? Essentially, the same underlying bit register for
> the three views?

Yes, that is the intention.

> What about the relation of vseip and vstip bits between mip and hvip?
> As the only explicit statement mentioning these bits is regarding mip
> and hip, I assume reading the register through mip has the same result
> as reading it through hip. Although these are RO in hip (and following
> the same logic as the s-mode interrupts bits and their relation
> between mip and sip), these seem to be writable through mip.

No, bits VSEIP and VSTIP are read-only in mip, the same as in hip.

> But what is the effect of
> writing these bits in mip? The spec says nothing on the effects of
> mip.vseip and mip.vstip on the pending status of these interrupts as
> read through hip.

Writing VSEIP or VSTIP in mip has no effect.  Hence, there will be no
transitive effect on VSEIP or VSTIP in hip either.  The read-only
values for bits VSEIP and VSTIP in hip (and thus in mip too) are
determined solely by the rules in section 5.2.3, "Hypervisor Interrupt
Registers (hvip, hip, and hie)".

> 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.)

I'm sorry you didn't get a quicker response to your questions.

    - John Hauser

[Jose Martins]

Thank you once again for taking the time for a detailed explanation.