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

["Dr. David Alan Gilbert" <dgilbert@redhat.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