From: Peter Krempa <pkrempa@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Michal Novotny <minovotn@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] New cpu-max field in query-machines QMP command output
Date: Tue, 09 Apr 2013 15:15:55 +0200 [thread overview]
Message-ID: <5164148B.4020000@redhat.com> (raw)
In-Reply-To: <20130409090613.70dd97e3@redhat.com>
On 04/09/13 15:06, Luiz Capitulino wrote:
> On Mon, 08 Apr 2013 11:14:32 -0600
> Eric Blake <eblake@redhat.com> wrote:
>
>> On 04/08/2013 10:41 AM, Michal Novotny wrote:
>>> Alter the query-machines QMP command to output information about
>>> maximum number of CPUs for each machine type with default value
>>> set to 1 in case the number of max_cpus is not set.
>>>
>>> Signed-off-by: Michal Novotny <minovotn@redhat.com>
>>> ---
>>> qapi-schema.json | 4 +++-
>>> vl.c | 1 +
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/qapi-schema.json b/qapi-schema.json
>>> index db542f6..689ca8d 100644
>>> --- a/qapi-schema.json
>>> +++ b/qapi-schema.json
>>> @@ -2861,11 +2861,13 @@
>>> #
>>> # @default: #optional whether the machine is default
>>> #
>>> +# @cpu-max: maximum number of CPUs supported by the machine type
>>
>> Typically, when adding a field in a later version than the original
>> introduction of the datatype, we add '(since 1.5)' to make it obvious
>> when to expect the field. However, as nothing (currently) enforces this
>> rule, I think such an addition is minor enough that it wouldn't
>> invalidate the use of my:
>
> Oh, it turns out I was making some confusion with this patch and
> didn't realize it was extending the query-machines command.
>
> I don't mean there's anything wrong with it, but my question is: doesn't
> this patch invalidates query-cpu-max?
Unfortunately, for libvirt query-cpu-max isn't really usable as it needs
us to start qemu with the correct machine type. This would increase
overhead as we would need to start the qemu process with a safe number
of cpus, use query-cpu-max and then restart the process.
The information added in the query-machines output can on the other hand
be cached (we are already doing this for the machine types) and used
later from the cache without increasing overhead.
So yes, I think it invalidates query-cpu-max and it can be removed in
case it wasn't released.
Peter
>
> PS: I can add the '(since 1.5)' line myself.
>
>>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>>
>
>
prev parent reply other threads:[~2013-04-09 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 16:41 [Qemu-devel] [PATCH v2] New cpu-max field in query-machines QMP command output Michal Novotny
2013-04-08 16:35 ` [Qemu-devel] Fwd: " Michal Novotny
2013-04-08 17:14 ` [Qemu-devel] " Eric Blake
2013-04-09 13:06 ` Luiz Capitulino
2013-04-09 13:09 ` Michal Novotny
2013-04-09 13:15 ` Luiz Capitulino
2013-04-09 13:32 ` Michal Novotny
2013-04-09 13:42 ` Luiz Capitulino
2013-04-09 13:59 ` Michal Novotny
2013-04-09 13:15 ` Peter Krempa [this message]
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=5164148B.4020000@redhat.com \
--to=pkrempa@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=minovotn@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.