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

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.

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