On Mon, Feb 23, 2026 at 11:22:41AM -0500, Andrea Bolognani wrote: > 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.
This is proving to be more of a challenge than I initially anticipated. Since these changes are not really prerequisites for introducing varstore support and simply ended up in the pile because I made them while working on that, I will pull them out of the series for now and come back with a new version once I've had the chance to spend some more time thinking things through. -- Andrea Bolognani / Red Hat / Virtualization
