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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list