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

On 01/31/2018 07:41 AM, Eduardo Habkost wrote:

On Tue, Jan 30, 2018 at 03:46:45PM -0600, Brijesh Singh wrote:

quoted

On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote:

quoted

* Brijesh Singh (brijesh.singh@amd.com) wrote:

quoted

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.

I also prefer Option (b). In next series, I will extend the sev-guest 
object to add a new property (cbitpos). Management software stack can 
use this property to pass the c-bit position and we validate it. Thanks 
for the feedback.

-Brijesh