| Message ID | 1480713496-11213-16-git-send-email-ehabkost@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: > The query-cpu-model-expand QMP command needs at least one static > model, to allow the "static" expansion mode to be implemented. > Instead of defining static versions of every CPU model, define a > "base" CPU model that has absolutely no feature flag enabled. > Introducing separate ones makes feature lists presented to the user much shorter (and therefore easier to maintain). But I don't know how libvirt wants to deal with models on x86 in the future. How long is the static expansion on a recent intel CPU?
On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: > Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: > > The query-cpu-model-expand QMP command needs at least one static > > model, to allow the "static" expansion mode to be implemented. > > Instead of defining static versions of every CPU model, define a > > "base" CPU model that has absolutely no feature flag enabled. > > > > Introducing separate ones makes feature lists presented to the user much > shorter (and therefore easier to maintain). But I don't know how libvirt > wants to deal with models on x86 in the future. I understand that having a larger set of static models would make expansions shorter. But I worry that by defining a complete set of static models on x86 would require extra maintenance work on the QEMU side with no visible benefit for libvirt. 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}}
Am 06.12.2016 um 00:57 schrieb Eduardo Habkost: > On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: >> Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: >>> The query-cpu-model-expand QMP command needs at least one static >>> model, to allow the "static" expansion mode to be implemented. >>> Instead of defining static versions of every CPU model, define a >>> "base" CPU model that has absolutely no feature flag enabled. >>> >> >> Introducing separate ones makes feature lists presented to the user much >> shorter (and therefore easier to maintain). But I don't know how libvirt >> wants to deal with models on x86 in the future. > > I understand that having a larger set of static models would make > expansions shorter. But I worry that by defining a complete set > of static models on x86 would require extra maintenance work on > the QEMU side with no visible benefit for libvirt. As static models will never change (theory) the maintenance work should be pretty much down to zero. But the initial implementation and comming up with the models requires work (my experience ;) ). I am not against the "base" model (actually it is really pretty nice to have). Using only that somehow smells like the "user" cpu model discussion. Which might be ok for x86. > > 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. -- David
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.
On Mon, Dec 05, 2016 at 21:57:45 -0200, Eduardo Habkost wrote: > On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: > > Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: > > > The query-cpu-model-expand QMP command needs at least one static > > > model, to allow the "static" expansion mode to be implemented. > > > Instead of defining static versions of every CPU model, define a > > > "base" CPU model that has absolutely no feature flag enabled. > > > > > > > Introducing separate ones makes feature lists presented to the user much > > shorter (and therefore easier to maintain). But I don't know how libvirt > > wants to deal with models on x86 in the future. > > I understand that having a larger set of static models would make > expansions shorter. But I worry that by defining a complete set > of static models on x86 would require extra maintenance work on > the QEMU side with no visible benefit for libvirt. > > 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. Currently we are mostly interested in the expansion of the "host" CPU model. We're fine with the expansion based on the "basic" static model with no features. Returning some real model instead of "basic" would be OK as long as it would be one of the existing CPU models. Adding special static models, such as Broadwell-base would actually be a complication since we would need to provide some translation to the existing models for backward compatibility. I'd appreciate if we could avoid doing this. Jirka
Am 16.12.2016 um 17:02 schrieb Jiri Denemark: > On Mon, Dec 05, 2016 at 21:57:45 -0200, Eduardo Habkost wrote: >> On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: >>> Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: >>>> The query-cpu-model-expand QMP command needs at least one static >>>> model, to allow the "static" expansion mode to be implemented. >>>> Instead of defining static versions of every CPU model, define a >>>> "base" CPU model that has absolutely no feature flag enabled. >>>> >>> >>> Introducing separate ones makes feature lists presented to the user much >>> shorter (and therefore easier to maintain). But I don't know how libvirt >>> wants to deal with models on x86 in the future. >> >> I understand that having a larger set of static models would make >> expansions shorter. But I worry that by defining a complete set >> of static models on x86 would require extra maintenance work on >> the QEMU side with no visible benefit for libvirt. >> >> 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. > > Currently we are mostly interested in the expansion of the "host" CPU > model. We're fine with the expansion based on the "basic" static model > with no features. Returning some real model instead of "basic" would be > OK as long as it would be one of the existing CPU models. Adding special > static models, such as Broadwell-base would actually be a complication I agree, mixing names would be confusing. So if we would want to introduce static CPU models for x86 in QEMU, they would have to be named exactly like the libvirt models and contain the exact same feature set. > since we would need to provide some translation to the existing models > for backward compatibility. I'd appreciate if we could avoid doing this. Right and translation would only confuse people, especially if the CPU models in libvirt and QEMU behave differently. > > Jirka >
diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h index 7561891..279f327 100644 --- a/target-i386/cpu-qom.h +++ b/target-i386/cpu-qom.h @@ -49,6 +49,7 @@ typedef struct X86CPUDefinition X86CPUDefinition; * @cpu_def: CPU model definition * @ordering: Ordering on the "-cpu help" CPU model list. * @migration_safe: See CpuDefinitionInfo::migration_safe + * @static_model: See CpuDefinitionInfo::static * @parent_realize: The parent class' realize handler. * @parent_reset: The parent class' reset handler. * @@ -64,6 +65,7 @@ typedef struct X86CPUClass { int ordering; bool migration_safe; + bool static_model; /* Optional description of CPU model. * If unavailable, cpu_def->model_id is used */ diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 3539419..bf4ac09 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2200,6 +2200,7 @@ static void x86_cpu_definition_entry(gpointer data, gpointer user_data) info->q_typename = g_strdup(object_class_get_name(oc)); info->migration_safe = cc->migration_safe; info->has_migration_safe = true; + info->q_static = cc->static_model; entry = g_malloc0(sizeof(*entry)); entry->value = info; @@ -3592,7 +3593,9 @@ static void x86_cpu_initfn(Object *obj) object_property_add_alias(obj, "sse4_1", obj, "sse4.1", &error_abort); object_property_add_alias(obj, "sse4_2", obj, "sse4.2", &error_abort); - x86_cpu_load_def(cpu, xcc->cpu_def, &error_abort); + if (xcc->cpu_def) { + x86_cpu_load_def(cpu, xcc->cpu_def, &error_abort); + } } static int64_t x86_cpu_get_arch_id(CPUState *cs) @@ -3747,6 +3750,24 @@ static const TypeInfo x86_cpu_type_info = { .class_init = x86_cpu_common_class_init, }; + +/* "base" CPU model, used by query-cpu-model-expansion */ +static void x86_cpu_base_class_init(ObjectClass *oc, void *data) +{ + X86CPUClass *xcc = X86_CPU_CLASS(oc); + + xcc->static_model = true; + xcc->migration_safe = true; + xcc->model_description = "base CPU model type with no feature enabled"; + xcc->ordering = 8; +} + +static const TypeInfo x86_base_cpu_type_info = { + .name = X86_CPU_TYPE_NAME("base"), + .parent = TYPE_X86_CPU, + .class_init = x86_cpu_base_class_init, +}; + static void x86_cpu_register_types(void) { int i; @@ -3755,6 +3776,7 @@ static void x86_cpu_register_types(void) for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) { x86_register_cpudef_type(&builtin_x86_defs[i]); } + type_register_static(&x86_base_cpu_type_info); #ifdef CONFIG_KVM type_register_static(&host_x86_cpu_type_info); #endif
The query-cpu-model-expand QMP command needs at least one static model, to allow the "static" expansion mode to be implemented. Instead of defining static versions of every CPU model, define a "base" CPU model that has absolutely no feature flag enabled. Despite having no CPUID data set at all, "-cpu base" is even a functional CPU: * It can boot a Slackware Linux 1.01 image with a Linux 0.99.12 kernel[1]. * It is even possible to boot[2] a modern Fedora x86_64 guest by manually enabling the following CPU features: -cpu base,+lm,+msr,+pae,+fpu,+cx8,+cmov,+sse,+sse2,+fxsr [1] http://www.qemu-advent-calendar.org/2014/#day-1 [2] This is what can be seen in the guest: [root@localhost ~]# cat /proc/cpuinfo processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : 00/00 stepping : 0 physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu msr pae cx8 cmov fxsr sse sse2 lm nopl bugs : bogomips : 5832.70 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [root@localhost ~]# x86info -v -a x86info v1.30. Dave Jones 2001-2011 Feedback to <davej@redhat.com>. No TSC, MHz calculation cannot be performed. Unknown vendor (0) MP Table: Family: 0 Model: 0 Stepping: 0 CPU Model (x86info's best guess): eax in: 0x00000000, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000001, eax = 00000000 ebx = 00000800 ecx = 00000000 edx = 07008161 eax in: 0x80000000, eax = 80000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 20000000 Feature flags: fpu Onboard FPU msr Model-Specific Registers pae Physical Address Extensions cx8 CMPXCHG8 instruction cmov CMOV instruction fxsr FXSAVE and FXRSTOR instructions sse SSE support sse2 SSE2 support Long NOPs supported: yes Address sizes : 0 bits physical, 0 bits virtual 0MHz processor (estimate). running at an estimated 0MHz [root@localhost ~]# Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- target-i386/cpu-qom.h | 2 ++ target-i386/cpu.c | 24 +++++++++++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-)