> >>> Microvm is a machine type inspired by both NEMU and Firecracker, and > >>> constructed after the machine model implemented by the latter. > >>> > >>> It's main purpose is providing users a minimalist machine type free > >>> from the burden of legacy compatibility, serving as a stepping stone > >>> for future projects aiming at improving boot times, reducing the > >>> attack surface and slimming down QEMU's 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 > >>> - MC146818 RTC (optional) > >>> - kvmclock (if using KVM) > >>> - fw_cfg > >>> - One ISA serial port (optional) > >>> - Up to eight virtio-mmio devices (configured by the user) > >> > >> So I assume also no ACPI (CPU/memory hotplug), correct? > > > > Correct. > > > >> @Pankaj, I think it would make sense to make virtio-pmem play with > >> virtio-mmio/microvm. > > > > That would be great. I'm also looking forward for virtio-mem (and an > > hypothetical virtio-cpu) to eventually gain hotplug capabilities in > > microvm. > > @Pankaj, do you have time to look into the virtio-pmem thingy? I guess > the virtio-mmio rapper shouldn't be too hard (very similar to the > virtio-pci wrapper - luckily I insisted to make it work independently > from PCI BARs and ACPI slots ;) ). The microvm bits would be properly > setting up device memory and wiring up the hotplug handlers, similar as > done in the other PC machine types (maybe that comes for free?). Yes, I can look at. > > virtio-pmem will allow (in read-only mode) to place the rootfs on a fake > NVDIMM, as done e.g., in kata containers. We might have to include the > virtio-pmem kernel module in the initramfs, shouldn't be too hard. Not > sure what else we'll need to make virtio-pmem get used as a rootfs. Sure, will work on it. Thanks, Pankaj > > > > > Thanks, > > Sergio. > > > > > -- > > Thanks, > > David / dhildenb > >
