On Mon, Feb 23, 2026 at 11:47:47AM +0000, Daniel P. Berrangé wrote: > On Wed, Feb 18, 2026 at 01:05:26PM +0100, Andrea Bolognani via Devel wrote: > > Right now we don't allow any match in that scenario, but really > > if a specific type hasn't been requested it means that any type > > is considered acceptable and we should allow matching against > > both UEFI and BIOS. > > AFAICT, there is nothing in the callpath that would limit this to only > VMs of a certain architecture or machine. This new codepath only works > for architectures which are capable of supporting UEFI and that's only > x86, arm (virt machine), riscv (virt machine).
Or loongarch64 :) > For any other arch > or machine type we don't want TYPE_NONE to match this way. > > AFAICS, requiring an explicit "type" attribute for any firmware file > matching was part of thue mechanism to avoid impacting back compat for > existing XML configurations none of which will have set 'type'. Note that this is just *one* of the many criteria that need to be satisfied before declaring a match. If there is no JSON firmware descriptor, there will be no match. If there is no firmware binary that will work for the architecture or machine type available on the system, there will be no match. If the domain XML contains something extremely silly such as <loader type='pflash'>/usr/share/seabios/bios.bin</loader> there will be no match. So incorrect matches are not really a concern. On the other hand, right now when libvirt is presented with <loader>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> it is unable to fill in all the additional information that it already knows about, and that's quite unhelpful. But your comments made me realize that the way we're matching things is still incorrect/suboptimal even after these changes. I'll rework things based on that realization, and we can continue the discussion once that's done. -- Andrea Bolognani / Red Hat / Virtualization
