Re: [PATCH RFC 2/4] target/i386: define CPU models to model x86-64 ABI levels

[Daniel P . Berrangé]

On Tue, Feb 02, 2021 at 12:50:53PM +0000, David Edmondson wrote:
> On Tuesday, 2021-02-02 at 12:32:39 GMT, Daniel P. Berrangé wrote:
> 
> > On Tue, Feb 02, 2021 at 09:46:55AM +0000, David Edmondson wrote:
> >> On Monday, 2021-02-01 at 15:36:04 GMT, Daniel P. Berrangé wrote:
> >> 
> >> > To paraphrase:
> >> >
> >> >   
> >> > https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/
> >> >
> >> > In 2020, AMD, Intel, Red Hat, and SUSE worked together to define
> >> > three microarchitecture levels on top of the historical x86-64
> >> > baseline:
> >> >
> >> >   * x86-64:    original x86_64 baseline instruction set
> >> >   * x86-64-v2: vector instructions up to Streaming SIMD
> >> >                Extensions 4.2 (SSE4.2)  and Supplemental
> >> >         Streaming SIMD Extensions 3 (SSSE3), the
> >> >         POPCNT instruction, and CMPXCHG16B
> >> >   * x86-64-v3: vector instructions up to AVX2, MOVBE,
> >> >                and additional bit-manipulation instructions.
> >> >   * x86-64-v4: vector instructions from some of the
> >> >                AVX-512 variants.
> >> >
> >> > This list of features is defined in the doc at:
> >> >
> >> >   https://gitlab.com/x86-psABIs/x86-64-ABI/
> >> >
> >> > QEMU has historically defaulted to the "qemu64" CPU model on
> >> > x86_64 targets, which is approximately the x86-64 baseline
> >> > ABI, with 'SVM' added.
> >> >
> >> > It is thought it might be desirable if QEMU could provide CPU models
> >> > that closely correspond to the ABI levels, while offering portability
> >> > across the maximum number of physical CPUs.
> >> >
> >> > Historically we've found that defining CPU models with an arbitrary
> >> > combination of CPU features can be problematic, as some guest OS
> >> > will not check all features they use, and instead assume that if
> >> > they see feature "XX", then "YY" will always exist. This is reasonable
> >> > in bare metal, but subject to breakage in virtualization.
> >> >
> >> > Thus in defining the CPI models for the ABI levels, this patch attempted
> >> 
> >> s/CPI/CPU/
> >> 
> >> > to base them off an existing CPU model.
> >> >
> >> > While each x86-64-abiNNN has a designated vendor, they are designed
> >> > to be vendor agnostic models. ie they are capable of running on any
> >> > AMD or Intel physical CPU model that satisfies the ABI level. eg
> >> 
> >> Only AMD or Intel? (You mention the Hugon chips elsewhere.)
> >
> > In theory any x86 CPU that meets the ABI level, regardless of vendor
> > but if any vendor's set of CPUID features diverges too far from other
> > CPUs of similar level we might have problems.
> 
> Understood - so why say "AMD or Intel"?

This text is just giving an example - it doesn't need to be an
exhaustive list of vendors.  Running AMD CPUs models on Intel
host and vica-verca are the two most common scenaroos.

> 
> > For example, I had to specially avoid including "aes" in the
> > x86-64-abi3 because of the Hugon chips lacking it. There might
> > be other cases like this, since I've only compared CPUID sets
> > for named CPUs that QEMU includes.
> >
> >> > None of the CPU models declare any VMX/SVM features. This would
> >> > make them unable to support nested virtualization with live
> >> > migration.
> >> 
> >> How about "Unable to support hardware accelerated nested
> >> virtualization." ?
> >> 
> >> Is live migration relevant?
> >
> > Choice of CPU models is a critical decision in your future ability
> > to live migrate, so I wanted to call that out specifically.
> 
> But the restriction, I believe, is not that you won't be able to live
> migrate with nested VMs, it's that you don't get support for nested VMs
> (well, hardware accelerated - you could still run a fully emulated
> nested VM). Live migration with nested VMs is irrelevant if I don't
> *get* nested VMs.

What I mean is that if you use  "-cpu x86-64-abi2,+vmx" and KVM will
enable nested virt, but I believe live migration will fail because
we've not declared any VMX capabilities in the CPU model. I'll have
to defer to Paolo on the actual failure scenario details.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|