On 08/08/14 14:05, Paolo Bonzini wrote:
> Il 08/08/2014 12:17, Michal Privoznik ha scritto:
>> When using split UEFI image, it may come handy if libvirt manages per
>> domain _VARS file automatically. While the _CODE file is RO and can
>> be shared among multiple domains, you certainly don't want to do that
>> on the _VARS file. This latter one needs to be per domain. So at the
>> domain startup process, if it's determined that domain needs _VARS
>> file it's copied from this master _VARS file. The location of the
>> master file is configurable in qemu.conf and the default path can be
>> compiled in via --with-qemu-nvram-file configure option.
>
> The only problem I see with this series is in this patch.
>
> The master _VARS file can be different for different machine types,
> for different architectures, and even for different _CODE files.
(I wasn't CC'd on the patch series, and I'm not a subscriber either, but
I now imported the set from the archive and hopefully can reply
in-thread.)
So, my suggestion was, for "src/qemu/qemu.conf":
# Locations of master nvram files
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# using this master file as image.
#
# Different firmware binaries can have different nvram templates;
# the following list specifies the mapping. Separate the
# nvram template from the firmware binary with a colon (":").
#
# nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]
Michal then asked if we should maybe even say:
nvram = [ "x86_64:/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
"i686:/usr/share/OVMF32/OVMF_CODE.fd:/usr/share/OVMF32/OVMF_VARS.fd" ]
I don't think so. "x86_64:/usr/share/OVMF/OVMF_CODE.fd" does not carry
more information than just "/usr/share/OVMF/OVMF_CODE.fd".
The firmware binary itself determines the valid architectures and the
nvram template; there's no additional "degree of freedom" in that
selection. That is, we do NOT have:
(guest architecture, firmware binary) --> nvram template
instead we have:
firmware binary --> (
{ set of valid architectures / machtypes },
nvram template
)
It is the user's responsibility to match architecture (machine type) and
firmware binary in the domain XML against each other.
- If they specify a firmware binary that is wrong for the architecture,
the firmware simply won't run. (No different from trying to boot an OS
that doesn't match the architecture.)
- If they specify the correct firmware binary, then it's *only* the
firmware binary that libvirt needs to look at, in order to determine
the nvram template.
Thanks,
Laszlo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list