Roman Bogorodskiy wrote: > I think I'll update the domain builder code to use either sata or ide, > based on what is available as reported by domain capabilities. At least > when the bus is not explicitly requested by the test.
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 > > 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? Thanks, Roman
