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

Boeuf, Sebastien sebastien.boeuf at intel.com
Mon Feb 25 18:53:18 UTC 2019

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.

What do you all think about this? Is there anything I missed that makes this proposal not feasible?

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

+ Miriam who is working on pit and apic on crosvm


Rust-vmm mailing list
Rust-vmm at lists.opendev.org<mailto:Rust-vmm at lists.opendev.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20190225/ed3700c5/attachment.html>

More information about the Rust-vmm mailing list