[libvirt] OVMF exposure in libvirt

[Daniel P. Berrange]

On Mon, Jul 14, 2014 at 04:12:14PM +0200, Paolo Bonzini wrote:
> Il 14/07/2014 11:27, Daniel P. Berrange ha scritto:
> >      -drive file=img_1,if=pflash,format=raw,readonly \
> >      -drive file=img_2,if=pflash,format=raw
> 
> It's safer to add ",unit=0" and ",unit=1" too.

Is there any compelling reason to make the unit numbers user
configurable. Are they guest ABI sensitive for example ?

If so, we're kind of screwed with <loader> because we can't
add a <address> sub-element to it as we do for ABI addressing
elsewhere.

> >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.
> 
> It obsoletes the -bios argument, but it is not the same thing:
> 
> 1) on some machines you can use "-drive if=pflash" for the nvram, but not
> for the firmware
> 
> 2) on some older versions of QEMU, "-drive if=pflash" will work only on TCG
> or will not work at all so you cannot blindly replace it.
> 
> What about:
> 
>    <loader readonly='on|off' type='rom|flash'>...</loader>
>    <nvram>...</nvram>
> 
> where the mapping from <nvram> to -drive if=flash is partly
> machine-dependent.  On x86, for example, <nvram> adds the ",unit=1"
> sub-option and fails if the <loader> element is absent; it also fails if
> <loader> has type='rom'.

That sounds reasonable to me.

> 
> >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 like this.


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