Re: [libvirt] [Qemu-devel] [PATCH v4 04/29] NUMA: convert -numa option to use OptsVisitor
On Mon, Jun 09, 2014 at 06:25:09PM +0800, Hu Tao wrote:
From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
So, this is when the ability to use multiple "cpus" ranges on -numa is finally enabled, right? Is there some capability probing mechanism that can be used by management to detect the new feature? -- Eduardo
Il 16/06/2014 16:08, Eduardo Habkost ha scritto:
Is there some capability probing mechanism that can be used by management to detect the new feature?
No, there isn't. Paolo
On 06/16/2014 08:16 AM, Paolo Bonzini wrote:
Il 16/06/2014 16:08, Eduardo Habkost ha scritto:
Is there some capability probing mechanism that can be used by management to detect the new feature?
No, there isn't.
Not even query-command-line-options? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Il 16/06/2014 16:23, Eric Blake ha scritto:
On 06/16/2014 08:16 AM, Paolo Bonzini wrote:
Il 16/06/2014 16:08, Eduardo Habkost ha scritto:
Is there some capability probing mechanism that can be used by management to detect the new feature?
No, there isn't.
Not even query-command-line-options?
No, this is a (backwards-compatible) extension to how the option is parsed. I suppose with QAPI introspection you could check if the QAPI type for -numa is defined... Paolo
On Mon, Jun 16, 2014 at 04:32:09PM +0200, Paolo Bonzini wrote:
Il 16/06/2014 16:23, Eric Blake ha scritto:
On 06/16/2014 08:16 AM, Paolo Bonzini wrote:
Il 16/06/2014 16:08, Eduardo Habkost ha scritto:
Is there some capability probing mechanism that can be used by management to detect the new feature?
No, there isn't.
Not even query-command-line-options?
No, this is a (backwards-compatible) extension to how the option is parsed.
But numa started appearing on query-command-line-options only after this patch got applied. It is not the semantics I would expect from query-command-line-options, but it is a hint that we have a QEMU version with the new numa option handling code.
I suppose with QAPI introspection you could check if the QAPI type for -numa is defined...
Does this exist, or is it just an idea? -- Eduardo
Il 16/06/2014 17:39, Eduardo Habkost ha scritto:
No, this is a (backwards-compatible) extension to how the option is parsed.
But numa started appearing on query-command-line-options only after this patch got applied. It is not the semantics I would expect from query-command-line-options, but it is a hint that we have a QEMU version with the new numa option handling code.
Oh, then indeed it's possible. I had forgotten that -numa was using ad hoc parsing code, not QemuOpts.
I suppose with QAPI introspection you could check if the QAPI type for -numa is defined... Does this exist, or is it just an idea?
Amos was working on it. Paolo
On 06/16/2014 09:46 AM, Paolo Bonzini wrote:
Il 16/06/2014 17:39, Eduardo Habkost ha scritto:
No, this is a (backwards-compatible) extension to how the option is parsed.
But numa started appearing on query-command-line-options only after this patch got applied. It is not the semantics I would expect from query-command-line-options, but it is a hint that we have a QEMU version with the new numa option handling code.
Oh, then indeed it's possible. I had forgotten that -numa was using ad hoc parsing code, not QemuOpts.
Then we have our witness, even without waiting for introspection :)
I suppose with QAPI introspection you could check if the QAPI type for -numa is defined... Does this exist, or is it just an idea?
Amos was working on it.
Although given that soft freeze is tomorrow, it looks very unlikely that we'll have it in 2.1. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eduardo Habkost -
Eric Blake -
Paolo Bonzini