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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
