All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Bandan Das <bsd@redhat.com>, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option
Date: Thu, 20 Jun 2013 15:34:33 +0400	[thread overview]
Message-ID: <51C2E8C9.9030503@msgid.tls.msk.ru> (raw)
In-Reply-To: <51C2D0EA.7060204@redhat.com>

20.06.2013 13:52, Paolo Bonzini wrote:
> Il 20/06/2013 11:30, Igor Mammedov ha scritto:
>>>> libvirt uses the "cpus" option already, so we have to keep it working.
>> Sure, we can leave it as it's now for some time while a new interface is
>> introduced/adopted. And than later deprecate "cpus".
> 
> So, you used a new name because the new behavior of "-numa
> node,cpus=1-2,cpus=3-4" would be incompatible with the old.

BTW, as I tried to touch exactly the same place yesterday (trying
to convert it to QemuOpts) -- what does this "node" mean?

For example, with

  -device [type=]devicetype,foo=bar,xzy=abc

this creates a new device for each "invocation" of option.  But
what does this `-numa node' mean?  Can there be anything else
besides node?  Why it is needed/used for?

This -numa option is the last one which uses the old option
parsing mechanism (there's also some smbios-related thing
but it's simple to convert, I almost got it ready yesterday),
but it is rather non-standard.

Thanks,

/mjt

  reply	other threads:[~2013-06-20 11:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18 20:09 [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option Bandan Das
2013-06-19 11:42 ` Igor Mammedov
2013-06-19 13:26   ` Eduardo Habkost
2013-06-20  9:30     ` Igor Mammedov
2013-06-20  9:52       ` Paolo Bonzini
2013-06-20 11:34         ` Michael Tokarev [this message]
2013-06-20 13:02           ` Paolo Bonzini
2013-06-20 13:26         ` Eduardo Habkost
2013-06-20 13:30           ` Paolo Bonzini
2013-06-20 16:02             ` Bandan Das
2013-06-21  6:53               ` Wanlong Gao
2013-06-21 14:51                 ` Bandan Das

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=51C2E8C9.9030503@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=bsd@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@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.