Roman Bogorodskiy wrote: > FWIW, I was able to resolve this and a couple of other minor issues > relatively simply. > > https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/59
Thanks for reviewing this one! > > > On QEMU side, use of UEFI has always required manual config specification, > > > though we have simplified the required XML now to just > > > > > > <os firmware='efi'/> > > > > > > where upon we auto-fill in the path to the UEFI loader. > > I noticed that bhyve actually supports this style of configuration as > well. > > > > As long as bhyve can do the auto-fill of UEFI path from this attribute > > > I think that's sufficiently simple. > > > > > > When using bhyveload, is there any firmware at all ? Or is it fully > > > paravirtualized in some way to avoid any firmware ? When using > > > <type>hvm</type> conceptually we would expect a firmware to be > > > present. > > > > In my understanding, it's not paravirtualized, in a way that it doesn't > > need special guests preparations and can load any reasonable general > > FreeBSD image. It doesn't need any firmware. It's based on the FreeBSD > > loader and knows how to load the FreeBSD kernel into memory. > > I was thinking about that, and it looks like in some cases driver > capabilities are probably not including enough information. > > Couple of examples of domain XMLs that libvirt-tck could generate: > > <domain type="bhyve"> > <name>tck</name> > <memory>1048576</memory> > <currentMemory>1048576</currentMemory> > <os> > <type arch="x86_64">hvm</type> > <kernel>/var/lib/libvirt-tck/libvirt-tck/os-x86_64-hvm/vmlinuz</kernel> > <initrd>/var/lib/libvirt-tck/libvirt-tck/os-x86_64-hvm/initrd</initrd> > </os> > <features> > <acpi /> > <apic /> > </features> > <devices> > <disk type="file"> > <driver /> > <source file="/var/lib/libvirt-tck/libvirt-tck/os-x86_64-hvm/disk.img" > /> > <target dev="vda" /> > </disk> > <rng model="virtio"> > <backend model="random" /> > </rng> > </devices> > </domain> > > I imagine that this is a valid configuration for qemu and probably other > drivers, but not for bhyve, because it doesn't support direct kernel > boot (neither for Linux nor FreeBSD). However, I wasn't able to find > anything similar in the driver's capabilities. If I'm not missing > anything, should drivers be able to advertise whether they support > direct kernel boot? > > Second example is pretty similar, but without the direct kernel bits: > > <domain type="bhyve"> > > > > <name>tck</name> > <memory>1048576</memory> > > > > <currentMemory>1048576</currentMemory> > <os> > <type arch="x86_64">hvm</type> > > <boot dev="hd" /> > > </os> > > <features> > <acpi /> > <apic /> > > </features> > > <devices> > > <disk type="file"> > > <driver /> > <source > file="/var/lib/libvirt-tck/libvirt-tck/os-x86_64-hvm/disk-fedora-40.img" /> > <target dev="vda" /> > </disk> > <rng model="virtio"> > <backend model="random" /> > </rng> > > </devices> > </domain> > > I imagine a config like is valid for qemu and many other drivers, but > it's valid for bhyve iff disk-fedora-40.img is a FreeBSD image. I think > in this should not be solved on the driver's capabilities reporting > level, because adding os_name details is probably way to specific. > > I wonder if it's a reasonable thing to extend bhyve's domain post parse > callback with a logic like: > > if (!domain.bootloader) > os.firmware = 'efi' > > Thus, it'll effectively switch default to efi firmware, but people who > only use bhyveload(8) will be able to continue using it by explicitly > specifying it as a bootloader. That'll, however, also require adding > generation of the proper <bootloader_args> if it's not specified, > because the current code assumes that the <bootloader> is not > bhyveload(8), so we don't know how to generate its arguments. For > bhyveload(8) we can generate a reasonable default if they're not > specified. > > Does this sound reasonable? Still would love to get feedback on this one before starting with the implementation. Thanks, Roman
