On Fri, Aug 22, 2014 at 10:41:13AM -0600, Eric Blake wrote: > On 08/21/2014 02:50 AM, Michal Privoznik wrote: > > Up to now, users can configure BIOS via the <loader/> element. With > > the upcoming implementation of UEFI this is not enough as BIOS and > > UEFI are conceptually different. For instance, while BIOS is ROM, UEFI > > is programmable flash (although all writes to code section are > > denied). Therefore we need new attribute @type which will > > differentiate the two. Then, new attribute @readonly is introduced to > > reflect the fact that some images are RO. > > > > Moreover, the OVMF (which is going to be used mostly), works in two > > modes: > > 1) Code and UEFI variable store is mixed in one file. > > 2) Code and UEFI variable store is separated in two files > > > > The latter has advantage of updating the UEFI code without losing the > > configuration. However, in order to represent the latter case we need > > yet another XML element: <nvram/>. Currently, it has no additional > > attributes, it's just a bare element containing path to the variable > > store file. > > > > > +++ b/docs/formatdomain.html.in > > @@ -102,7 +102,8 @@ > > ... > > <os> > > <type>hvm</type> > > - <loader>/usr/lib/xen/boot/hvmloader</loader> > > + <loader readonly='on' type='rom'>/usr/lib/xen/boot/hvmloader</loader> > > readonly='yes' is a bit more typical of other XML constructs. > > > + <nvram>/var/lib/libvirt/nvram/guest_VARS.fd</nvram> > > You chose <nvram> to be a sibling, rather than a child, of <loader>. Is > it legal to have <nvram> in isolation, or can it only appear when > <loader> is present? If the former, then you are okay; if the latter, > then I'd rather see it as a child than a sibling. <loader> is a long standing element whose contents is a string path. So from a back compatibility POV we can't make <nvram> be a child of that, even though it would make sense. 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