On Tue, Jul 30, 2019 at 5:42 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 30/07/19 14:00, Anup Patel wrote: > > On Tue, Jul 30, 2019 at 4:47 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > >> > >> First, something that is not clear to me: how do you deal with a guest > >> writing 1 to VSIP.SSIP? I think that could lead to lost interrupts if > >> you have the following sequence > >> > >> 1) guest writes 1 to VSIP.SSIP > >> > >> 2) guest leaves VS-mode > >> > >> 3) host syncs VSIP > >> > >> 4) user mode triggers interrupt > >> > >> 5) host reenters guest > >> > >> 6) host moves irqs_pending to VSIP and clears VSIP.SSIP in the process > > > > This reasoning also apply to M-mode firmware (OpenSBI) providing timer > > and IPI services to HS-mode software. We had some discussion around > > it in a different context. > > (Refer, https://github.com/riscv/opensbi/issues/128) > > > > The thing is SIP CSR is supposed to be read-only for any S-mode SW. This > > means HS-mode/VS-mode SW modifications to SIP CSR should have no > > effect. > > Is it? The privileged specification says > > Interprocessor interrupts are sent to other harts by implementation- > specific means, which will ultimately cause the SSIP bit to be set in > the recipient hart’s sip register. To further explain my rationale ... Here's some text from RISC-V spec regarding MIP CSR: "The mip register is an MXLEN-bit read/write register containing information on pending interrupts, while mie is the corresponding MXLEN-bit read/write register containing interrupt enable bits. Only the bits corresponding to lower-privilege software interrupts (USIP, SSIP), timer interrupts (UTIP, STIP), and external interrupts (UEIP, SEIP) in mip are writable through this CSR address; the remaining bits are read-only." 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). There was quite a bit of discussion in last RISC-V Zurich Workshop about avoiding SBI calls for injecting IPIs. The best suggestion so far is to eventually have RISC-V systems with separate CLINT HW for M-mode and S-mode. The S-mode SW can use S-mode CLINT to trigger IPIs to other CPUs and it will use SBI calls for IPIs only when S-mode CLINT is not available. > > All bits besides SSIP in the sip register are read-only. > > Meaning that sending an IPI to self by writing 1 to sip.SSIP is > well-defined. The same should be true of vsip.SSIP while in VS mode. > > > Do you still an issue here? > > Do you see any issues in the pseudocode I sent? It gets away with the > spinlock and request so it may be a good idea anyway. :) Yes, I am evaluating your psedocode right now. I definitely want to remove the irq_pending_lock if possible. I will try to in-corporate your suggestion in v2 series. Regards, Anup
