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

[David Edmondson]

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"?

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

dme.
-- 
I don't care 'bout your other girls, just be good to me.