Message ID | 20190822084131.114764-1-anup.patel@wdc.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM RISC-V Support | expand |
On 22.08.19 10:42, Anup Patel wrote: > This series adds initial KVM RISC-V support. Currently, we are able to boot > RISC-V 64bit Linux Guests with multiple VCPUs. > > Few key aspects of KVM RISC-V added by this series are: > 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs. > 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure. > 3. KVM ONE_REG interface for VCPU register access from user-space. > 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will > be added in future. > 5. Timer and IPI emuation is done in-kernel. > 6. MMU notifiers supported. > 7. FP lazy save/restore supported. > 8. SBI v0.1 emulation for KVM Guest available. > > Here's a brief TODO list which we will work upon after this series: > 1. Handle trap from unpriv access in reading Guest instruction > 2. Handle trap from unpriv access in SBI v0.1 emulation > 3. Implement recursive stage2 page table programing > 4. SBI v0.2 emulation in-kernel > 5. SBI v0.2 hart hotplug emulation in-kernel > 6. In-kernel PLIC emulation > 7. ..... and more ..... Please consider patches I did not comment on as Reviewed-by: Alexander Graf <graf@amazon.com> Overall, I'm quite happy with the code. It's a very clean implementation of a KVM target. The only major nit I have is the guest address space read: I don't think we should pull in code that we know allows user space to DOS the kernel. For that, we need to find an alternative. Either you implement a software page table walker and resolve VAs manually or you find a way to ensure that *any* exception taken during the read does not affect general code execution. Thanks, Alex
On Fri, Aug 23, 2019 at 1:39 PM Alexander Graf <graf@amazon.com> wrote: > > On 22.08.19 10:42, Anup Patel wrote: > > This series adds initial KVM RISC-V support. Currently, we are able to boot > > RISC-V 64bit Linux Guests with multiple VCPUs. > > > > Few key aspects of KVM RISC-V added by this series are: > > 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs. > > 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure. > > 3. KVM ONE_REG interface for VCPU register access from user-space. > > 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will > > be added in future. > > 5. Timer and IPI emuation is done in-kernel. > > 6. MMU notifiers supported. > > 7. FP lazy save/restore supported. > > 8. SBI v0.1 emulation for KVM Guest available. > > > > Here's a brief TODO list which we will work upon after this series: > > 1. Handle trap from unpriv access in reading Guest instruction > > 2. Handle trap from unpriv access in SBI v0.1 emulation > > 3. Implement recursive stage2 page table programing > > 4. SBI v0.2 emulation in-kernel > > 5. SBI v0.2 hart hotplug emulation in-kernel > > 6. In-kernel PLIC emulation > > 7. ..... and more ..... > > Please consider patches I did not comment on as > > Reviewed-by: Alexander Graf <graf@amazon.com> > > Overall, I'm quite happy with the code. It's a very clean implementation > of a KVM target. Thanks Alex. > > The only major nit I have is the guest address space read: I don't think > we should pull in code that we know allows user space to DOS the kernel. > For that, we need to find an alternative. Either you implement a > software page table walker and resolve VAs manually or you find a way to > ensure that *any* exception taken during the read does not affect > general code execution. I will send v6 next week. I will try my best to implement unpriv trap handling in v6 itself. Regards, Anup > > > Thanks, > > Alex
> Am 23.08.2019 um 13:26 schrieb Anup Patel <anup@brainfault.org>: > >> On Fri, Aug 23, 2019 at 1:39 PM Alexander Graf <graf@amazon.com> wrote: >> >>> On 22.08.19 10:42, Anup Patel wrote: >>> This series adds initial KVM RISC-V support. Currently, we are able to boot >>> RISC-V 64bit Linux Guests with multiple VCPUs. >>> >>> Few key aspects of KVM RISC-V added by this series are: >>> 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs. >>> 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure. >>> 3. KVM ONE_REG interface for VCPU register access from user-space. >>> 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will >>> be added in future. >>> 5. Timer and IPI emuation is done in-kernel. >>> 6. MMU notifiers supported. >>> 7. FP lazy save/restore supported. >>> 8. SBI v0.1 emulation for KVM Guest available. >>> >>> Here's a brief TODO list which we will work upon after this series: >>> 1. Handle trap from unpriv access in reading Guest instruction >>> 2. Handle trap from unpriv access in SBI v0.1 emulation >>> 3. Implement recursive stage2 page table programing >>> 4. SBI v0.2 emulation in-kernel >>> 5. SBI v0.2 hart hotplug emulation in-kernel >>> 6. In-kernel PLIC emulation >>> 7. ..... and more ..... >> >> Please consider patches I did not comment on as >> >> Reviewed-by: Alexander Graf <graf@amazon.com> >> >> Overall, I'm quite happy with the code. It's a very clean implementation >> of a KVM target. > > Thanks Alex. > >> >> The only major nit I have is the guest address space read: I don't think >> we should pull in code that we know allows user space to DOS the kernel. >> For that, we need to find an alternative. Either you implement a >> software page table walker and resolve VAs manually or you find a way to >> ensure that *any* exception taken during the read does not affect >> general code execution. > > I will send v6 next week. I will try my best to implement unpriv trap > handling in v6 itself. Are you sure unpriv is the only exception that can hit there? What about NMIs? Do you have #MCs yet (ECC errors)? Do you have something like ARM's #SError which can asynchronously hit at any time because of external bus (PCI) errors? Alex > > Regards, > Anup > >> >> >> Thanks, >> >> Alex
On 23/08/19 13:44, Graf (AWS), Alexander wrote: >> Overall, I'm quite happy with the code. It's a very clean implementation >> of a KVM target. Yup, I said the same even for v1 (I prefer recursive implementation of page table walking but that's all I can say). >> I will send v6 next week. I will try my best to implement unpriv >> trap handling in v6 itself. > Are you sure unpriv is the only exception that can hit there? What > about NMIs? Do you have #MCs yet (ECC errors)? Do you have something > like ARM's #SError which can asynchronously hit at any time because > of external bus (PCI) errors? As far as I know, all interrupts on RISC-V are disabled by local_irq_disable()/local_irq_enable(). Paolo
On Fri, Aug 23, 2019 at 5:40 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 23/08/19 13:44, Graf (AWS), Alexander wrote: > >> Overall, I'm quite happy with the code. It's a very clean implementation > >> of a KVM target. > > Yup, I said the same even for v1 (I prefer recursive implementation of > page table walking but that's all I can say). > > >> I will send v6 next week. I will try my best to implement unpriv > >> trap handling in v6 itself. > > Are you sure unpriv is the only exception that can hit there? What > > about NMIs? Do you have #MCs yet (ECC errors)? Do you have something > > like ARM's #SError which can asynchronously hit at any time because > > of external bus (PCI) errors? > > As far as I know, all interrupts on RISC-V are disabled by > local_irq_disable()/local_irq_enable(). Yes, we don't have per-CPU interrupts for async bus errors or non-maskable interrupts. The local_irq_disable() and local_irq_enable() affect all interrupts (excepts traps). Although, the async bus errors can certainly be routed to Linux via PLIC (interrupt-controller) as regular peripheral interrupts. Regards, Anup > > Paolo
On 23.08.19 14:19, Anup Patel wrote: > On Fri, Aug 23, 2019 at 5:40 PM Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> On 23/08/19 13:44, Graf (AWS), Alexander wrote: >>>> Overall, I'm quite happy with the code. It's a very clean implementation >>>> of a KVM target. >> >> Yup, I said the same even for v1 (I prefer recursive implementation of >> page table walking but that's all I can say). >> >>>> I will send v6 next week. I will try my best to implement unpriv >>>> trap handling in v6 itself. >>> Are you sure unpriv is the only exception that can hit there? What >>> about NMIs? Do you have #MCs yet (ECC errors)? Do you have something >>> like ARM's #SError which can asynchronously hit at any time because >>> of external bus (PCI) errors? >> >> As far as I know, all interrupts on RISC-V are disabled by >> local_irq_disable()/local_irq_enable(). > > Yes, we don't have per-CPU interrupts for async bus errors or > non-maskable interrupts. The local_irq_disable() and local_irq_enable() > affect all interrupts (excepts traps). Awesome, so that means you really only need to worry about traps. Even easier then! :) Also, you want to look out for a future extension that adds any of the above (NMI, MCE, SError on local bus), as that would then break the function ;) Alex