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 :|