Re: [libvirt] OVMF exposure in libvirt

On 07/14/14 11:27, Daniel P. Berrange wrote: > 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. I prefer <nvram> too. Additionally it would be great if we'd be able to generate an empty nvram for a guest if the user doesn't specify it. The only problem here is that an empty variable store isn't in fact a zero filled image, but has some structure.