[libvirt] OVMF exposure in libvirt

[Daniel P. Berrange]

On Mon, Jul 14, 2014 at 11:55:52AM +0200, Peter Krempa wrote:
> 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.

BTW, we I believe some non-x86 architectures would already like to have
some nvram capability in libvirt, but I can't remember the details right
now.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|