qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Bharata B Rao <bharata@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Cc: ehabkost@redhat.com, aik@ozlabs.ru, agraf@suse.de,
	armbru@redhat.com, pbonzini@redhat.com, imammedo@redhat.com,
	david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug
Date: Mon, 22 Feb 2016 16:32:25 +0100	[thread overview]
Message-ID: <56CB2A09.9040102@suse.de> (raw)
In-Reply-To: <1456117285-22273-1-git-send-email-bharata@linux.vnet.ibm.com>

Hi Bharata,

Am 22.02.2016 um 06:01 schrieb Bharata B Rao:
> This is an attempt to implement David Gibson's RFC that was posted at
> https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg00000.html
> I am not sure if I have followed all the aspects of the RFC fully, but we
> can make changes going forward.

I am not familiar with David's RFC beyond what was portrayed on the KVM
call - this is not what we discussed on the call and I don't like it.

Further, your commits are pretty cryptic to me. Please improve your
commit messages.

For example, you add a cpu_type field and you assign it the value
TYPE_POWERPC_CPU. That's not the user-chosen CPU type then, it's a base
CPU type that cannot be instantiated. Either name it cpu_base_type or
fill it in with proper values in one patch - that patch on its own does
not create value and does not explain your claim:
"Storing CPU typename in MachineState lets us to create CPU threads
for all architectures in uniform manner from arch-neutral code."
I'm pretty sure that CPU threads cannot be created from that type, as it
would run into an assertion.

Next, you make a functionally correct refactoring of cpu_generic_init(),
but I don't understand why you duplicate that code. cpu_foo_init() still
expects things to be realized, so instead of realizing once in a central
place you do it in nine different places. Had you touched all helper
functions we might be able to move that to three places, once for
softmmu, once or twice for linux-user and once for bsd-user. But I
rather get the feeling that you misunderstand those legacy helper
functions, they're for -cpu handling and not to my knowledge used for
cpu-add at all. You should not be using them and then won't need to
touch them in this way. By using them in your supposedly QOM code you
are hiding an object_new() call inside deep layers of helper functions
instead of using QOM native functions such as object_initialize(),
object_new() and object_property_set*().

Is "CPU package" some IBM sPAPR term? It is new to me and does not match
-smp precedence, so I really don't think we should be forcing that term
on all architectures for no good reason.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

  parent reply	other threads:[~2016-02-22 15:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22  5:01 [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug Bharata B Rao
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 1/8] cpu: Store CPU typename in MachineState Bharata B Rao
2016-02-22  8:04   ` David Gibson
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 2/8] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 3/8] cpu: CPU package abstract device Bharata B Rao
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device Bharata B Rao
2016-02-22  6:44   ` Andreas Färber
2016-02-22  7:47     ` David Gibson
2016-02-22 15:58       ` Andreas Färber
2016-02-22 23:24         ` David Gibson
2016-02-22  8:05     ` Bharata B Rao
2016-02-22 15:48       ` Andreas Färber
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 5/8] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 6/8] spapr: CPU hotplug support Bharata B Rao
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 7/8] qmp: Implement query cpu-packages Bharata B Rao
2016-02-22 16:49   ` Eric Blake
2016-02-23  8:37     ` Igor Mammedov
2016-02-22  5:01 ` [Qemu-devel] [RFC PATCH v0 8/8] hmp: Implement 'info cpu-slots' Bharata B Rao
2016-02-22  5:10 ` [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug Bharata B Rao
2016-02-22 15:32 ` Andreas Färber [this message]
2016-02-22 23:28   ` David Gibson
2016-02-23  6:11   ` Bharata B Rao

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=56CB2A09.9040102@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=armbru@redhat.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).