All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, libvir-list@redhat.com,
	Jiri Denemark <jdenemar@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model
Date: Tue, 6 Dec 2016 10:32:48 +0100	[thread overview]
Message-ID: <862e80d2-d0f9-668f-d6ed-b25712a220c1@redhat.com> (raw)
In-Reply-To: <20161205235745.GJ13060@thinpad.lan.raisama.net>

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

  reply	other threads:[~2016-12-06  9:32 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02 21:17 [Qemu-devel] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 01/17] qmp: Report QOM type name on query-cpu-definitions Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 02/17] qemu.py: Make logging optional Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 03/17] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 04/17] qtest.py: make logging optional Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 05/17] qtest.py: Make 'binary' parameter optional Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 06/17] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 07/17] target-i386: Reorganize and document CPUID initialization steps Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 08/17] target-i386: Support "-cpu host" on TCG too Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 09/17] target-i386: Move "host" properties to base class Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 10/17] target-i386: Allow short strings to be used as vendor ID Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 11/17] target-i386: Remove AMD feature flag aliases from Opteron models Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 12/17] target-i386: Return migration-safe field on query-cpu-definitions Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 13/17] cpu: Support comma escaping when parsing -cpu Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 14/17] qapi: add static/migration-safe info to query-cpu-model-expansion Eduardo Habkost
2016-12-13  9:47   ` Markus Armbruster
2016-12-13 12:46     ` Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model Eduardo Habkost
2016-12-05 18:18   ` David Hildenbrand
2016-12-05 23:57     ` Eduardo Habkost
2016-12-06  9:32       ` David Hildenbrand [this message]
2016-12-06 12:43         ` Eduardo Habkost
2016-12-16 16:02       ` Jiri Denemark
2016-12-20 16:49         ` David Hildenbrand
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 16/17] tests: query-cpu-model-test.py test code Eduardo Habkost
2016-12-02 21:18 ` [Qemu-devel] [PATCH for-2.9 17/17] target-i386: Implement query-cpu-model-expansion QMP command Eduardo Habkost
2016-12-13 10:16   ` Markus Armbruster
2016-12-13 12:55     ` Eduardo Habkost
2016-12-13 19:20       ` Markus Armbruster
2016-12-13 21:11         ` Eduardo Habkost
2016-12-05  9:09 ` [Qemu-devel] [libvirt] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion no-reply
2016-12-05 15:15 ` [Qemu-devel] " David Hildenbrand
2016-12-05 17:11   ` Eduardo Habkost
2016-12-05 18:13     ` David Hildenbrand
2016-12-05 23:45       ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=862e80d2-d0f9-668f-d6ed-b25712a220c1@redhat.com \
    --to=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.