From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Re: [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support Date: Wed, 31 Jan 2018 11:41:02 -0200 Message-ID: <20180131134102.GI26425@localhost.localdomain> References: <20180129174132.108925-1-brijesh.singh@amd.com> <20180129174132.108925-6-brijesh.singh@amd.com> <20180130174957.GD2536@work-vm> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, kvm@vger.kernel.org, Paolo Bonzini , Tom Lendacky , Peter Maydell , Richard Henderson , "Edgar E. Iglesias" , Stefan Hajnoczi , Eric Blake , "Michael S. Tsirkin" , "Daniel P . Berrange" , Richard Henderson To: Brijesh Singh Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47062 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752680AbeAaNlN (ORCPT ); Wed, 31 Jan 2018 08:41:13 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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