All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: libvir-list@redhat.com, "Igor Mammedov" <imammedo@redhat.com>,
	qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Date: Fri, 11 Nov 2016 15:29:21 +0100	[thread overview]
Message-ID: <87inruum2m.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20161111121744.GA5348@orkuz.home> (Jiri Denemark's message of "Fri, 11 Nov 2016 13:17:44 +0100")

Jiri Denemark <jdenemar@redhat.com> writes:

> On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>> > libvirt wants to know if the QEMU binary supports a given -cpu
>> > option (normally CPU features that can be enabled/disabled using
>> > "+foo"/"-foo").
>> 
>> The obvious way to check whether a specific CPU supports it is to
>> introspect that CPU.
>> 
>> The obvious way to check whether all CPUs of interest support it
>> (assuming that is a productive question) is to introspect all CPUs of
>> interest.  Works regardless of whether the option is inherited, which is
>> really an implementation detail.
>
> As Eduardo said, libvirt wants to know whether it can use a given CPU
> feature with current QEMU binary. In -cpu help, we can see a list of
> models and features QEMU understands, but we need to get similar info
> via QMP. CPU models are easy, but how do we get the list of CPU
> features? If introspection is the way to get it, I'm fine with that,
> just beware that we don't actually know the name of the CPU object
> (Westmere-x86_64-cpu), we only know the name of the CPU model
> (Westmere).

Actually, you do:

    { "execute": "qom-list-types", "arguments": { "implements": "cpu" } }
    {"return": [{"name": "Westmere-x86_64-cpu"}, ...]}

>             So if the object name is needed, we need to query the
> mapping from CPU model names to CPU object names.

Hmm.  The problem is that some interfaces such as -cpu require a "CPU
model name", but introspection gives you the QOM type name.  The mapping
from "model name" to type name even depends on the target: it's CPUClass
method class_by_name().

Can't say I like that, but we got to play the hand we were dealt, and
that means we need to provide a way to introspect the mapping between
CPU model name and QOM type name.  Eduardo's plan to add the QOM type
name to query-cpu-definitions makes more sense to me now.

  parent reply	other threads:[~2016-11-11 14:29 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-29  1:47 [Qemu-devel] [PATCH v4 0/8] qdev class properties + abstract class support on device-list-properties Eduardo Habkost
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 1/8] tests: check-qom-proplist: Remove duplicate "bv" property Eduardo Habkost
2016-11-04 11:22   ` Markus Armbruster
2016-11-04 15:10     ` Markus Armbruster
2016-11-04 15:56   ` Andreas Färber
2016-11-04 16:07     ` Eduardo Habkost
2016-11-04 16:11       ` Andreas Färber
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 2/8] tests: check-qom-proplist: Use &error_abort to catch errors Eduardo Habkost
2016-10-31 10:14   ` Igor Mammedov
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 3/8] qdev: device_class_set_props() function Eduardo Habkost
2016-11-01 15:02   ` Igor Mammedov
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 4/8] qdev: Extract property-default code to qdev_property_set_to_default() Eduardo Habkost
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 5/8] qdev: Register static properties as class properties Eduardo Habkost
2016-10-31 12:06   ` Igor Mammedov
2016-11-04 15:22   ` Markus Armbruster
2016-11-04 16:00     ` Eduardo Habkost
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 6/8] qom: object_class_property_iter_init() function Eduardo Habkost
2016-10-31 13:45   ` Igor Mammedov
2016-11-04 15:31   ` Markus Armbruster
2016-10-29  1:48 ` [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties Eduardo Habkost
2016-10-31 14:07   ` Igor Mammedov
2016-10-31 14:36     ` Eduardo Habkost
2016-11-04 15:45       ` Markus Armbruster
2016-11-04 16:04         ` Eduardo Habkost
2016-11-07  8:09           ` Markus Armbruster
2016-11-07 12:38             ` Eduardo Habkost
2016-11-07 14:40               ` Markus Armbruster
2016-11-07 17:11                 ` Eduardo Habkost
2016-11-08  7:29                   ` Markus Armbruster
2016-11-11 12:17                     ` Jiri Denemark
2016-11-11 12:34                       ` Eduardo Habkost
2016-11-11 14:29                       ` Markus Armbruster [this message]
2016-11-07 12:45   ` Halil Pasic
2016-11-07 13:05     ` Eduardo Habkost
2016-11-07 14:48       ` Halil Pasic
2016-11-07 15:01         ` Daniel P. Berrange
2016-11-07 15:51           ` Markus Armbruster
2016-11-07 17:27             ` Eduardo Habkost
2016-11-07 17:41               ` Daniel P. Berrange
2016-11-07 18:03                 ` Eduardo Habkost
2016-11-07 18:08                   ` Daniel P. Berrange
2016-11-07 18:28                     ` Eduardo Habkost
2016-11-08  7:37                       ` Markus Armbruster
2016-11-08 10:09                         ` Daniel P. Berrange
2016-11-08 14:35                           ` Markus Armbruster
2016-11-08 16:16                             ` Eduardo Habkost
2016-11-08 10:11                         ` Halil Pasic
2016-10-29  1:48 ` [Qemu-arm] [PATCH v4 8/8] qdev: Warning about using qdev_property_add_static() in new code Eduardo Habkost
2016-10-29  1:48   ` [Qemu-devel] " Eduardo Habkost
2016-10-31 14:05   ` [Qemu-arm] " Igor Mammedov
2016-10-31 14:05     ` [Qemu-devel] " Igor Mammedov
2016-11-04 15:52 ` [Qemu-devel] [PATCH v4 0/8] qdev class properties + abstract class support on device-list-properties Markus Armbruster

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=87inruum2m.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@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.