Re: [Qemu-devel] [PATCH] Introduce query-cpu-max QMP command and cpu_max HMP counterpart

["Andreas Färber" <afaerber@suse.de>]

Am 19.03.2013 13:28, schrieb Markus Armbruster:
> Please cc: Luiz and me on QMP work in the future.
> 
> Michal Novotny <minovotn@redhat.com> writes:
> 
>> This is the patch to introduce the query-cpu-max QMP command to get
>> the maximum number of CPUs supported by the currently running emulator
>> instance. This may differ machine from machine as defined by -machine
>> settings and max_cpus member of QEMUMachine structure.
> 
> Humor me: don't start commit message bodies with "This patch" or
> variations thereof, and don't repeat the subject.  Suggest:
> 
> QMP command query-cpu-max returns the maximum number of CPUs supported
> by the currently running emulator instance, as defined in its
> QEMUMachine struct.
> 
>> It's been tested both using QMP/qmp utility and telnet session on
>> the QEMU session.
> 
> What's a QMP/qmp utility?

Our ./QMP/qmp script, I guess.

>  Let's drop this sentence.  In the future,
> feel free to put testing info below the "---" line.
> 
>> The HMP counterpart called cpu_max has been introduced by this patch
>> too.
> 
> Grammar nit: s/has been/is/.  Even better, avoid passive voice.
> 
> Hmm, I just rewrote most of your commit message, so why not rewrite all
> of it:
> 
>     New QMP command query-cpu-max and HMP command cpu_max
> 
>     These commands return the maximum number of CPUs supported by the
>     currently running emulator instance, as defined in its QEMUMachine
>     struct.
> 
> Perhaps Luiz can fix up the commit message commit, if you don't mind.
> 
> Patch looks good.
> 
> Should query commands for machine properties multiply, we should
> consider creating a single command returning all of them.  I'm not
> asking you to do that now.
> 
> Reviewed-by: Markus Armbruster <armbru@redhat.com>

>From my CPU perspective I am wondering if this info has future as-is?
IIUC this QEMUMachine value differs from the value exposed to
SeaBIOS/KVM already since recently, as it ignores CPU topology.

I'm guessing the libvirt use case is just to detect users specifying too
many -cpu options, so I won't veto this, but want to caution that we may
need to change this as we proceed with CPU remodelling.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg