Daniel P. Berrangé <berra...@redhat.com> writes: > On Wed, Sep 01, 2021 at 04:14:10PM +0200, Markus Armbruster wrote: >> Michael Roth <michael.r...@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.
