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