Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 24/09/19 14:44, Sergio Lopez wrote: >> +Microvm is a machine type inspired by both NEMU and Firecracker, and >> +constructed after the machine model implemented by the latter. > > I would say it's inspired by Firecracker only. The NEMU virt machine > had virtio-pci and ACPI. > >> +It's main purpose is providing users a minimalist machine type free >> +from the burden of legacy compatibility, > > I think this is too strong, especially if you keep the PIC and PIT. :) > Maybe just "It's a minimalist machine type without PCI support designed > for short-lived guests". > >> +serving as a stepping stone >> +for future projects aiming at improving boot times, reducing the >> +attack surface and slimming down QEMU's footprint. > > "Microvm also establishes a baseline for benchmarking QEMU and operating > systems, since it is optimized for both boot time and footprint". > >> +The microvm machine type supports the following devices: >> + >> + - ISA bus >> + - i8259 PIC >> + - LAPIC (implicit if using KVM) >> + - IOAPIC (defaults to kernel_irqchip_split = true) >> + - i8254 PIT > > Do we need the PIT? And perhaps the PIC even? > I'm going back to this level of the thread, because after your suggestion I took a deeper look at how things work around the PIC, and discovered I was completely wrong about my assumptions. For virtio-mmio devices, given that we don't have the ability to configure vectors (as it's done in the PCI case) we're stuck with the ones provided by the platform PIC, which in the x86 case is the i8259 (at least from Linux's perspective). So we can get rid of the IOAPIC, but we need to keep the i8259 (we have both a userspace and a kernel implementation too, so it should be fine). As for the PIT, we can omit it if we're running with KVM acceleration, as kvmclock will be used to calculate loops per jiffie and avoid the calibration, leaving it enabled otherwise. Thanks, Sergio.
Attachment:
signature.asc
Description: PGP signature
