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@xxxxxxx) 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
