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