Re: [libvirt] [PATCH v4 1/3] conf: Extend <loader/> and introduce <nvram/>

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 @@ > ... > &lt;os&gt; > &lt;type&gt;hvm&lt;/type&gt; > - &lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt; > + &lt;loader readonly='on' type='rom'&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt; readonly='yes' is a bit more typical of other XML constructs. > + &lt;nvram&gt;/var/lib/libvirt/nvram/guest_VARS.fd&lt;/nvram&gt; 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.