[libvirt] OVMF exposure in libvirt

[Michal Privoznik]

On 14.07.2014 16:12, 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.
>
>> 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

And how should the FW cmd line look like then?

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

Whoa. How to detect this? I mean, how do detect both?

>
> 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'.
>

Makes sense.

>> 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.
>
>> Additionally it would be great if we'd be able to
>> generate an empty nvram for a guest if the user doesn't specify it.

I'm not big fan of this. Pre-creating storage is something that should 
be done by mgmt applications (migration with non-shared storage is 
something different).

>
> Laszlo has OVMF patches to "auto-format" an all-zero nvram file.

Great. Do they work automagically or does libvirt need to enable the 
formatting somehow (e.g. monitor command, cmd line argument, ...)?

>
> Paolo