[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 @@
> >    ...
> >    &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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]