[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 2/4] target/i386: define CPU models to model x86-64 ABI l
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH RFC 2/4] target/i386: define CPU models to model x86-64 ABI levels |
Date: |
Tue, 2 Feb 2021 12:54:43 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
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 :|
- Re: [PATCH RFC 1/4] docs: add a table showing x86-64 ABI compatibility levels, (continued)
[PATCH RFC 2/4] target/i386: define CPU models to model x86-64 ABI levels, Daniel P . Berrangé, 2021/02/01
[PATCH RFC 3/4] NOT FOR MERGE target/i386: use x86-64-abi1 CPU model as default on x86_64, Daniel P . Berrangé, 2021/02/01
[PATCH RFC 4/4] NOT FOR MERGE: script for CPU model stuff related to x86-64 ABI levels, Daniel P . Berrangé, 2021/02/01