Re: [libvirt] OVMF exposure in libvirt

On Mon, Jul 14, 2014 at 09:32:34AM +0200, Michal Privoznik wrote: > Dear list, > > there's been a lot of development in QEMU on this part. And I think it's > settled down enough long so I can start looking at it. So I'd like to hear > you opinion what's the best way to expose this in libvirt. > > OVMF can bee looked at as a UEFI enablement in guest. Standard UEFI consists > of two parts: > > a) the firmware binary image (RO) > b) UEFI variables flash (RW) > > IIUC both of these are to be passed to qemu on the command line as: > > -drive file=img_1,if=pflash,format=raw,readonly \ > -drive file=img_2,if=pflash,format=raw > > Subsequently, -bios parameter should be dropped. The idea of splitting the > UEFI into two files allows distros to update the UEFI firmware (FW for > short) without modifying guest written UEFI variables file (the variables > should have unified name so they should be transferable between two versions > of UEFI FW). > > So my question is: how to expose this in the domain XML? We have the <os/> > element which handles the booting arguments. It can have <loader/> (which > would be great for the FW, wouldn't it?). But then we need to invent a > different element (say <vars/>) which would contain path the the UEFI vars > file. Moreover, the element would exclude other elements like <boot/>, > <bios/> or <smbios/>. So my proposal is: > > <os> > <type>hvm</type> > <loader>/path/to/uefi.fw</loader> > <vars>/path/to/uefi.nvvarstore</vars> > </os> > > Does this make any sense or am I just blabbing? We already use <loader/> for specifying alternative BIOS blobs for the QEMU -bios arg. Since you say this obsoletes the -bios arg, I think it makes sense to use <loader/> for the read-only firmware image. For the variable storage, I'd probably suggest <nvram/> as the element name, since IIUC that's a fairly commonly used term for this concept.