Re: [PATCH v2 13/39] xen/riscv: save and restore AIA state on vCPU context switch

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

> vsiselect and hviprio{1,2} are per-hart CSRs which a guest can change, so
> they have to be part of the vCPU context:
Where in the spec did you see that? Because in AIA spec section 6.3.1,
it is written that "When vsiselect has a value in the range 0x30-0x3F,
an attempt from VS-mode to access sireg (really vsireg) causes a virtual
instruction exception" and this even when hstateen0.CSRIND is set as hstateen0
just control whether a guest/S-mode is allowed to access a CSR (exactly
as you described below).

Therefore, the hypervisor has two options to modify the priority of a
major irq:
- emulate the iprio array in software.
- Use hviprio1/hviprio2 (only 10 irqs configurable).

But the guest shouldn't be able to modify h CSRs at all, in any case, or
I may have misunderstood a part of the spec.

For the moment I don't see any catch of possible instruction exception
in do_trap().

>  - vsiselect is written directly by VS-mode through siselect;
>  - hviprio1 and hviprio2 hold the priorities of the local interrupts which
>    VS-mode reaches through the iprio array of vsiselect/vsireg, so writes
>    the guest performs there land in these CSRs.
hviprio1 and hviprio2 hold priorities for interrupts 1 (SSI), 5 (STI),
13 (counter overflow), and 14-23 (local) so calling all of them "local"
is wrong.
> Without saving them, one vCPU's selector leaks into another vCPU's vsireg
> accesses and one guest's interrupt priorities apply to the next guest which
> runs on the same hart.
> 
> Whether the CSRs may be touched at all is gated by hstateen0 when Smstateen
> is implemented: SVSLCT for vsiselect/vsireg and AIA for the rest of the AIA
I couldn't find any reference to SVSLCT in the spec. I assume you wanted
to refer to CSRIND and SVSLCT is an OpenSBI's own nickname.

-- 
Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>