On Tue, Jul 02, 2019 at 02:11:02PM +0200, Sergio Lopez wrote: > 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 KVM-only machine type with fast > boot times, minimal attack surface (measured as the number of IO ports > and MMIO regions exposed to the Guest) and small footprint (specially > when combined with the ongoing QEMU modularization effort). > > Normally, other than the device support provided by KVM itself, > microvm only supports virtio-mmio devices. Microvm also includes a > legacy mode, which adds an ISA bus with a 16550A serial port, useful > for being able to see the early boot kernel messages. > > Microvm only supports booting PVH-enabled Linux ELF images. Booting > other PVH-enabled kernels may be possible, but due to the lack of ACPI > and firmware, we're relying on the command line for specifying the > location of the virtio-mmio transports. If there's an interest on > using this machine type with other kernels, we'll try to find some > kind of middle ground solution. > > This is the list of the exposed IO ports and MMIO regions when running > in non-legacy mode: > > address-space: memory > 00000000d0000000-00000000d00001ff (prio 0, i/o): virtio-mmio > 00000000d0000200-00000000d00003ff (prio 0, i/o): virtio-mmio > 00000000d0000400-00000000d00005ff (prio 0, i/o): virtio-mmio > 00000000d0000600-00000000d00007ff (prio 0, i/o): virtio-mmio > 00000000d0000800-00000000d00009ff (prio 0, i/o): virtio-mmio > 00000000d0000a00-00000000d0000bff (prio 0, i/o): virtio-mmio > 00000000d0000c00-00000000d0000dff (prio 0, i/o): virtio-mmio > 00000000d0000e00-00000000d0000fff (prio 0, i/o): virtio-mmio > 00000000fee00000-00000000feefffff (prio 4096, i/o): kvm-apic-msi > > address-space: I/O > 0000000000000000-000000000000ffff (prio 0, i/o): io > 0000000000000020-0000000000000021 (prio 0, i/o): kvm-pic > 0000000000000040-0000000000000043 (prio 0, i/o): kvm-pit > 000000000000007e-000000000000007f (prio 0, i/o): kvmvapic > 00000000000000a0-00000000000000a1 (prio 0, i/o): kvm-pic > 00000000000004d0-00000000000004d0 (prio 0, i/o): kvm-elcr > 00000000000004d1-00000000000004d1 (prio 0, i/o): kvm-elcr > > A QEMU instance with the microvm machine type can be invoked this way: > > - Normal mode: > > qemu-system-x86_64 -M microvm -m 512m -smp 2 \ > -kernel vmlinux -append "console=hvc0 root=/dev/vda" \ > -nodefaults -no-user-config \ > -chardev pty,id=virtiocon0,server \ > -device virtio-serial-device \ > -device virtconsole,chardev=virtiocon0 \ > -drive id=test,file=test.img,format=raw,if=none \ > -device virtio-blk-device,drive=test \ > -netdev tap,id=tap0,script=no,downscript=no \ > -device virtio-net-device,netdev=tap0 > > - Legacy mode: > > qemu-system-x86_64 -M microvm,legacy -m 512m -smp 2 \ > -kernel vmlinux -append "console=ttyS0 root=/dev/vda" \ > -nodefaults -no-user-config \ > -drive id=test,file=test.img,format=raw,if=none \ > -device virtio-blk-device,drive=test \ > -netdev tap,id=tap0,script=no,downscript=no \ > -device virtio-net-device,netdev=tap0 \ > -serial stdio
Please post metrics that compare this against a minimal Q35. With qboot it was later found that SeaBIOS can achieve comparable boot times, so it wasn't worth maintaining qboot. Data is needed to show that microvm is really a significant improvement over a minimal Q35. Stefan
signature.asc
Description: PGP signature