qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 7/8] docs/microvm.txt: document the new microvm machine ty


From: Sergio Lopez
Subject: Re: [PATCH v4 7/8] docs/microvm.txt: document the new microvm machine type
Date: Wed, 25 Sep 2019 17:04:19 +0200
User-agent: mu4e 1.2.0; emacs 26.2

Paolo Bonzini <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]