Re: [PATCH] qemu: Fix migration with disabled vmx-* CPU features

On a Monday in 2024, Jiri Denemark wrote: When starting a domain on a host which lacks a vmx-* CPU feature which is expected to be enabled by the CPU model specified in the domain XML, libvirt properly marks such feature as disabled in the active domain XML. But migrating the domain to a similar

Re: [PATCH v2] qemu: add support for qemu switchover-ack

On Mon, Jun 24, 2024 at 10:38:51 -0700, Jon Kohler wrote: > Add plumbing for QEMU's switchover-ack migration capability, which > helps lower the downtime during VFIO migrations. This capability is > enabled by default as long as both the source and destination support > it. > > Note: switchover-ac

Re: [PATCH v2] qemu_block: Validate number of hosts for iSCSI disk device

On Thu, Jun 06, 2024 at 19:57:51 +0530, Rayhan Faizel wrote: > An iSCSI device with zero hosts will result in a segmentation fault. This > patch > adds a check for the number of hosts, which must be one in the case of iSCSI. > > Minimal reproducing XML: > > > MyGuest > 4dea22b3-1d52-d8f

[PATCH 0/8] Expose SEV-SNP in domcaps and virt-host-validate

This is a promised follow up to: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7QQXVQXZATOIDYAJFOT45RPXRKX4GEWP/ Michal Prívozník (8): libvirt_private.syms: Export virDomainLaunchSecurity enum handlers qemuxmlconftest; Explicitly enable QEMU_CAPS_SEV_SNP_GUEST for

[PATCH 1/8] libvirt_private.syms: Export virDomainLaunchSecurity enum handlers

Signed-off-by: Michal Privoznik --- src/libvirt_private.syms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index bac4a8a366..f7a0a8bc36 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -497,6 +497,8 @@ virDomainIOT

[PATCH 4/8] domcaps: Report launchSecurity

In order to learn what types of are supported users can turn to domain capabilities and find and elements. While these may expose some additional info on individual launchSecurity types, we are lacking clean enumeration (like we do for say device models). And given that SEV and SEV SNP share the

[PATCH 6/8] qemu_validate: Use domaincaps to validate supported launchSecurity type

Now that the logic for detecting supported launchSecurity types has been moved to domain capabilities generation, we can just use it when validating launchSecurity type. Just like we do for device models and so on. Signed-off-by: Michal Privoznik --- src/qemu/qemu_validate.c | 29 ---

[PATCH 2/8] qemuxmlconftest; Explicitly enable QEMU_CAPS_SEV_SNP_GUEST for "launch-security-sev-snp"

Soon, QEMU_CAPS_SEV_SNP_GUEST is going to be dependant on more than plain presence of "sev-snp-guest" object in QEMU. Explicitly enable the capability for "launch-security-sev-snp" test so that we can continue testing cmd line and xml2xml. Signed-off-by: Michal Privoznik --- tests/qemuxmlconftes

[PATCH 5/8] qemu: Fill launchSecurity in domaincaps

The inspiration for these rules comes from qemuValidateDomainDef(). Signed-off-by: Michal Privoznik --- src/qemu/qemu_capabilities.c | 20 +++ src/qemu/qemu_capabilities.h | 3 +++ .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 3 +++ .../doma

[PATCH 7/8] virt-host-validate: Move AMD SEV into a separate func

The code that validates AMD SEV is going to be expanded soon. Move it into its own function to avoid lengthening virHostValidateSecureGuests() where the code lives now, even more. Signed-off-by: Michal Privoznik --- tools/virt-host-validate-common.c | 54 ++- 1 file c

[PATCH 3/8] qemu_capabilities: Probe SEV capabilities even for QEMU_CAPS_SEV_SNP_GUEST

While it's very unlikely to have QEMU that supports SEV-SNP but doesn't support plain SEV, for completeness sake we ought to query SEV capabilities if QEMU supports either. And similarly to QEMU_CAPS_SEV_GUEST we need to clear the capability if talking to QEMU proves SEV is not really supported. T

[PATCH 8/8] virt-host-validate: Detect SEV-ES and SEV-SNP

With a simple cpuid (Section "E.4.17 Function 8000_001Fh—Encrypted Memory Capabilities" in "AMD64 Architecture Programmer’s Manual Vol. 3") we can detect whether CPU is capable of running SEV-ES and/or SEV-SNP guests. Report these in virt-host-validate tool. Signed-off-by: Michal Privoznik --- t

[PATCH v1] security_manager: Ensure top lock is acquired before nested locks

We need to ensure top lock is acquired before nested lock. Otherwise deadlock issues may arise. We have the stack security driver, which internally manages other security drivers, we call them "top" and "nested". We call virSecurityStackPreFork() to lock the top one, and it also locks and then unl

[PATCH 0/2] qemu_command: Enable sev-guest.legacy-vm-type when possible

*** IMPORTANT *** There's a competing patch sent to qemu-devel which when merged renders these patches unnecessary: https://mail.gnu.org/archive/html/qemu-devel/2024-06/msg02776.html But I accumulated this change whilst working on previous patches that enabled SEV SNP and figured might as well s

[PATCH 2/2] qemu_command: Enable sev-guest.legacy-vm-type when possible

With recent enough QEMU (yet unreleased) there's 'legacy-vm-type' attribute of 'sev-guest' object. It controls whether QEMU uses newer or older interface to init SEV guests. As a result, the measurements (e.g. implemented in tools/virt-qemu-sev-validate) are affected. There's no clear benefit in sw

[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_SEV_GUEST_LEGACY_VM_TYPE

This capability tracks whether the sev-guest object has 'legacy-vm-type' attribute. It's going to be important later. Signed-off-by: Michal Privoznik --- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + tests/qemucapabilitiesdata/ca

Re: [PATCH 3/8] qemu_capabilities: Probe SEV capabilities even for QEMU_CAPS_SEV_SNP_GUEST

On Tue, Jun 25, 2024 at 11:48:48 +0200, Michal Privoznik wrote: > While it's very unlikely to have QEMU that supports SEV-SNP but > doesn't support plain SEV, for completeness sake we ought to > query SEV capabilities if QEMU supports either. And similarly to > QEMU_CAPS_SEV_GUEST we need to clear

Re: [PATCH 5/8] qemu: Fill launchSecurity in domaincaps

On Tue, Jun 25, 2024 at 11:48:50 +0200, Michal Privoznik wrote: > The inspiration for these rules comes from > qemuValidateDomainDef(). > > Signed-off-by: Michal Privoznik > --- ... > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index adaf5f9c26..4f9895ba9c 100644 >

Re: [PATCH 0/8] Expose SEV-SNP in domcaps and virt-host-validate

On Tue, Jun 25, 2024 at 11:48:45 +0200, Michal Privoznik wrote: > This is a promised follow up to: > > https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7QQXVQXZATOIDYAJFOT45RPXRKX4GEWP/ > > Michal Prívozník (8): > libvirt_private.syms: Export virDomainLaunchSecurity enum

Re: [PATCH 0/8] Expose SEV-SNP in domcaps and virt-host-validate

On Tue, Jun 25, 2024 at 01:54:59PM +0200, Jiri Denemark wrote: > On Tue, Jun 25, 2024 at 11:48:45 +0200, Michal Privoznik wrote: > > This is a promised follow up to: > > > > https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7QQXVQXZATOIDYAJFOT45RPXRKX4GEWP/ > > > > Michal Pr

Entering freeze for libvirt-10.5.0

I have just tagged v10.5.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue

[libvirt RFC PATCH 0/2] qemu: do not use deprecated options for new virtiofsd

Depends on https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/231 Ján Tomko (2): qemu: fill capabilities for virtiofsd qemu: do not use deprecated options for new virtiofsd src/conf/domain_conf.h | 1 + src/qemu/qemu_vhost_user.c | 59 + src/qemu/qemu_vhost_

[libvirt PATCH 1/2] qemu: fill capabilities for virtiofsd

Run the daemon with --print-capabilities first, to see what it supports. Signed-off-by: Ján Tomko --- src/conf/domain_conf.h | 1 + src/qemu/qemu_vhost_user.c | 58 ++ src/qemu/qemu_vhost_user.h | 12 src/qemu/qemu_virtiofs.c | 9 -- 4 fil

[libvirt PATCH 2/2] qemu: do not use deprecated options for new virtiofsd

Use the to-be-introduced virtiofsd capability to mark whether new options are safe to use. Depends on: https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/231 https://issues.redhat.com/browse/RHEL-7108 Signed-off-by: Ján Tomko --- src/qemu/qemu_vhost_user.c | 5 ++- src/qemu/qemu_virtiofs