We are not introducing additional API flags for varstore
handling since that would require unnecessary churn in all
libvirt-based apps, and the intent is the same: recreate
the UEFI variable storage, be it NVRAM or varstore, from its
template.
In order to clarify that the existing flags affect varstore
too, update their documentation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that everything else is in place, we can finally add the
firmware descriptors for the edk2 builds that use the uefi-vars
QEMU device.
Several existing test cases that were failing up until this
point can pass now. This includes firmware-auto-efi-varstore-q35,
firmware-auto-efi-varstore-aarch64 and
firmware-auto-efi-enrolled-keys-aarch64, which were only failing
because a matching firmware descriptor could not be found.
firmware-manual-efi-varstore-aarch64 also passes now, because
with the firmware descriptor in place libvirt is able to figure
out that the manually-provided path corresponds to a UEFI
firmware build, which means that the use of ACPI is fine.
The test cases using older version of QEMU still fail, as is
expected, though the error message is now slightly different and
reflect the actual reason why that is.
The qemufirmware and domaincaps tests are updated in the
expected ways. In particular, versions QEMU 10.0 and newer now
advertise varstore support as available.
https://issues.redhat.com/browse/RHEL-82645
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Before this, attempting to use a ROM that was not explictly
marked at read only resulted in an error at startup time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Simply mimicking what is currently done for NVRAM files does
the trick. A few user-visible messages are updated to reflect
the fact that they apply both to NVRAM and varstore.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Most of the code in the qemuPrepareNVRAMFile() function can
be reused to create a varstore file from template. Move the
common parts to a generic helper, leaving only the parts
that are NVRAM-specific in the original function.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce qemuFirmwareEnsureVarstore(), which performs the same
task as the existing qemuFirmwareEnsureNVRAM() but for the
varstore element.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This is the same as the existing nvramDir, except it will be
used to store the files used with the uefi-vars QEMU device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If the matching firmware requires the use of varstore, we
have to bubble up information about it, namely the path to
the template. If the struct member doesn't exist yet, we need
to allocate it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Stateful ROMs are those that use the uefi-vars QEMU device to
implement access to UEFI variable storage.
Matching works much the same as it does for pflash-based
firmware images. Notably, the <varstore> element is only
allowed for ROM and the <nvram> element is only allowed for
pflash.
The firmware-auto-efi-varstore-q35 and
firmware-auto-efi-varstore-aarch64 fail in a different way
after this change: the input XML is now considered valid, and
the only remaining issue is that the firmware autoselection
process is unable to find a match.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we only look at the value for the stateless attribute
itself when matching, but the <nvram> element being included in
the input XML is likewise a clear sign that a stateless firmware
build will not satisfy the user's requirements.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The element should only be advertised as supported if the QEMU
binary contains the necessary device and a suitable JSON firmware
descriptor is found on the system. Right now the latter
requirement is not satisfied, so it's marked as not supported
across the board.
The qemufirmware test is extended to cover the new attribute.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This was not necessary until now since ROMs couldn't have an
associate NVRAM template, and technically speaking they still
can't; however, the varstore template serves essentialy the
same purpose.
The qemuFirmwareGetSupported() helper is used in two places:
one is the code that is responsible for filling in domaincaps,
where templates are ignored so this change has no impact on it;
the other is the qemufirmware test program, where this value
being reported is useful as it will allow us to confirm that
the JSON firmware descriptors for uefi-vars enabled builds are
parsed correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The existing syntax can only describe stateless firmware builds,
while the extended one can additionally describe builds intended
for use with the uefi-vars device. This involves including the
path to the corresponding varstore template.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Just like with firmware builds targeting the confidential use
case, use of the uefi-vars device obviates the need to have SMM
emulation enabled while still guaranteeing that protected EFI
variables work as intended.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The two checks are semantically different, so it makes sense to
perform them separately. We will soon extend the first one.
While at it, start printing out the value of isConfidential. We
could print the value of each firmware feature it's derived from,
but that would make things unnecessarily verbose; at the same
time, knowing that libvirt believes that the firmware build is
targeting the confidential use case can be useful for debugging
so it's worth including it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When present in a firmware descriptor, this feature indicates that
the corresponding executable expects to access variable storage
through the uefi-vars QEMU device.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to automatically configure an
aarch64 guest so that Secure Boot support is available and only
signed operating systems are allowed to boot.
It currently fails because there is no firmware descriptor that
describes a suitable firmware build yet. That will change in a
future commit.
In addition to the latest version, the test case is also executed
against QEMU 8.2.0 specifically. This version of the test case is
intended to fail, because the uefi-vars device that we need to
support Secure Boot on aarch64 was not yet available in that
version of QEMU. The exact error message will change down the
line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to explicitly opt into using
the uefi-vars device for an aarch64 guest.
Normally the firmware autoselection process will pick a UEFI
build that is loaded via pflash, but by including the <varstore>
element in the input XML we can tell the QEMU driver that we
want want the uefi-vars device to be used instead.
Currently this results in an error, because the firmware
autoselection algorithm doesn't yet know how to properly handle
the scenario. A future commit will address this and make things
work as expected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to explicitly opt into using
the uefi-vars device for an x86_64 guest.
Normally the firmware autoselection process will pick a UEFI
build that is loaded via pflash, but by including the <varstore>
element in the input XML we can tell the QEMU driver that we
want want the uefi-vars device to be used instead.
Currently this results in an error, because the firmware
autoselection algorithm doesn't yet know how to properly handle
the scenario. A future commit will address this and make things
work as expected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to manually configure an aarch64
guest to use the uefi-vars device.
It currently fails because the QEMU driver does not yet recognize
the firmware type as EFI, and so rejects the attempt to use ACPI
together with it. That will change in a future commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates how to manually configure an x86_64
guest to use the uefi-vars device.
It fails when using an older version of QEMU which didn't have
the device, and succeeds when using the latest version. The
relevant bits of the QEMU command line are not generated yet,
but that will come in a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This capability indicates the availability of the uefi-vars
device.
The actual name of the QEMU device varies slightly depending on
the architecture: it's uefi-vars-x64 on x86_64, uefi-vars-sysbus
on other UEFI architectures (aarch64, riscv64, loongarch64).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The code is reworked quite significantly, but most of the
existing checks are preserved. Those that aren't, notably the
one that allowed pflash as the only acceptable non-stateless
firmware type, are intentionally removed because they will no
longer reflect reality once support for the uefi-vars QEMU
device is introduced.
As a side effect, reworking the function in this fashion
resolves a subtle bug: due to the early exits that were being
performed when the loader element was missing, the checks at
the bottom of the function (related to the shim and kernel
elements) were effectively never performed. This is no longer
the case.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will be used to configure the backing storage used by the
uefi-vars QEMU device.
Dealing with the element itself is trivial, however we have to
refactor the existing code which deals with the loader and nvram
elements slightly: in particular, we can no longer perform an
early exit if those elements are absent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This moves the definition of the <nvram> element out of the
fairly complex oshvm define and will make it easier to later
add the <varstore> element without making things unmanageable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Most of the JSON firmware descriptors in our test suite come from
the Fedora package for edk2, but there are a few additional ones
that we have created ourselves to ensure coverage of uncommon or
problematic scenarios.
In order to make sure that such descriptors are clearly marked as
custom, rename them to include the string "libvirt" in the path.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Right now we set this default in the common parsing code, which
is not a big problem per se but would get in the way of some
upcoming changes.
Leave this choice to individual drivers instead. Only the QEMU
and Xen drivers use the value for anything, so we can limit the
amount of code duplication this change causes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We only set the template format if the template path is present,
and we should be consistent with that. The format on its own is
not very interesting anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Recommend that users take advantage of firmware autoselection
and discourage providing paths manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The new name is much more accurate since the documentation is
applicable to firmware other than BIOS, notably UEFI.
An empty container is used to keep old links working.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
On architectures that support neither UEFI nor BIOS as firmware,
such as ppc64 and s390x, the enums end up empty. This correctly
indicates that filtering by firmware feature is not possible, and
is consistent with the fact that the existing "firmware" enum is
also empty in those cases, meaning that firmware autoselection
itself is just not applicable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we apply a 1:1 mapping between loader type and firmware
type: ROM can only match BIOS and pflash can only match UEFI.
That was accurate at the time when the check was introduced, but
is no longer the case today: the Intel TDX build of edk2, for
example, is loaded as a ROM but it still provides an UEFI
implementation to the guest.
Tweak the matching logic so that a ROM loader is allowed to match
both BIOS and UEFI firmware descriptors.
The firmware-manual-efi-tdx test case benefits from this change,
as all the missing information is now correctly filled in.
This will also solve an issue reported to the list, where
firmware builds targeting the confidential VM use case on aarch64
would not be usable at all, due to the way UEFI and ACPI are
depending on each other on the architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It's possible to have firmware descriptors for builds intended to
be loaded as ROM, as is the case for those loaded as pflash.
There is no reason to skip firmware autoselection in those cases,
and doing so prevents useful information from being filled in.
After this change, the firmware-manual-efi-tdx test case is
augmented with some additional information. Even more information
will be filled in later, when we improve the matching logic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates that firmware selection does not run
for domains manually configured to use the Intel TDX build of
edk2, and as a result some expected information is missing; in
particular, the fact that the firmware type is EFI is not
reflected in the domain XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test cases demonstrates that firmware selection runs for
domains manually configured to use the AMD SEV build of edk2, and
that the missing information (firmware features, as well as the
fact that firmware type is EFI) are correctly filled in.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the hack is gone, a few test cases that were failing
before start succeeding instead.
The firmware-auto-efi-format-nvramtemplate-qcow2 test case
originally passed but produced wrong results, then started
failing once we began taking templateFormat into account, and now
passes once again, finally producing the correct results.
The firmware-auto-efi-format-nvram-raw-loader-path and
firmware-auto-efi-format-nvram-raw-nvramtemplate-path test cases,
on the other hand, never passed before now, because the hack
resulted in information contradicting those provided by the user
being injected into the configuration, which in turn made it
impossible to successfully pick a firmware build. With the hack
gone they can finally succeed, as they should have in the first
place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit d3016e47be removed a hunk very similar to the one we're
adding with the rationale that there is no actual requirement for
the NVRAM file and the NVRAM template to have the same format,
which is completely correct: while libvirt will not perform the
format conversion itself, the user can do that on their own and
everything (except RESET_NVRAM) will work just fine.
That said, we also need <nvram format='foo'/> specified on its
own with no <loader> element to result in a firmware build with a
foo-formatted NVRAM template to be picked. Right now this works
thanks to the hack at the top of qemuFirmwareFillDomain() which
copies nvram.format to loader.format, but we want to get rid of
that because it has additional side effects that can lead to
confusing outcomes in certain specific scenarios.
So reintroduce this check, but make it extremely narrow: if any
other information that can influence firmware selection is
present in the domain XML, ignore the NVRAM format entirely; if
however the NVRAM format is the only information that was
provided, consider it when looking for a match.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the user has specified a desired format for the NVRAM
template, we should take that information into account when
looking for a suitable firmware build instead of ignoring it.
Two test cases start failing as a result of this change.
For firmware-auto-efi-format-nvramtemplate-qcow2, the failure
is temporary and the test case will pass once again with an
upcoming commit. It should be noted that, until now, the selected
firmware used raw, not qcow2, as the NVRAM template format,
meaning that though the test case passed the outcome was not the
desired one.
For firmware-auto-efi-format-mismatch-nvramtemplate, the failure
is desired and the test case should not have succeeded in the
first place, as there are no firmware descriptors for a build
that uses raw format for the executable and qcow2 format for the
NVRAM template.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we throw the entire definition away if the path is
not present, including the format. This effectively results in
discarding user-provided information.
This change fixes the firmware-auto-efi-format-mismatch test
case. Until now, the NVRAM format ended up being raw (matching
the NVRAM template) despite the user explicitly asking for it
to be qcow2 instead.
While this means that libvirt will no longer be able to start
such a VM without user intervention, since it does not
automatically perform conversion between formats, that's still
preferrable to silently overriding an explicit user's request.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the vast majority of cases they will match, but it just makes
more logical sense to copy the format from the NVRAM template to
the NVRAM file itself.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of setting the format every single time, knowing that we
might throw away the entire definition immediately afterwards,
and duplicating a check, only set it if we are going to perform
an early return due to the rest of the definition being properly
filled in already.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we're doing a weird dance to avoid overwriting the
user-provided path to the NVRAM template, which might potentially
be one we actually know about but just so happens not to be
listed first. Explaining why we're doing things this way requires
a fairly long comment.
We can make things simpler: if the NVRAM template path is present
in the domain XML, include it into the matching criteria. This is
consistent with how we match firmware descriptors.
Handling of format, both for the firmware executable and the
NVRAM template, is improved too. Legacy paths were used before
non-raw firmware builds existed, so we can set the format to raw
unconditionally.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If an NVRAM template is used, its format should be set too.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Simple helper for the case where completely custom firmware paths
are in use. It's quite trivial right now, but it will be expanded
slightly in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
While the test case passes, the outcome is not the desired one.
The domain XML explicitly requests that the format for the
firmware excutable is raw and the format for the NVRAM template
is qcow2: since there are no firmware descriptors that satisfy
these requirements, this should result in a failure. Instead, the
second request is simply ignored and a firmware that uses raw
format NVRAM template is selected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
While the test case passes, the outcome is not the desired one.
The domain XML explicitly requests that the NVRAM template is in
qcow2 format, and yet the selected firmware build uses the raw
format for the NVRAM template instead.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
There is no requirement for the format of the NVRAM file (raw in
this case) to match that of the NVRAM template (qcow2 in this
case), and yet libvirt incorrectly rejects the configuration.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates an issue with the current
implementation of firmware autoselection.
libvirt would normally be able to find the firmware descriptor
for the binary mentioned in the domain XML, but the fact that at
the same time we're asking for the NVRAM file to be of a
different format throws a spanner in the works.
Of course there is no requirement for the format of the NVRAM
file to match that of the NVRAM template, so the fact that
libvirt is unable to produce a working configuration out of this
input is an issues that will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates that it's possible to explicitly
select the format for the NVRAM template, and usually the
firmware binary itself, by using the <nvram format='foo'/>
shorthand syntax.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test cases demonstrates that it's possible to use a custom
NVRAM template together with a standard firmware binary even when
referring to the latter by its legacy path rather than its
modern, canonical one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates that it's possible to associate a
custom NVRAM template to a well-known firmware binary, specifying
its format, and libvirt will behave correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to how we allow the format for the loader and the NVRAM
file to be specified without the corresponding path being present,
we should allow that to happen for the NVRAM template too.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If this information is missing, the parsing code will consider
the firmware descriptor to be invalid and matching against it will
not even be attempted. So we can safely drop this redundant
fallback.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For combined firmware builds, the variable storage is part of the
same image as the executable code, whereas stateless builds don't
support variable storage at all.
In both cases, the use of a separate NVRAM storage area is not
supported, so if attributes connected to one are present in the
domain XML, firmware descriptors for stateless/combined builds
should be ignored.
ROM firmware builds are stateless by definition, so the same
handling applies to them as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The combination doesn't make sense.
After this change the firmware-auto-efi-format-loader-qcow2-rom
test case starts failing, as it should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates a flaw in the XML validation process.
ROM images are by definition in raw format, so attempting to use
any other format should have resulted in the domain XML being
rejected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The combination doesn't make sense.
After this change the firmware-manual-bios-rw test case starts
failing, as it should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates a flaw in the XML validation process.
ROM images are by definition read-only, so attempting to use one
as read/write should have resulted in the domain XML being
rejected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test cases demonstrates that the firmware autoselection
process is unable to find a BIOS image that is read/write.
This is expected, as BIOS is loaded as ROM and is thus by
definition read-only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The combination doesn't make sense.
After this change the firmware-manual-bios-rw test cases starts
failing, as it should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test case demonstrates a flaw in the XML validation process.
Read/write firmware images already contain an area dedicated to
variable storage, which they use, so attempting to use a separate
NVRAM file together with them should have resulted in the domain
XML being rejected.
The issue will be addressed in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As explained in the comment that comes along with it, this code
ensures that the user's preference is taken into account when
nvram.format is the only information that's provided. Currently
it lives in the parser, but it makes more sense for it to be
together with the rest of the firmware selection code instead.
Note that this move is not completely seamless: once the code
is moved outside of the parser, it can no longer reliably know
whether the <loader> element actually existed in the domain
XML. The difference is subtle enough that the test suite is
completely unaffected, and we are going to rework the handling
of this scenario in a way that restores the original behavior
later anyway, so it ultimately doesn't matter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We currently apply this exception, which is critical to ensure
that the correct firmware is selected when working with older VMs,
in the postparse callback.
Move it to the firmware selection process instead, where it should
have been added in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We access the NVRAM information via the 'loader' local variable
throughout the file, and this is the only spot where the 'nvram'
local variable exists. It makes things inconsistent and opens up
the possibility of the values for 'loader' and 'nvram' going out
of sync, especially after a future commit will introduce the
need to set the former. Just get rid of the additional variable.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I have been able to find exactly zero evidence of this type of
firmware descriptor actually existing in the wild, so this is
essentialy dead code. Dropping it simplifies the task of further
tweaking the firmware selection code.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The idea of adding devices such as USB controllers or memory
balloons by default comes from attempting to match QEMU's own
defaults at a time when x86 was the only game in town.
The unfortunate consequence of this is that, if the user does
NOT want the device in question to be present, they have to
create a special XML element with model=none to stop libvirt.
This is counter-intuitive.
For architectures for which we've added support more recently,
such as aarch64 and loongarch64, we've generally chosen to do
the sensible thing and create very minimal guests by default.
The user is of course still able to ask for additional hardware
if they so desire.
When adding RISC-V support, we accidentally forgot to skip the
creation of the default memory balloon. Address that oversight.
This is technically a breaking change, but it's fairly safe to
apply it because:
* it doesn't affect existing guests;
* virt-manager will automatically add the memballoon device
by default anyway;
* RISC-V is still not widely used.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are still a couple of scenarios in which we end up
using the Intel-specific piix3-uhci (USB1) controller for
non-x86 guests.
Remove these uses, leaving the generic pci-ohci (USB1)
controller as either the fallback or default for situations
where no better choice can be made.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is another case where the current behavior can be traced
back to the fact that x86 was the only architecture to really
be taken into account for a long time: in reality, using an
Intel-specific USB1 controller for a modern, PCIe-native,
virtualization-friendly Arm guest just doesn't make any sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have special behavior for these two machine types, and
more specifically for the USB controller that they get added
by default - something that doesn't generally happen on Arm.
Not only this is inconsistent with other machine types for
the architecture, it also means that the model for the USB
controller that gets added automatically (pci-ohci, USB1) is
worse than the default one for user-added USB controllers
(qemu-xhci, USB3) which is just silly.
Bring these machine types in line with the rest of the
architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we differentiate between 64-bit and 32-bit
architectures, which doesn't seem very reasonable
considering that the same machine types are available
in both cases. Remove this inconsistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar to loongarch64, the current behavior is a result
of the way the existing code was written rather than a
consequence of an intentional choice. Make the two
architectures behave the same way, as they should have
from the start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture was introduced at a time when USB3 in
general, and qemu-xhci in particular, had already been
well established for years. Having USB1 controllers as a
fallback was something that happened by mistake due to
the way the pre-existing code was organized rather than
because of a conscious decision. Make things work the
way they should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch from the current approach, in which an initial and
likely poor default is picked and then a better one later
overwrites it, to the more common and easy to reason about
pattern where the value is returned directly as soon as
possible.
To make things easier to understand and more maintainable,
the various architectures for which we have explicit
handling are each taken care of separately, with no falling
through to the default behavior.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the code in qemuDomainControllerDefPostParse(),
which we have just factored into its own function, we also have
some code in qemuDomainDefAddDefaultDevices() that deals with
choosing the USB controller model for a couple of specific
machine types.
Once again, extract the logic to a dedicated helper. The
behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the logic from qemuDomainControllerDefPostParse() to
a dedicated helper. The behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now we call qemuValidateDomainDeviceDefControllerUSB()
quite late, just as we're generating the QEMU command line.
The original intention was likely to prevent configurations
from being rejected, even though a default USB controller
model could not be found, because using -usb could be used
as a last resort.
As it turns out, this premise was always flawed: in order
for -usb to work, the underlying device still needs to be
compiled into QEMU, and if that was the case then the
earlier code would have detected its presence and set the
model name accordingly.
More recently, we have dropped the use of -usb altogether
so there's simply no longer anything to fall back to.
With all this in mind, we can move the validation step much
earlier, making for a better user experience as any issues
will be reported when the domain is defined rather than when
an attempt is made to start it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is not useful right now, because the function is simply
not called at all for model=none USB controllers, but that's
going to change in a moment, when we start calling the
function during validation instead of command line generation.
Making this change ahead of time means that we can simply
move the code verbatim later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Attempting to use a USB controller that's a PCI device with
a machine type that doesn't support PCI should result in an
error.
Note that, while all USB controllers supported by the libvirt
QEMU driver today are PCI devices, QEMU itself implements
machine types that come with non-PCI USB controllers. Having
a separate helper with a switch/case statement ensures that
things will need to be updated accordingly if libvirt will
ever grow support for those USB controllers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This makes the signature consistent with that of other
qemuValidateDomainDeviceDefController*() functions, which
are passed a virDomainDef along with the existing
virDomainControllerDef. Later changes to this function
will require access to the additional data structure.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
That obviously doesn't make sense, since the value is used
to indicate the absence of a USB controller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When support for s390x was introduced in libvirt, it naturally
followed the conventions established at the time for x86, which
were to have a USB controller added by default.
Later, in 2013, commit 3a82f628a9 made the default USB
controller model for s390x VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE,
effectively overriding the architecture-independent default.
However, an exception was carved out at the time: if the USB
controller had an address assigned to it, then it would be left
alone.
A couple of years later, commit 09ab9dcc85 changed things
again in two ways: for starters, libvirt would no longer
automatically attempt to add a USB controller to newly-defined
s390x guests; moreover, the command line generator was changed
so that the legacy USB controller (-usb) would never be used
on s390x.
In other words, unless a model name is explicitly provided for
the USB controller, which is something that only actually works
when using a recent QEMU version (see commit f9ed4d385a),
s390x guests will never have USB controllers attached to them.
Remove the exception carved out a decade ago and always
reflect this fact accurately in the guest XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These checks enforce some expectations that were, until now,
documented solely through comments or not spelled out at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The sparc architecture doesn't support PCI, and neither do the
isapc and microvm machine types on x86 architectures.
One of the isapc/microvm tests starts failing as a consequence
of this change, which is expected; somewhat surprisingly,
another test for the same machine types goes from an early/hard
failure (PARSE_ERROR) to a late/soft one (FAILURE) instead.
This will be rectified by a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuValidateDomainDeviceDefControllerPCI() function is
called if PCI controllers are present in the domain
configuration, which shouldn't happen if the machine type
doesn't support PCI. If we somehow find ourselves in that
scenario, reporting an error would be the right thing to do.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the moment, we check whether the machine type supports PCI
before attempting to allocate PCI addresses, and if it does
not, we simply skip the step entirely.
This means that an attempt to use a PCI device with a machine
type that has no PCI support won't be rejected by libvirt, and
only once the QEMU process is started the problem will be made
apparent.
Validate things ahead of time instead, rejecting any such
configurations.
Note that we only do this for new domains, because otherwise
existing domains that are configured incorrectly would disappear
and we generally try really hard to avoid that.
A few tests start failing after this change, demonstrating that
things are now working as desired.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani