[libvirt] OVMF exposure in libvirt

[Peter Krempa]

On 07/14/14 11:27, Daniel P. Berrange wrote:
> On Mon, Jul 14, 2014 at 09:32:34AM +0200, Michal Privoznik wrote:
>> Dear list,
>>
>> there's been a lot of development in QEMU on this part. And I think it's
>> settled down enough long so I can start looking at it. So I'd like to hear
>> you opinion what's the best way to expose this in libvirt.
>>
>> OVMF can bee looked at as a UEFI enablement in guest. Standard UEFI consists
>> of two parts:
>>
>> a) the firmware binary image (RO)
>> b) UEFI variables flash (RW)
>>
>> IIUC both of these are to be passed to qemu on the command line as:
>>
>>       -drive file=img_1,if=pflash,format=raw,readonly \
>>       -drive file=img_2,if=pflash,format=raw
>>
>> Subsequently, -bios parameter should be dropped. The idea of splitting the
>> UEFI into two files allows distros to update the UEFI firmware (FW for
>> short) without modifying guest written UEFI variables file (the variables
>> should have unified name so they should be transferable between two versions
>> of UEFI FW).
>>
>> So my question is: how to expose this in the domain XML? We have the <os/>
>> element which handles the booting arguments. It can have <loader/> (which
>> would be great for the FW, wouldn't it?). But then we need to invent a
>> different element (say <vars/>) which would contain path the the UEFI vars
>> file. Moreover, the element would exclude other elements like <boot/>,
>> <bios/> or <smbios/>. So my proposal is:
>>
>> <os>
>>   <type>hvm</type>
>>   <loader>/path/to/uefi.fw</loader>
>>   <vars>/path/to/uefi.nvvarstore</vars>
>> </os>
>>
>> Does this make any sense or am I just blabbing?
> 
> 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.
> 
> 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 prefer <nvram> too. 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. The
only problem here is that an empty variable store isn't in fact a zero
filled image, but has some structure.

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140714/58788456/attachment-0001.sig>