On Mon, Feb 12, 2018 at 3:19 PM, Borislav Petkov <b...@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.



> --
> Regards/Gruss,
>     Boris.
>
> SUSE Linux GmbH, GF: Felix Imend├Ârffer, Jane Smithard, Graham Norton, HRB
> 21284 (AG N├╝rnberg)
> --
>
>

Reply via email to