<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<div>Reviving this thread!</div>
<div><br>
</div>
<div>As Miriam mentioned, there's some ongoing work to support IOAPIC, PIC and PIT emulation being performed in userspace (<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=908689" target="_blank">https://bugs.chromium.org/p/chromium/issues/detail?id=908689</a>),
 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>What do you all think about this? Is there anything I missed that makes this proposal not feasible?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Sebastien<br>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF717684" style="direction: ltr;"><font size="2" face="Tahoma" color="#000000"><b>From:</b> Dylan Reid [dgreid@google.com]<br>
<b>Sent:</b> Thursday, December 20, 2018 11:55 AM<br>
<b>To:</b> Paolo Bonzini; Miriam Zimmerman<br>
<b>Cc:</b> rust-vmm@lists.opendev.org<br>
<b>Subject:</b> Re: [Rust-VMM] [Rust-vmm] Goals for this list<br>
</font><br>
</div>
<div></div>
<div>
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Dec 20, 2018, 7:34 AM Paolo Bonzini <<a href="mailto:pbonzini@redhat.com" target="_blank" rel="noopener noreferrer">pbonzini@redhat.com</a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
On 20/12/18 16:05, Anthony Liguori wrote:<br>
> The two biggest sources of CVEs in KVM have been instruction emulation<br>
> and device emulation.  Moving the x86_emulate code to userspace and<br>
> rewritting it in Rust would eliminate one of the larger attack surfaces<br>
> in KVM and likewise, moving IO APIC and PIT emulation to userspace would<br>
> help a lot there too.<br>
> <br>
> On modern processors, LAPIC is handled almost entirely in hardware so<br>
> the remaining complexity in KVM is really around EPT handling and<br>
> hardware interaction.  I don't think either can reasonably be moved.<br>
<br>
Note that userspace PIT/PIC/IOAPIC emulation is already supported by KVM<br>
(Linux 4.4 or newer I think; QEMU will make it the default for the q35<br>
machine type in the next release, for now you need -machine<br>
kernel_irqchip=split).<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">+ Miriam who is working on pit and apic on crosvm</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<br>
Paolo<br>
<br>
_______________________________________________<br>
Rust-vmm mailing list<br>
<a href="mailto:Rust-vmm@lists.opendev.org" rel="noreferrer" target="_blank">Rust-vmm@lists.opendev.org</a><br>
<a href="http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm" rel="noreferrer noreferrer" target="_blank">http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>