On Tue, Jul 30, 2019 at 7:38 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 30/07/19 15:35, Anup Patel wrote: > > On Tue, Jul 30, 2019 at 6:48 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> > >> On 30/07/19 14:45, Anup Patel wrote: > >>> Here's some text from RISC-V spec regarding SIP CSR: > >>> "software interrupt-pending (SSIP) bit in the sip register. A pending > >>> supervisor-level software interrupt can be cleared by writing 0 to the SSIP bit > >>> in sip. Supervisor-level software interrupts are disabled when the SSIE bit in > >>> the sie register is clear." > >>> > >>> Without RISC-V hypervisor extension, the SIP is essentially a restricted > >>> view of MIP CSR. Also as-per above, S-mode SW can only write 0 to SSIP > >>> bit in SIP CSR whereas it can only be set by M-mode SW or some HW > >>> mechanism (such as S-mode CLINT). > >> > >> But that's not what the spec says. It just says (just before the > >> sentence you quoted): > >> > >> A supervisor-level software interrupt is triggered on the current > >> hart by writing 1 to its supervisor software interrupt-pending (SSIP) > >> bit in the sip register. > > > > Unfortunately, this statement does not state who is allowed to write 1 > > in SIP.SSIP bit. > > If it doesn't state who is allowed to write 1, whoever has access to sip > can. > > > I quoted MIP CSR documentation to highlight the fact that only M-mode > > SW can set SSIP bit. > > > > In fact, I had same understanding as you have regarding SSIP bit > > until we had MSIP issue in OpenSBI. > > (https://github.com/riscv/opensbi/issues/128) > > > >> and it's not written anywhere that S-mode SW cannot write 1. In fact > >> that text is even under sip, not under mip, so IMO there's no doubt that > >> S-mode SW _can_ write 1, and the hypervisor must operate accordingly. > > > > Without hypervisor support, SIP CSR is nothing but a restricted view of > > MIP CSR thats why MIP CSR documentation applies here. > > But the privileged spec says mip.MSIP is read-only, it cannot be cleared > (as in the above OpenSBI issue). So mip.MSIP and sip.SSIP are already > different in that respect, and I don't see how the spec says that S-mode > SW cannot set sip.SSIP. > > (As an aside, why would M-mode even bother using sip and not mip to > write 1 to SSIP?). > > > I think this discussion deserves a Github issue on RISC-V ISA manual. > > Perhaps, but I think it makes more sense this way. The question remains > of why M-mode is not allowed to write to MSIP/MEIP/MTIP. My guess is > that then MSIP/MEIP/MTIP are simply a read-only view of an external pin, > so it simplifies hardware a tiny bit by forcing acks to go through the > MMIO registers. > > > If my interpretation is incorrect then it would be really strange that > > HART in S-mode SW can inject IPI to itself by writing 1 to SIP.SSIP bit. > > Well, it can be useful, for example Windows does it when interrupt > handlers want to schedule some work to happen out of interrupt context. > Going through SBI would be unpleasant if it causes an HS-mode trap. Another way of artificially injecting interrupt would be using interrupt controller, where Windows can just write to some pending register of interrupt controller. I have raised a new Github issue on GitHub for clarity on this. You can add your comments to this issue as well. https://github.com/riscv/riscv-isa-manual/issues/425 Also, I have raised a proposal to support mechanism for external entity (such as PLICv2 with virtualization support) to inject virtual interrupts. https://github.com/riscv/riscv-isa-manual/issues/429 Regards, Anup
