Re: [Qemu-devel] [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support

From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Brijesh Singh <brijesh.ksingh@gmail.com>
Cc: Borislav Petkov <bp@suse.de>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@xilinx.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Alistair Francis <alistair.francis@xilinx.com>,
	Bruce
Subject: Re: [Qemu-devel] [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support
Date: Tue, 13 Feb 2018 15:45:08 +0000	[thread overview]
Message-ID: <20180213154508.GK2378@work-vm> (raw)
In-Reply-To: <CA+HCGMYvh081neh=aF45qG0WF2vpJwkZ4unnLPLwhEkDNPWZsQ@mail.gmail.com>

* Brijesh Singh (brijesh.ksingh@gmail.com) wrote:
> On Mon, Feb 12, 2018 at 3:19 PM, Borislav Petkov <bp@suse.de> wrote:
> 
> > On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote:
> > > In current implementation, when -cpu ...,+sev is passed without
> > > appropriate SEV configuration then we populate the Fn8000_001F CPUID but
> > > VMCB will not have SEV bit set hence a guest will be launched as
> > > non-SEV.
> >
> > I think we should fail the guest init if sev is not really supported by
> > the host. Otherwise people might get mislead.
> >
> >
> 
> Sure I will do that. We can simplify this patch if we don't fill the CPUID
> for non SEV guest. I am thinking of doing something like this:
> 
> "If SEV configration is provided in QEMU command line then
> automatically increase xlevel to 0x8000_001F and populate the EAX and EBX
> registers"
> 
> 
> 
> > > > Changing existing CPU models is possible only on very specific
> > > > circumstances (where VMs that are currently runnable would always
> > > > stay runnable), and would require compat_props entries to keep
> > > > compatibility on existing machine-types.
> > >
> > > Ah I didn't consider that case. What is recommendation, should we create
> > > a new CPU Model (EPYC-SEV) ?
> >
> > Can we please stop creating a new CPU model with every new CPUID feature
> > support added? This is just ridiculous.
> >
> > If this is about live migration, then by all means, fail the migration
> > if the feature bits are not compatible. But replicating CPU models and
> > then adding one new differing feature doesn't make any sense.
> >
> >
> Yes, I think we should be able to avoid creating new CPU model to handle
> this case.
> I am leaning towards dropping this patch and implement logic to populate the
> CPUID 0x8000_001F only when SEV is enabled. This should not require any
> changes
> in existing CPU model feature flag and live migration of existing guest
> should work fine.

Take care that a non-SEV guest works migrating from a SEV-enabled host
back to a non-SEV-enabled host.  Similarly a guest that understands SEV
but you aren't going to enable it for this VM.

Dave

> 
> 
> > --
> > Regards/Gruss,
> >     Boris.
> >
> > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
> > 21284 (AG Nürnberg)
> > --
> >
> >
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK