[Rust-VMM] [Rust-vmm] Goals for this list

[Dr. David Alan Gilbert]

* Boeuf, Sebastien (sebastien.boeuf at intel.com) wrote:
> Reviving this thread!
> 
> As Miriam mentioned, there's some ongoing work to support IOAPIC, PIC and PIT emulation being performed in userspace (https://bugs.chromium.org/p/chromium/issues/detail?id=908689), which is equivalent to irqchip=split. This is really great to see this happening, but I would like to go even one step further, and be able to support the equivalent of irqchip=off.
> 
> This use case means that KVM is not performing any emulation and that everything is left off to the userspace process. This would allow for running legacy free hypervisor, where IRQs would be always supported through MSI/MSI-X, hence using only the LAPIC. For this, we would need full LAPIC emulation to be designed in userspace, with no need for any IOAPIC/PIC/PIT.
> 
> The current blocker is the fact that MSI is tightly coupled with PCI, and there is no current upstream way to retrieve the MSI vectors associated with a device. But if we can find some mechanisms to communicate the MSI vectors chosen by the guest kernel down to the hypervisor about a device, we could definitely get rid of IOAPIC, hence reaching the end goal I'm talking about here. Just note that ACPI would be a good way for the guest to communicate those information with the VMM.

Would a new ACPI mechanism really be any easy than some really basic
PCI?  You don't really need to provide a true PCI hierarchy or anything.

Dave

> What do you all think about this? Is there anything I missed that makes this proposal not feasible?
> 
> Thanks,
> Sebastien
> ________________________________
> From: Dylan Reid [dgreid at google.com]
> Sent: Thursday, December 20, 2018 11:55 AM
> To: Paolo Bonzini; Miriam Zimmerman
> Cc: rust-vmm at lists.opendev.org
> Subject: Re: [Rust-VMM] [Rust-vmm] Goals for this list
> 
> 
> 
> On Thu, Dec 20, 2018, 7:34 AM Paolo Bonzini <pbonzini at redhat.com<mailto:pbonzini at redhat.com> wrote:
> On 20/12/18 16:05, Anthony Liguori wrote:
> > The two biggest sources of CVEs in KVM have been instruction emulation
> > and device emulation.  Moving the x86_emulate code to userspace and
> > rewritting it in Rust would eliminate one of the larger attack surfaces
> > in KVM and likewise, moving IO APIC and PIT emulation to userspace would
> > help a lot there too.
> >
> > On modern processors, LAPIC is handled almost entirely in hardware so
> > the remaining complexity in KVM is really around EPT handling and
> > hardware interaction.  I don't think either can reasonably be moved.
> 
> Note that userspace PIT/PIC/IOAPIC emulation is already supported by KVM
> (Linux 4.4 or newer I think; QEMU will make it the default for the q35
> machine type in the next release, for now you need -machine
> kernel_irqchip=split).
> 
> + Miriam who is working on pit and apic on crosvm
> 
> 
> Paolo
> 
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org<mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm

> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm

--
Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK