On Tue, Dec 06, 2016 at 10:32:48AM +0100, David Hildenbrand wrote:
[...]
>
> I would like to hear from libvirt developers what they think. I
> still don't know what they plan to use the type=static expansion
> results for.
>
> >
> > How long is the static expansion on a recent intel CPU?
>
> CPU model "Broadwell" returns 165 entries on return.model.props:
>
> (QEMU) query-cpu-model-expansion type=static
model={"name":"Broadwell"}
> {"return": {"migration-safe": true, "model":
{"name": "base", "props": {"pfthreshold": false,
"pku": false, "rtm": true, "tsc-deadline": true,
"xstore-en": false, "tsc-scale": false, "abm": true,
"ia64": false, "kvm-mmu": false, "xsaveopt": true,
"tce": false, "smep": true, "fpu": true, "xcrypt":
false, "clflush": true, "flushbyasid": false,
"kvm-steal-time": false, "lm": true, "tsc": true,
"adx": true, "fxsr": true, "tm": false, "xgetbv1":
false, "xstore": false, "vme": false, "vendor":
"GenuineIntel", "arat": true, "de": true, "aes":
true, "pse": true, "ds-cpl": false, "tbm": false,
"sse": true, "phe-en": false, "f16c": true, "ds":
false, "mpx": false, "tsc-adjust": false, "avx512f": false,
"avx2": true, "pbe": false, "cx16": true,
"avx512pf": false, "movbe": true, "perfctr-nb": false,
"ospke": false, "avx512ifma": false, "stepping": 2,
"sep": true, "sse4a": false, "avx512dq": false,
"avx512-4vnniw": false, "xsave": true, "pmm": false,
"hle": true, "est": false, "xop": false, "smx":
false, "monitor": false, "avx512er": false, "apic": true,
"sse4.1": true, "sse4.2": true, "pause-filter": false,
"lahf-lm": true, "kvm-nopiodelay": false, "acpi": false,
"mmx": true, "osxsave": false, "pcommit": false,
"mtrr": true, "clwb": false, "dca": false, "pdcm":
false, "xcrypt-en": false, "3dnow": false, "invtsc": false,
"tm2": false, "hypervisor": true, "kvmclock-stable-bit":
false, "fxsr-opt": false, "pcid": true, "lbrv": false,
"avx512-4fmaps": false, "svm-lock": false, "popcnt": true,
"nrip-save": false, "avx512vl": false, "x2apic": true,
"kvmclock": false, "smap": true, "family": 6,
"min-level": 13, "dtes64": false, "ace2": false,
"fma4": false, "xtpr": false, "avx512bw": false,
"nx": true, "lwp": false, "msr": true, "ace2-en":
false, "decodeassists": false, "perfctr-core": false, "pge":
true, "pn": false, "fma": true, "nodeid-msr": false,
"cx8": true, "mce": true, "avx512cd": false,
"cr8legacy": false, "mca": true, "pni": true,
"rdseed": true, "osvw": false, "fsgsbase": true,
"model-id": "Intel Core Processor (Broadwell)",
"cmp-legacy": false, "kvm-pv-unhalt": false, "rdtscp": true,
"mmxext": false, "cid": false, "vmx": false,
"ssse3": true, "extapic": false, "pse36": true,
"min-xlevel": 2147483656, "ibs": false, "avx": true,
"syscall": true, "umip": false, "invpcid": true,
"bmi1": true, "bmi2": true, "vmcb-clean": false,
"erms": true, "cmov": true, "misalignsse": false,
"clflushopt": false, "pat": true, "3dnowprefetch": true,
"rdpid": false, "pae": true, "wdt": false,
"skinit": false, "pmm-en": false, "phe": false,
"3dnowext": false, "lmce": false, "ht": false,
"pdpe1gb": false, "kvm-pv-eoi": false, "npt": false,
"xsavec": false, "pclmulqdq": true, "svm": false,
"sse2": true, "ss": false, "topoext": false,
"rdrand": true, "avx512vbmi": false, "kvm-asyncpf": false,
"xsaves": false, "model": 61}}, "static": true}}
>
>
Wow, yes that was the reason for me to introduce abstractions on s390x. But
here the plan was to use the epansion directly when indication the
"host" model to the user. Having something like "Broadwell-base"+/-
a
handful of features is just easier to handle than "base" with 165 feature
flags. But as we don't know what libvirt plans are (they could use that
interface on x86 to do feature detection only and convert to models
themselves), I also have no idea what would be best in the context of x86
cpu models.
In the case of x86, libvirt already has their own database of
"static" CPU models in /usr/share/libvirt/cpu_map.xml. Maybe
providing our own set of static CPU models would be helpful if
they want to get rid of their database. But I'm not sure if:
1) they want to do that in the near future; 2) how easily they
could keep compatibility with their existing model names while
doing that.
--
Eduardo