Most of the current 'query-sev' command is relevant to both legacy
SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions:
- 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and
the meaning of the bit positions has changed
- 'handle' is not relevant to SEV-SNP
To address this, this patch adds a new 'sev-type' field that can be
used as a discriminator to select between SEV and SEV-SNP-specific
fields/formats without breaking compatibility for existing management
tools (so long as management tools that add support for launching
SEV-SNP guest update their handling of query-sev appropriately).
The corresponding HMP command has also been fixed up similarly.
Signed-off-by: Michael Roth <michael.roth@amd.com>
---
qapi/misc-target.json | 71 +++++++++++++++++++++++++++++++++---------
target/i386/monitor.c | 29 +++++++++++++----
target/i386/sev.c | 22 +++++++------
target/i386/sev_i386.h | 3 ++
4 files changed, 95 insertions(+), 30 deletions(-)
diff --git a/qapi/misc-target.json b/qapi/misc-target.json
index 3b05ad3dbf..80f994ff9b 100644
--- a/qapi/misc-target.json
+++ b/qapi/misc-target.json
@@ -81,6 +81,49 @@
'send-update', 'receive-update' ],
'if': 'TARGET_I386' }
+##
+# @SevGuestType:
+#
+# An enumeration indicating the type of SEV guest being run.
+#
+# @sev: The guest is a legacy SEV or SEV-ES guest.
+# @sev-snp: The guest is an SEV-SNP guest.
+#
+# Since: 6.2
+##
+{ 'enum': 'SevGuestType',
+ 'data': [ 'sev', 'sev-snp' ],
+ 'if': 'TARGET_I386' }
+
+##
+# @SevGuestInfo:
+#
+# Information specific to legacy SEV/SEV-ES guests.
+#
+# @policy: SEV policy value
+#
+# @handle: SEV firmware handle
+#
+# Since: 2.12
+##
+{ 'struct': 'SevGuestInfo',
+ 'data': { 'policy': 'uint32',
+ 'handle': 'uint32' },
+ 'if': 'TARGET_I386' }
+
+##
+# @SevSnpGuestInfo:
+#
+# Information specific to SEV-SNP guests.
+#
+# @policy: SEV-SNP policy value
+#
+# Since: 6.2
+##
+{ 'struct': 'SevSnpGuestInfo',
+ 'data': { 'policy': 'uint64' },
+ 'if': 'TARGET_I386' }
+
##
# @SevInfo:
#
@@ -94,25 +137,25 @@
#
# @build-id: SEV FW build id
#
-# @policy: SEV policy value
-#
# @state: SEV guest state
#
-# @handle: SEV firmware handle
+# @sev-type: Type of SEV guest being run
#
# Since: 2.12
##
-{ 'struct': 'SevInfo',
- 'data': { 'enabled': 'bool',
- 'api-major': 'uint8',
- 'api-minor' : 'uint8',
- 'build-id' : 'uint8',
- 'policy' : 'uint32',
- 'state' : 'SevState',
- 'handle' : 'uint32'
- },
- 'if': 'TARGET_I386'
-}
+{ 'union': 'SevInfo',
+ 'base': { 'enabled': 'bool',
+ 'api-major': 'uint8',
+ 'api-minor' : 'uint8',
+ 'build-id' : 'uint8',
+ 'state' : 'SevState',
+ 'sev-type' : 'SevGuestType' },
+ 'discriminator': 'sev-type',
+ 'data': {
+ 'sev': 'SevGuestInfo',
+ 'sev-snp': 'SevSnpGuestInfo' },
+ 'if': 'TARGET_I386' }
+
##
# @query-sev:
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 119211f0b0..85a8bc2bef 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -692,20 +692,37 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict)
{
SevInfo *info = sev_get_info();
- if (info && info->enabled) {
- monitor_printf(mon, "handle: %d\n", info->handle);
+ if (!info || !info->enabled) {
+ monitor_printf(mon, "SEV is not enabled\n");
+ goto out;
+ }
+
+ if (sev_snp_enabled()) {
monitor_printf(mon, "state: %s\n", SevState_str(info->state));
monitor_printf(mon, "build: %d\n", info->build_id);
monitor_printf(mon, "api version: %d.%d\n",
info->api_major, info->api_minor);
monitor_printf(mon, "debug: %s\n",
- info->policy & SEV_POLICY_NODBG ? "off" : "on");
- monitor_printf(mon, "key-sharing: %s\n",
- info->policy & SEV_POLICY_NOKS ? "off" : "on");
+ info->u.sev_snp.policy & SEV_SNP_POLICY_DBG ? "on"
+ : "off");
+ monitor_printf(mon, "SMT allowed: %s\n",
+ info->u.sev_snp.policy & SEV_SNP_POLICY_SMT ? "on"
+ : "off");
+ monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
} else {
- monitor_printf(mon, "SEV is not enabled\n");
+ monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
+ monitor_printf(mon, "state: %s\n", SevState_str(info->state));
+ monitor_printf(mon, "build: %d\n", info->build_id);
+ monitor_printf(mon, "api version: %d.%d\n",
+ info->api_major, info->api_minor);
+ monitor_printf(mon, "debug: %s\n",
+ info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
+ monitor_printf(mon, "key-sharing: %s\n",
+ info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
+ monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
}
+out:
qapi_free_SevInfo(info);
}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 72a6146295..fac2755e68 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -704,25 +704,27 @@ sev_get_info(void)
{
SevInfo *info;
SevCommonState *sev_common = SEV_COMMON(MACHINE(qdev_get_machine())->cgs);
- SevGuestState *sev_guest =
- (SevGuestState *)object_dynamic_cast(OBJECT(sev_common),
- TYPE_SEV_GUEST);
info = g_new0(SevInfo, 1);
info->enabled = sev_enabled();
if (info->enabled) {
- if (sev_guest) {
- info->handle = sev_guest->handle;
- }
info->api_major = sev_common->api_major;
info->api_minor = sev_common->api_minor;
info->build_id = sev_common->build_id;
info->state = sev_common->state;
- /* we only report the lower 32-bits of policy for SNP, ok for now... */
- info->policy =
- (uint32_t)object_property_get_uint(OBJECT(sev_common),
- "policy", NULL);
+
+ if (sev_snp_enabled()) {
+ info->sev_type = SEV_GUEST_TYPE_SEV_SNP;
+ info->u.sev_snp.policy =
+ object_property_get_uint(OBJECT(sev_common), "policy", NULL);
+ } else {
+ info->sev_type = SEV_GUEST_TYPE_SEV;
+ info->u.sev.handle = SEV_GUEST(sev_common)->handle;
+ info->u.sev.policy =
+ (uint32_t)object_property_get_uint(OBJECT(sev_common),
+ "policy", NULL);
+ }
}
return info;
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index e0e1a599be..948d8f1079 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -28,6 +28,9 @@
#define SEV_POLICY_DOMAIN 0x10
#define SEV_POLICY_SEV 0x20
+#define SEV_SNP_POLICY_SMT 0x10000
+#define SEV_SNP_POLICY_DBG 0x80000
+
extern bool sev_es_enabled(void);
extern bool sev_snp_enabled(void);
extern uint64_t sev_get_me_mask(void);
--
2.25.1
Michael Roth <michael.roth@amd.com> writes:
> Most of the current 'query-sev' command is relevant to both legacy
> SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions:
>
> - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and
> the meaning of the bit positions has changed
> - 'handle' is not relevant to SEV-SNP
>
> To address this, this patch adds a new 'sev-type' field that can be
> used as a discriminator to select between SEV and SEV-SNP-specific
> fields/formats without breaking compatibility for existing management
> tools (so long as management tools that add support for launching
> SEV-SNP guest update their handling of query-sev appropriately).
Technically a compatibility break: query-sev can now return an object
that whose member @policy has different meaning, and also lacks @handle.
Matrix:
Old mgmt app New mgmt app
Old QEMU, SEV/SEV-ES good good(1)
New QEMU, SEV/SEV-ES good(2) good
New QEMU, SEV-SNP bad(3) good
Notes:
(1) As long as the management application can cope with absent member
@sev-type.
(2) As long as the management application ignores unknown member
@sev-type.
(3) Management application may choke on missing member @handle, or
worse, misinterpret member @policy. Can only happen when something
other than the management application created the SEV-SNP guest (or the
user somehow made the management application create one even though it
doesn't know how, say with CLI option passthrough, but that's always
fragile, and I wouldn't worry about it here).
I think (1) and (2) are reasonable. (3) is an issue for management
applications that support attaching to existing guests. Thoughts?
>
> The corresponding HMP command has also been fixed up similarly.
>
> Signed-off-by: Michael Roth <michael.roth@amd.com>
> ---
> qapi/misc-target.json | 71 +++++++++++++++++++++++++++++++++---------
> target/i386/monitor.c | 29 +++++++++++++----
> target/i386/sev.c | 22 +++++++------
> target/i386/sev_i386.h | 3 ++
> 4 files changed, 95 insertions(+), 30 deletions(-)
>
> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
> index 3b05ad3dbf..80f994ff9b 100644
> --- a/qapi/misc-target.json
> +++ b/qapi/misc-target.json
> @@ -81,6 +81,49 @@
> 'send-update', 'receive-update' ],
> 'if': 'TARGET_I386' }
>
> +##
> +# @SevGuestType:
> +#
> +# An enumeration indicating the type of SEV guest being run.
> +#
> +# @sev: The guest is a legacy SEV or SEV-ES guest.
> +# @sev-snp: The guest is an SEV-SNP guest.
> +#
> +# Since: 6.2
> +##
> +{ 'enum': 'SevGuestType',
> + 'data': [ 'sev', 'sev-snp' ],
> + 'if': 'TARGET_I386' }
> +
> +##
> +# @SevGuestInfo:
> +#
> +# Information specific to legacy SEV/SEV-ES guests.
> +#
> +# @policy: SEV policy value
> +#
> +# @handle: SEV firmware handle
> +#
> +# Since: 2.12
> +##
> +{ 'struct': 'SevGuestInfo',
> + 'data': { 'policy': 'uint32',
> + 'handle': 'uint32' },
> + 'if': 'TARGET_I386' }
> +
> +##
> +# @SevSnpGuestInfo:
> +#
> +# Information specific to SEV-SNP guests.
> +#
> +# @policy: SEV-SNP policy value
> +#
> +# Since: 6.2
> +##
> +{ 'struct': 'SevSnpGuestInfo',
> + 'data': { 'policy': 'uint64' },
> + 'if': 'TARGET_I386' }
> +
> ##
> # @SevInfo:
> #
> @@ -94,25 +137,25 @@
> #
> # @build-id: SEV FW build id
> #
> -# @policy: SEV policy value
> -#
> # @state: SEV guest state
> #
> -# @handle: SEV firmware handle
> +# @sev-type: Type of SEV guest being run
> #
> # Since: 2.12
> ##
> -{ 'struct': 'SevInfo',
> - 'data': { 'enabled': 'bool',
> - 'api-major': 'uint8',
> - 'api-minor' : 'uint8',
> - 'build-id' : 'uint8',
> - 'policy' : 'uint32',
> - 'state' : 'SevState',
> - 'handle' : 'uint32'
> - },
> - 'if': 'TARGET_I386'
> -}
> +{ 'union': 'SevInfo',
> + 'base': { 'enabled': 'bool',
> + 'api-major': 'uint8',
> + 'api-minor' : 'uint8',
> + 'build-id' : 'uint8',
> + 'state' : 'SevState',
> + 'sev-type' : 'SevGuestType' },
> + 'discriminator': 'sev-type',
> + 'data': {
> + 'sev': 'SevGuestInfo',
> + 'sev-snp': 'SevSnpGuestInfo' },
> + 'if': 'TARGET_I386' }
> +
>
> ##
> # @query-sev:
[...]
On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: > Michael Roth <michael.roth@amd.com> writes: > > > Most of the current 'query-sev' command is relevant to both legacy > > SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: > > > > - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and > > the meaning of the bit positions has changed > > - 'handle' is not relevant to SEV-SNP > > > > To address this, this patch adds a new 'sev-type' field that can be > > used as a discriminator to select between SEV and SEV-SNP-specific > > fields/formats without breaking compatibility for existing management > > tools (so long as management tools that add support for launching > > SEV-SNP guest update their handling of query-sev appropriately). > > Technically a compatibility break: query-sev can now return an object > that whose member @policy has different meaning, and also lacks @handle. > > Matrix: > > Old mgmt app New mgmt app > Old QEMU, SEV/SEV-ES good good(1) > New QEMU, SEV/SEV-ES good(2) good > New QEMU, SEV-SNP bad(3) good > > Notes: > > (1) As long as the management application can cope with absent member > @sev-type. > > (2) As long as the management application ignores unknown member > @sev-type. > > (3) Management application may choke on missing member @handle, or > worse, misinterpret member @policy. Can only happen when something > other than the management application created the SEV-SNP guest (or the > user somehow made the management application create one even though it > doesn't know how, say with CLI option passthrough, but that's always > fragile, and I wouldn't worry about it here). > > I think (1) and (2) are reasonable. (3) is an issue for management > applications that support attaching to existing guests. Thoughts? IIUC you can only reach scenario (3) if you have created a guest using '-object sev-snp-guest', which is a new feature introduced in patch 2. IOW, scenario (3) old mgmt app + new QEMU + sev-snp guest does not exist as a combination. Thus the (bad) field is actually (n/a) So I believe this proposed change is acceptable in all scenarios with existing deployed usage, as well as all newly introduced scenarios. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé <berrange@redhat.com> writes: > On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: >> Michael Roth <michael.roth@amd.com> writes: >> >> > Most of the current 'query-sev' command is relevant to both legacy >> > SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: >> > >> > - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and >> > the meaning of the bit positions has changed >> > - 'handle' is not relevant to SEV-SNP >> > >> > To address this, this patch adds a new 'sev-type' field that can be >> > used as a discriminator to select between SEV and SEV-SNP-specific >> > fields/formats without breaking compatibility for existing management >> > tools (so long as management tools that add support for launching >> > SEV-SNP guest update their handling of query-sev appropriately). >> >> Technically a compatibility break: query-sev can now return an object >> that whose member @policy has different meaning, and also lacks @handle. >> >> Matrix: >> >> Old mgmt app New mgmt app >> Old QEMU, SEV/SEV-ES good good(1) >> New QEMU, SEV/SEV-ES good(2) good >> New QEMU, SEV-SNP bad(3) good >> >> Notes: >> >> (1) As long as the management application can cope with absent member >> @sev-type. >> >> (2) As long as the management application ignores unknown member >> @sev-type. >> >> (3) Management application may choke on missing member @handle, or >> worse, misinterpret member @policy. Can only happen when something >> other than the management application created the SEV-SNP guest (or the >> user somehow made the management application create one even though it >> doesn't know how, say with CLI option passthrough, but that's always >> fragile, and I wouldn't worry about it here). >> >> I think (1) and (2) are reasonable. (3) is an issue for management >> applications that support attaching to existing guests. Thoughts? > > IIUC you can only reach scenario (3) if you have created a guest > using '-object sev-snp-guest', which is a new feature introduced > in patch 2. > > IOW, scenario (3) old mgmt app + new QEMU + sev-snp guest does > not exist as a combination. Thus the (bad) field is actually (n/a) > > So I believe this proposed change is acceptable in all scenarios > with existing deployed usage, as well as all newly introduced > scenarios. Let's work this into the commit message.
* Daniel P. Berrangé (berrange@redhat.com) wrote: > On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: > > Michael Roth <michael.roth@amd.com> writes: > > > > > Most of the current 'query-sev' command is relevant to both legacy > > > SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: > > > > > > - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and > > > the meaning of the bit positions has changed > > > - 'handle' is not relevant to SEV-SNP > > > > > > To address this, this patch adds a new 'sev-type' field that can be > > > used as a discriminator to select between SEV and SEV-SNP-specific > > > fields/formats without breaking compatibility for existing management > > > tools (so long as management tools that add support for launching > > > SEV-SNP guest update their handling of query-sev appropriately). > > > > Technically a compatibility break: query-sev can now return an object > > that whose member @policy has different meaning, and also lacks @handle. > > > > Matrix: > > > > Old mgmt app New mgmt app > > Old QEMU, SEV/SEV-ES good good(1) > > New QEMU, SEV/SEV-ES good(2) good > > New QEMU, SEV-SNP bad(3) good > > > > Notes: > > > > (1) As long as the management application can cope with absent member > > @sev-type. > > > > (2) As long as the management application ignores unknown member > > @sev-type. > > > > (3) Management application may choke on missing member @handle, or > > worse, misinterpret member @policy. Can only happen when something > > other than the management application created the SEV-SNP guest (or the > > user somehow made the management application create one even though it > > doesn't know how, say with CLI option passthrough, but that's always > > fragile, and I wouldn't worry about it here). > > > > I think (1) and (2) are reasonable. (3) is an issue for management > > applications that support attaching to existing guests. Thoughts? > > IIUC you can only reach scenario (3) if you have created a guest > using '-object sev-snp-guest', which is a new feature introduced > in patch 2. > > IOW, scenario (3) old mgmt app + new QEMU + sev-snp guest does > not exist as a combination. Thus the (bad) field is actually (n/a) > > So I believe this proposed change is acceptable in all scenarios > with existing deployed usage, as well as all newly introduced > scenarios. I wonder if it's worth going firther and renaming 'policy' in the SNP world to 'snppolicy' just to reduce the risk of accidentally specifying the wrong one. Dave > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Tue, Sep 07, 2021 at 12:52:54PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrangé (berrange@redhat.com) wrote: > > On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: > > > Michael Roth <michael.roth@amd.com> writes: > > > > > > > Most of the current 'query-sev' command is relevant to both legacy > > > > SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: > > > > > > > > - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and > > > > the meaning of the bit positions has changed > > > > - 'handle' is not relevant to SEV-SNP > > > > > > > > To address this, this patch adds a new 'sev-type' field that can be > > > > used as a discriminator to select between SEV and SEV-SNP-specific > > > > fields/formats without breaking compatibility for existing management > > > > tools (so long as management tools that add support for launching > > > > SEV-SNP guest update their handling of query-sev appropriately). > > > > > > Technically a compatibility break: query-sev can now return an object > > > that whose member @policy has different meaning, and also lacks @handle. > > > > > > Matrix: > > > > > > Old mgmt app New mgmt app > > > Old QEMU, SEV/SEV-ES good good(1) > > > New QEMU, SEV/SEV-ES good(2) good > > > New QEMU, SEV-SNP bad(3) good > > > > > > Notes: > > > > > > (1) As long as the management application can cope with absent member > > > @sev-type. > > > > > > (2) As long as the management application ignores unknown member > > > @sev-type. > > > > > > (3) Management application may choke on missing member @handle, or > > > worse, misinterpret member @policy. Can only happen when something > > > other than the management application created the SEV-SNP guest (or the > > > user somehow made the management application create one even though it > > > doesn't know how, say with CLI option passthrough, but that's always > > > fragile, and I wouldn't worry about it here). > > > > > > I think (1) and (2) are reasonable. (3) is an issue for management > > > applications that support attaching to existing guests. Thoughts? > > > > IIUC you can only reach scenario (3) if you have created a guest > > using '-object sev-snp-guest', which is a new feature introduced > > in patch 2. > > > > IOW, scenario (3) old mgmt app + new QEMU + sev-snp guest does > > not exist as a combination. Thus the (bad) field is actually (n/a) > > > > So I believe this proposed change is acceptable in all scenarios > > with existing deployed usage, as well as all newly introduced > > scenarios. > > I wonder if it's worth going firther and renaming 'policy' in the > SNP world to 'snppolicy' just to reduce the risk of accidentally > specifying the wrong one. Seems reasonable. I'll plan on renaming to 'snp-policy' if there are no objections. > > Dave > > > Regards, > > Daniel > > -- > > |: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fberrange.com%2F&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947391605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D56oHIuVk%2FmAJaKYtpJ3ZEZpKZpDPWZXydV3tpYjcM4%3D&reserved=0 -o- https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.flickr.com%2Fphotos%2Fdberrange&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947401567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A9YA65nj6En3f3E2wm%2BVZE%2F6DpdbDKyHSWN9VXHAk8U%3D&reserved=0 :| > > |: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibvirt.org%2F&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947401567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yf%2FV3f3%2FNxEDwmYESp7D0ZOn74aM6cXskVJrvHLvXRE%3D&reserved=0 -o- https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffstop138.berrange.com%2F&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947401567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pUYNVu6WWgPtwjwrjvz3YCCY7S1Qli%2FfvQKmkaRu3gc%3D&reserved=0 :| > > |: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fentangle-photo.org%2F&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947401567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=opdXI%2BlyzxWhUbNNgka6sMKMiLmMHfk8WuZY6cMy7yE%3D&reserved=0 -o- https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.instagram.com%2Fdberrange&data=04%7C01%7Cmichael.roth%40amd.com%7Cb9a484cd5d4f484b542908d971f61073%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637666123947401567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8cV6tsleO5nDBVKR3WX74a%2BKch5RdRdmPciv%2F6T9nOg%3D&reserved=0 :| > > > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK >
On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: > Michael Roth <michael.roth@amd.com> writes: > > > Most of the current 'query-sev' command is relevant to both legacy > > SEV/SEV-ES guests and SEV-SNP guests, with 2 exceptions: > > > > - 'policy' is a 64-bit field for SEV-SNP, not 32-bit, and > > the meaning of the bit positions has changed > > - 'handle' is not relevant to SEV-SNP > > > > To address this, this patch adds a new 'sev-type' field that can be > > used as a discriminator to select between SEV and SEV-SNP-specific > > fields/formats without breaking compatibility for existing management > > tools (so long as management tools that add support for launching > > SEV-SNP guest update their handling of query-sev appropriately). > > Technically a compatibility break: query-sev can now return an object > that whose member @policy has different meaning, and also lacks @handle. > > Matrix: > > Old mgmt app New mgmt app > Old QEMU, SEV/SEV-ES good good(1) > New QEMU, SEV/SEV-ES good(2) good > New QEMU, SEV-SNP bad(3) good > > Notes: > > (1) As long as the management application can cope with absent member > @sev-type. > > (2) As long as the management application ignores unknown member > @sev-type. > > (3) Management application may choke on missing member @handle, or > worse, misinterpret member @policy. Can only happen when something > other than the management application created the SEV-SNP guest (or the > user somehow made the management application create one even though it > doesn't know how, say with CLI option passthrough, but that's always > fragile, and I wouldn't worry about it here). > > I think (1) and (2) are reasonable. (3) is an issue for management > applications that support attaching to existing guests. Thoughts? Hmm... yah I hadn't considering 'old mgmt' trying to interact with a SNP guest started through some other means. Don't really see an alternative other than introducing a new 'query-sev-snp', but that would still leave 'old mgmt' broken, since it might still call do weird stuff like try to interpret the SNP policy as an SEV/SEV-ES and end up with some very unexpected results. So if I did go this route, I would need to have QMP begin returning an error if query-sev is run against an SNP guest. But currently for non-SEV guests it already does: error_setg(errp, "SEV feature is not available") so 'old mgmt' should be able to handle the error just fine. Would that approach be reasonable?
© 2016 - 2025 Red Hat, Inc.