Re: [PATCH 06/25] qemu: Add basic framework for 'microvm' machine type

On Wed, Feb 28, 2024 at 06:35:46AM -0800, Andrea Bolognani wrote: > On Tue, Feb 27, 2024 at 05:36:08PM +0100, Peter Krempa wrote: > > @@ -4157,6 +4158,14 @@ qemuDomainDefAddDefaultDevices(virQEMUDriver *driver, > > switch (def->os.arch) { > > case VIR_ARCH_I686: > > case VIR_ARCH_X86_64: > > + /* don't add anything for microvm */ > > + if (qemuDomainIsMicrovm(def)) { > > + /* explicitly add 'none' USB controller */ > > + usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE; > > + addDefaultUSB = true; > > + break; > > + } > > I'm not terribly keen on seeing support for microvm officially > introduced in libvirt. > > AFAIK nobody ever asked for it, and given that the intended use case > for the machine type is specifically to have incredibly minimal, fast > booting VMs, to the extent where trimmed out kernels and even custom > firmware implementations are employed to shave every last possible > microsecond off the boot time, I really don't expect that anyone > would ever consider using libvirt to manage them. What you describe is one use case for microvm, but more generally I'd say microvm provides a "legacy free" machine type. Q35 is still a legacy platform, just a little less legacy than i440fx. By eliminating legacy platform features, microvm reduces the guest machine attack surface. As such, I think it is conceptially relevant to want to use microvm for general purpose guest OS, while not caring about its supposed performance differences.