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