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.
