linux-kernel - Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150331131623.GG7031@thinpad.lan.raisama.net>
Date:	Tue, 31 Mar 2015 10:16:23 -0300
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	Eric Blake <eblake@...hat.com>
Cc:	Michael Mueller <mimu@...ux.vnet.ibm.com>,
	linux-s390@...r.kernel.org, kvm@...r.kernel.org,
	Gleb Natapov <gleb@...nel.org>, linux-kernel@...r.kernel.org,
	Alexander Graf <agraf@...e.de>, qemu-devel@...gnu.org,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Daniel Hansel <daniel.hansel@...ux.vnet.ibm.com>,
	"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Andreas Faerber <afaerber@...e.de>,
	Richard Henderson <rth@...ddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command
 query-cpu-model

On Mon, Mar 30, 2015 at 02:20:43PM -0600, Eric Blake wrote:
> On 03/30/2015 02:17 PM, Eduardo Habkost wrote:
> > On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> >> This patch implements a new QMP request named 'query-cpu-model'.
> >> It returns the cpu model of cpu 0 and its backing accelerator.
> >>
> >> request:
> >>   {"execute" : "query-cpu-model" }
> >>
> >> answer:
> >>   {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> > 
> > If you are returning information about an existing CPU, why not just
> > extend the output of "query-cpus"?
> > 
> > (Existing qmp_query_cpus() calls cpu_synchronize_state(), which may be
> > undesired. But in this case we could add an optional parameter to
> > disable the return of data that requires stopping the VCPU).
> 
> And how would libvirt learn about the existence of that optional
> parameter?  Without introspection, a new command is easier to query than
> learning about whether an optional parameter exists (then again, we're
> hoping to get introspection into 2.4, so it may be a moot question).

Even if we don't get introspection, a query-cpus-v2 command (with the
extra parameter) could be extended in the future to return additional
information about CPUs, instead of being specific for CPU model
information.

We also have the option of simply providing predictable QOM paths for
CPU objects, then clients could use qom-get to get what they need
through QOM properties. There was a discussion about it some time ago,
but I don't remember the conclusion.

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/