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>
This adds initial support for virDomainGetBlockInfo() for the hyperv
driver. It currently supports:
- physical disk drives that are assigned to a vm
- virtual disk drives backed by a .VHD file that are local to the host
- other drives backed by local files (e.g. cdrom with a .iso)
It will fail to get allocation and physical values for any drives backed
by files that are not local to the host (e.g. on network shares)
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rather than using raw strings, create definitions for each subtype
string so that they can be re-used without needing to know the exact
string format.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With the hyperv driver, disks might have windows paths like
"c:\path\to\disk.vhdx". Currently, this function supports paths, but
only if they're in unix format.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When getting the xml description of a guest, check if secure boot is
enabled and set firmware features accordingly.
Also support firmware autoselection and honor the secure boot setting
when defining new vms from xml.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Remove some unused or over-broad includes from headers, push some
includes down to .c files when the only user is the implementation.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Always instantiate a 'virFileWrapperFd' (iohelper) to wrap the saveimage
file descriptor of a non-'sparse' format saveimage.
For 'sparse' images we also need to ensure that the FD returned when
opening the save image is an actual file FD (thus not the FD from the
helper process used to bypass root-squashed NFS) as qemu requires an
actual file in those cases.
This patch reworks 'qemuSaveImageOpen' to create the wrapper process
based on whether the 'wrapperFd' variable is non-NULL rather than
based on a combination of 'sparse' and 'bypass_cache' flags. The caller
will then based on the image format and the need for the wrapper use the
appropriate settings.
As with this patch all non-sparse images will always pass a pipe instead
of a file to qemu it also fixes problems with qemu-11.0 where the 'fd'
migration protocol rejects FDs which point to a file.
Resolves: https://issues.redhat.com/browse/RHEL-76301
Closes: https://gitlab.com/libvirt/libvirt/-/issues/850
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The two functions are for reverting a save image. They differ only on
what domain object is used (new one vs existing one). Merge the code
paths for existing VMs (for managed save restore) into
'qemuDomainRestoreInternal' and reuse it instead of
'qemuDomainObjRestore'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'sparse' uses a mode in qemu which requires direct access to the
file descriptior of the file itself. If we reside on root-squashed NFS
the FD from 'virQEMUFileOpenAs' may not actually be a file which would
not work with qemu.
Reject such a config with a better error message and add documentation
outlining the quirk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to 'virFileIsRegular' return if the FD is a regular file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After commit 517248e239 removed the previously-4th argument the
ATTRIBUTE_NONNULL(4) annotation no longer makes sense.
Fixes: 517248e239
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Either an error should be returned in all error paths in a
function or in none (leaving it up to caller). Well,
virPCIGetVirtualFunctionIndex() breaks this pattern. Fix it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Implement domainGetVcpuPinInfo for querying vcpu pinning information.
Also, implement a couple of other APIs this one depends on:
domainGetVcpusFlags and domainGetMaxVcpus.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Bhyve supports vcpu pinning using the `-p vcpu:hostcpu`
argument. This argument can be specified multiple times for the same
vcpu to pin it to multiple hostcpu's.
Bhyve currently does not allow to change vcpu pinning configuration for
the VM that is already running.
Use this to support domain's vcpupin configuration such as:
<cputune>
<vcpupin vcpu="0" cpuset="1,2,3"/>
</cputune>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When virDomainAbortJob is called with VIR_DOMAIN_ABORT_JOB_POSTCOPY flag
and the post-copy migration of the domain is already stopped (either
because of a failure or previous call to virDomainAbortJob), the
migrate-pause QMP command fails with "migrate-pause is currently only
supported during postcopy-active or postcopy-recover state". Such error
might be confusing to end users especially when we mark it as an
internal error. Let's not call the QMP command at all and report a
clear error message instead.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Adding a storage volume into a pool is done by calling
virStoragePoolObjAddVol(). This function may fail if another
volume already exists with the same key/name/target. In some
cases the storage driver does check for duplicates before calling
the function. But in some cases (e.g. when refreshing an RBD pool
in virStorageBackendRBDRefreshPool()) it doesn't.
The problem here is that the function reports no error upon
failure and leaves it as an exercise for caller. Well, no caller
does that.
Therefore, make the function report an error. The advantage of
this approach is - the function can report more accurate error
message than any caller ever could.
NB¸ this stems from a discussion on the users list [1], and while
this does NOT solve the original issue, it fixes one of the
symptoms.
1: https://lists.libvirt.org/archives/list/users@lists.libvirt.org/message/BALVNCRQM4KBKGV4RQ7BMKSX7UIJKLQH/
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When virStoragePoolGetAutostart(), virNetworkGetAutostart(), or
virNodeDeviceGetAutostart() fails, the respective info commands
report "no autostart". This is incorrect: the API failure means
we cannot determine the autostart state, not that autostart is
disabled.
The persistent field in the same functions already correctly
reports "unknown" on API failure. Apply the same pattern to the
autostart field for consistency and correctness.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The domuuid, net-uuid, and pool-uuid commands call vshError() when
GetUUIDString() fails, but unconditionally return true, which
vshCommandRun() maps to EXIT_SUCCESS. This means scripts checking
$? see success despite the error.
Return false on failure so the exit code correctly reflects the
error, consistent with other virsh commands.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@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>
On macOS we use flat namespace so we cannot have multiple mocks for the
same function.
Fixes: 63434db800
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For first host device we need to add iommufd object as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When removing last host device using IOMMUFD remove the iommufd object
as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We need to track if iommufd object was added to the VM when we add
hotplug support.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This cleans up creating QEMU command line and makes it easier when
adding hotplug support.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani
Jonathon Jongsma
Peter Krempa
Michal Privoznik
Roman Bogorodskiy
Jiri Denemark
Lucas Amaral
Pavel Hrdina