Re: [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model

[Eduardo Habkost]

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