On Tue, Apr 22, 2025 at 05:15:32PM +0200, Roman Bogorodskiy wrote: > > > 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?
Yeah, we ought to come up with a way to express whether a driver can do direct kernel boot or not. Only virt tech that originated in a Linux context can typically do this (Xen, UserModeLinux, QEMU). At the same time though, for the TCK we could fudge it via the configuration file. We currently list the kernel+initrd in that config file, but we could make it accept an ISO image instead perhaps ? > > 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'm not sure I understand what the problem is in this example ? Are you saying that bhyve can only run FreeBSD guests, not Linux guests, or am I mis-interpreting ? > > 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 > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
