Re: [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Jan 30, 2018 at 03:46:45PM -0600, Brijesh Singh wrote:
> 
> 
> On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote:
> > * Brijesh Singh (brijesh.singh@amd.com) wrote:
> >> AMD EPYC processors support memory encryption feature. The feature
> >> is reported through CPUID 8000_001F[EAX].
> >>
> >> Fn8000_001F [EAX]:
> >>  Bit 0   Secure Memory Encryption (SME) supported
> >>  Bit 1   Secure Encrypted Virtualization (SEV) supported
> >>  Bit 2   Page flush MSR supported
> >>  Bit 3   Ecrypted State (SEV-ES) support
> >>
> >> when memory encryption feature is reported, CPUID 8000_001F[EBX] should
> >> provide additional information regarding the feature (such as which page
> >> table bit is used to mark pages as encrypted etc). The information in EBX
> >> and ECX may vary from one family to another hence we use the host cpuid
> >> to populate the EBX information.
> > That's going to make it interesting for migration.  If the guest needs
> > to know that C-bit position then you presumably can't migrate between
> > those two host types, but we wouldn't have anything that currently
> > stops us.
> > We already have similar problems with variations in physical address
> > size but normally get away with that, especially on smaller VMs.
> 
> Dave,
> 
> While building the page tables guest need to know the C-bit position.
> The C-bit position in the guest is same as C-bit position on the host.
> For migration case, we should be able to migrate SEV guest on same host
> type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should
> be okay migrating the SEV guests among those host types).  Since C-bit
> position is not fixed hence migrating to different host family will be
> an issue.

Thanks for the explanation.  If this affects ability to migrate,
you need to either:
a) not report the "sev" property on
   query-cpu-model-expansion type=static output (because the
   feature is not migration-safe); or
b) make the C-bit position configurable, and let management
   explicitly specify it.  In this case, you need to validate the
   configured C-bit position and prevent the VM from running if
   it doesn't match the host.  This is more work, but would make
   the feature migration-safe and more useful for management
   software.

Option (b) is preferred because it lets management software
ensure the VM is migratable to a host before starting migration.

There was a very recent discussion about migration-safe features
and the problems with relaying host CPUID data directly to the
guest.  Look for the "i386: Add Intel Processor Trace feature
support" threads in qemu-devel for more info.

I'm looking for a way to document these rules concisely so people
touching the CPUID code are aware of the available options.

-- 
Eduardo