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 (address@hidden) 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.