[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base"
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model |
Date: |
Tue, 6 Dec 2016 10:43:36 -0200 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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
- [Qemu-devel] [PATCH for-2.9 08/17] target-i386: Support "-cpu host" on TCG too, (continued)
- [Qemu-devel] [PATCH for-2.9 08/17] target-i386: Support "-cpu host" on TCG too, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 09/17] target-i386: Move "host" properties to base class, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 10/17] target-i386: Allow short strings to be used as vendor ID, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 12/17] target-i386: Return migration-safe field on query-cpu-definitions, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 13/17] cpu: Support comma escaping when parsing -cpu, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 11/17] target-i386: Remove AMD feature flag aliases from Opteron models, Eduardo Habkost, 2016/12/02
- [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model, Eduardo Habkost, 2016/12/02
[Qemu-devel] [PATCH for-2.9 14/17] qapi: add static/migration-safe info to query-cpu-model-expansion, Eduardo Habkost, 2016/12/02
[Qemu-devel] [PATCH for-2.9 17/17] target-i386: Implement query-cpu-model-expansion QMP command, Eduardo Habkost, 2016/12/02