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

Boeuf, Sebastien sebastien.boeuf at intel.com
Tue Feb 26 00:48:49 UTC 2019


On Mon, 2019-02-25 at 15:32 -0800, Miriam Zimmerman wrote:
> 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.

Yes, Steve's presentation summarizes it well.

Gerry, I think you mentioned some work you did using NetBSD and uKVM
regarding the LAPIC emulation being done in userspace, right?
How were the performances?
Do you have some pointers to the code?

Thanks,
Sebastien

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


More information about the Rust-vmm mailing list