Re: [libvirt] [PATCH v1 3/3] qemu: Automatically create NVRAM store
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