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

[Miriam Zimmerman]

On Mon, Feb 25, 2019 at 10:53 AM 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.

Thanks for your interest! It's great to know that the work I'm doing
will be more broadly useful! :-)

> 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.

I believe that the Google Cloud folks tried using a userspace LAPIC,
but when they benchmarked, the performance was unacceptably bad.
(since LAPICs are used much more frequently than IOAPICs/PICs/PITs)

I can't watch it right now to confirm, but I believe the "Performant
Security Hardening of KVM" from KVM forum 2016
(http://www.linux-kvm.org/page/KVM_Forum_2016) goes into some more
detail on this.

> 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?
>
> Thanks,
> Sebastien

Miriam