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.
This in turn removes the 'sev-snp-guest' capability from one of
our test cases as Peter's machine he uses to refresh capabilities
is not SEV capable. But that's okay. It's consistent with
'sev-guest' capability.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
int rc = -1;
virSEVCapability *caps = NULL;
- if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST))
+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST) &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_SNP_GUEST))
return 0;
if ((rc = qemuMonitorGetSEVCapabilities(mon, &caps)) < 0)
/* SEV isn't actually supported */
if (rc == 0) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV_GUEST);
+ virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV_SNP_GUEST);
return 0;
}
<flag name='display-reload'/>
<flag name='usb-mtp'/>
<flag name='virtio-sound'/>
- <flag name='sev-snp-guest'/>
<version>9000050</version>
<microcodeVersion>43100246</microcodeVersion>
<package>v9.0.0-1388-g80e8f06021-dirty</package>