7:54 a.m.
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 :|