[libvirt] OVMF exposure in libvirt
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? Michal BTW OVMF stands for Open Virtual Machine Firmware.
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. 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 :|
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
On Mon, Jul 14, 2014 at 11:55:52AM +0200, Peter Krempa wrote:
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.
BTW, we I believe some non-x86 architectures would already like to have some nvram capability in libvirt, but I can't remember the details right now. 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 :|
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 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'.
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.
Laszlo has OVMF patches to "auto-format" an all-zero nvram file. Paolo
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 :|
Il 14/07/2014 16:43, 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 ?
unit=0 goes just up to the 4G limit (e.g. if it's 256k it occupies the 256K from fffc0000 to ffffffff). unit=1 goes just below that. So yes they affect the guest ABI. However, unit=0 contains the reset vector, so the <loader> must be unit=0 and <nvram> must be unit=1. Exchanging them makes little sense. Paolo
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
Il 18/07/2014 15:01, Michal Privoznik ha scritto:
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?
You use -bios for the firmware, and -drive (without unit=1) for the nvram.
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?
Do not bother. Just assume that people know what they're doing. Paolo
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
participants (4)
-
Daniel P. Berrange -
Michal Privoznik -
Paolo Bonzini -
Peter Krempa