From: Anup Patel <anup@brainfault.org> To: Paolo Bonzini <pbonzini@redhat.com> Cc: Anup Patel <Anup.Patel@wdc.com>, Palmer Dabbelt <palmer@sifive.com>, Paul Walmsley <paul.walmsley@sifive.com>, Radim K <rkrcmar@redhat.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Atish Patra <Atish.Patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Damien Le Moal <Damien.LeMoal@wdc.com>, Christoph Hellwig <hch@infradead.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 05/16] RISC-V: KVM: Implement VCPU interrupts and requests handling Date: Tue, 30 Jul 2019 18:15:39 +0530 [thread overview] Message-ID: <CAAhSdy3b-o6y1fsYi1iQcCN=9ZuC98TLCqjHCYAzOCx+N+_89w@mail.gmail.com> (raw) In-Reply-To: <66c4e468-7a69-31e7-778b-228908f0e737@redhat.com> On Tue, Jul 30, 2019 at 5:42 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 30/07/19 14:00, Anup Patel wrote: > > On Tue, Jul 30, 2019 at 4:47 PM Paolo Bonzini <pbonzini@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Anup Patel <anup@brainfault.org> To: Paolo Bonzini <pbonzini@redhat.com> Cc: Damien Le Moal <Damien.LeMoal@wdc.com>, Palmer Dabbelt <palmer@sifive.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Radim K <rkrcmar@redhat.com>, Anup Patel <Anup.Patel@wdc.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>, Atish Patra <Atish.Patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Paul Walmsley <paul.walmsley@sifive.com>, Thomas Gleixner <tglx@linutronix.de>, "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org> Subject: Re: [RFC PATCH 05/16] RISC-V: KVM: Implement VCPU interrupts and requests handling Date: Tue, 30 Jul 2019 18:15:39 +0530 [thread overview] Message-ID: <CAAhSdy3b-o6y1fsYi1iQcCN=9ZuC98TLCqjHCYAzOCx+N+_89w@mail.gmail.com> (raw) In-Reply-To: <66c4e468-7a69-31e7-778b-228908f0e737@redhat.com> On Tue, Jul 30, 2019 at 5:42 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 30/07/19 14:00, Anup Patel wrote: > > On Tue, Jul 30, 2019 at 4:47 PM Paolo Bonzini <pbonzini@redhat.com> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-07-30 12:45 UTC|newest] Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-29 11:56 [RFC PATCH 00/16] KVM RISC-V Support Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-29 11:56 ` [RFC PATCH 01/16] KVM: RISC-V: Add KVM_REG_RISCV for ONE_REG interface Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-29 11:56 ` [RFC PATCH 02/16] RISC-V: Add hypervisor extension related CSR defines Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-29 11:56 ` [RFC PATCH 03/16] RISC-V: Add initial skeletal KVM support Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-30 9:23 ` Paolo Bonzini 2019-07-30 9:23 ` Paolo Bonzini 2019-07-30 11:04 ` Anup Patel 2019-07-30 11:04 ` Anup Patel 2019-07-30 9:25 ` Paolo Bonzini 2019-07-30 9:25 ` Paolo Bonzini 2019-07-30 11:03 ` Anup Patel 2019-07-30 11:03 ` Anup Patel 2019-07-29 11:56 ` [RFC PATCH 04/16] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-30 8:48 ` Paolo Bonzini 2019-07-30 8:48 ` Paolo Bonzini 2019-07-30 10:16 ` Paolo Bonzini 2019-07-30 10:16 ` Paolo Bonzini 2019-07-30 11:45 ` Anup Patel 2019-07-30 11:45 ` Anup Patel 2019-07-30 11:47 ` Paolo Bonzini 2019-07-30 11:47 ` Paolo Bonzini 2019-07-29 11:56 ` [RFC PATCH 05/16] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-30 11:17 ` Paolo Bonzini 2019-07-30 11:17 ` Paolo Bonzini 2019-07-30 12:00 ` Anup Patel 2019-07-30 12:00 ` Anup Patel 2019-07-30 12:12 ` Paolo Bonzini 2019-07-30 12:12 ` Paolo Bonzini 2019-07-30 12:45 ` Anup Patel [this message] 2019-07-30 12:45 ` Anup Patel 2019-07-30 13:18 ` Paolo Bonzini 2019-07-30 13:18 ` Paolo Bonzini 2019-07-30 13:35 ` Anup Patel 2019-07-30 13:35 ` Anup Patel 2019-07-30 14:08 ` Paolo Bonzini 2019-07-30 14:08 ` Paolo Bonzini 2019-08-02 3:59 ` Anup Patel 2019-08-02 3:59 ` Anup Patel 2019-07-29 11:56 ` [RFC PATCH 06/16] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel 2019-07-29 11:56 ` Anup Patel 2019-07-30 8:43 ` Paolo Bonzini 2019-07-30 8:43 ` Paolo Bonzini 2019-07-30 9:35 ` Paolo Bonzini 2019-07-30 9:35 ` Paolo Bonzini 2019-07-30 12:08 ` Anup Patel 2019-07-30 12:08 ` Anup Patel 2019-07-30 12:10 ` Paolo Bonzini 2019-07-30 12:10 ` Paolo Bonzini 2019-07-30 12:16 ` Anup Patel 2019-07-30 12:16 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 07/16] RISC-V: KVM: Implement VCPU world-switch Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-30 9:34 ` Paolo Bonzini 2019-07-30 9:34 ` Paolo Bonzini 2019-07-30 12:51 ` Anup Patel 2019-07-30 12:51 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 08/16] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-30 11:20 ` Paolo Bonzini 2019-07-30 11:20 ` Paolo Bonzini 2019-07-31 7:23 ` Anup Patel 2019-07-31 7:23 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 09/16] RISC-V: KVM: Handle WFI " Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 10/16] RISC-V: KVM: Implement VMID allocator Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-30 8:59 ` Paolo Bonzini 2019-07-30 8:59 ` Paolo Bonzini 2019-07-29 11:57 ` [RFC PATCH 11/16] RISC-V: KVM: Implement stage2 page table programming Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-30 9:00 ` Paolo Bonzini 2019-07-30 9:00 ` Paolo Bonzini 2019-07-30 12:14 ` Anup Patel 2019-07-30 12:14 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 12/16] RISC-V: KVM: Implement MMU notifiers Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 13/16] RISC-V: KVM: Add timer functionality Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-29 14:40 ` Andreas Schwab 2019-07-29 14:40 ` Andreas Schwab 2019-07-29 18:02 ` Atish Patra 2019-07-29 18:02 ` Atish Patra 2019-07-30 6:51 ` Andreas Schwab 2019-07-30 6:51 ` Andreas Schwab 2019-07-30 7:00 ` Atish Patra 2019-07-30 7:00 ` Atish Patra 2019-07-30 11:26 ` Paolo Bonzini 2019-07-30 11:26 ` Paolo Bonzini 2019-07-31 1:55 ` Atish Patra 2019-07-31 1:55 ` Atish Patra 2019-07-31 6:58 ` Paolo Bonzini 2019-07-31 6:58 ` Paolo Bonzini 2019-07-31 7:18 ` Anup Patel 2019-07-31 7:18 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 14/16] RISC-V: KVM: FP lazy save/restore Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-29 11:57 ` [RFC PATCH 15/16] RISC-V: KVM: Add SBI v0.1 support Anup Patel 2019-07-29 11:57 ` Anup Patel 2019-07-29 19:40 ` Paolo Bonzini 2019-07-29 19:40 ` Paolo Bonzini 2019-07-29 19:51 ` Atish Patra 2019-07-29 19:51 ` Atish Patra 2019-07-29 20:08 ` Paolo Bonzini 2019-07-29 20:08 ` Paolo Bonzini 2019-07-29 21:08 ` Atish Patra 2019-07-29 21:08 ` Atish Patra 2019-07-30 9:26 ` Paolo Bonzini 2019-07-30 9:26 ` Paolo Bonzini 2019-07-29 11:58 ` [RFC PATCH 16/16] RISC-V: Enable VIRTIO drivers in RV64 and RV32 defconfig Anup Patel 2019-07-29 11:58 ` Anup Patel 2019-07-29 21:47 ` [RFC PATCH 00/16] KVM RISC-V Support Paolo Bonzini 2019-07-29 21:47 ` Paolo Bonzini 2019-07-30 5:26 ` Anup Patel 2019-07-30 5:26 ` Anup Patel 2019-07-30 11:33 ` Paolo Bonzini 2019-07-30 11:33 ` Paolo Bonzini 2019-07-30 13:50 ` Anup Patel 2019-07-30 13:50 ` Anup Patel 2019-07-30 14:02 ` Paolo Bonzini 2019-07-30 14:02 ` Paolo Bonzini 2019-07-30 6:53 ` Andreas Schwab 2019-07-30 6:53 ` Andreas Schwab 2019-07-30 7:25 ` Anup Patel 2019-07-30 7:25 ` Anup Patel 2019-07-30 7:42 ` Andreas Schwab 2019-07-30 7:42 ` Andreas Schwab 2019-07-30 7:36 ` Anup Patel 2019-07-30 7:36 ` Anup Patel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAAhSdy3b-o6y1fsYi1iQcCN=9ZuC98TLCqjHCYAzOCx+N+_89w@mail.gmail.com' \ --to=anup@brainfault.org \ --cc=Alistair.Francis@wdc.com \ --cc=Anup.Patel@wdc.com \ --cc=Atish.Patra@wdc.com \ --cc=Damien.LeMoal@wdc.com \ --cc=daniel.lezcano@linaro.org \ --cc=hch@infradead.org \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@sifive.com \ --cc=paul.walmsley@sifive.com \ --cc=pbonzini@redhat.com \ --cc=rkrcmar@redhat.com \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.