All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Igor Mammedov <imammedo@redhat.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com,
	qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com,
	"Bharata B Rao" <bharata@linux.vnet.ibm.com>,
	pbonzini@redhat.com, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device
Date: Tue, 12 Jan 2016 14:54:34 +1100	[thread overview]
Message-ID: <20160112035434.GI22925@voom.redhat.com> (raw)
In-Reply-To: <20151216182220.258dc9f0@igors-macbook-pro.local>

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

On Wed, Dec 16, 2015 at 06:22:20PM +0100, Igor Mammedov wrote:
> On Wed, 16 Dec 2015 16:57:54 +0100
> Andreas Färber <afaerber@suse.de> wrote:
> 
> > Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> > > On Wed, 16 Dec 2015 16:19:06 +0100
> > > Andreas Färber <afaerber@suse.de> wrote:
> > > 
> > >> Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
> > >>> CPU hotplug granularity
> > >>> -----------------------
> > >>> CPU hotplug will now be done in cpu-core device granularity.
> > >>
> > >> Nack.
> > >>
> > >>> Are there archs that would need thread level CPU addition ?
> > >>
> > >> Yes, s390. And for x86 people called for socket level.
> > > socket level hotplug would be the last resort if we can't agree
> > > on thread level one. As it would break existing setups where
> > > user can hotplug 1 core, and  I'd like to avoid it if it is
> > > possible.
> > 
> > We still need to keep cpu-add for backwards compatibility, so I am
> > discussing solely the new device_add interface. My previous x86 series
> > went to severe hacks trying to keep cpu-add working with
> > sockets&cores.
> if possible, it would be better to make cpu-add to use device_add
> internally.
> 
> > 
> > Attendees in Seattle said that thread-level hot-plug were dangerous
> > for Linux guests due to assumptions in the (guest's) scheduler
> > breaking for any incompletely filled cores or sockets. No one present
> There is not such thing as cpu hotplug at socket level in x86 linux so far.
> CPUs are plugged at logical(thread) cpu level, one at a time.
> And ACPI spec does the same (describes logical CPUs) and hotplug
> notification in guest handled per one logical cpu at a time.

I don't think that precludes handling hotplug at socket level in
qemu.  The user <-> qemu interaction can work on the socket level,
then the qemu <-> guest interaction on the thread level, iterating
through the threads in the socket.

Problems arise when the qemu <-> guest protocol is at a coarser
granularity than the user <-> qemu protocol, rather than the other way
around, AFAICT.

This is the problem we have with the existing interfaces for Power -
there the qemu <-> guest protocol specified by the platform has no way
of representing a single thread hotplug, it's always a core at a time
(as a paravirt platform, there's not really a useful difference
between cores and sockets).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      parent reply	other threads:[~2016-01-12  4:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  6:15 [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2015-12-10 10:25   ` Daniel P. Berrange
2015-12-11  3:24     ` Bharata B Rao
2015-12-14 17:37       ` Eduardo Habkost
2015-12-15  8:41         ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState Bharata B Rao
2015-12-14 17:29   ` Eduardo Habkost
2015-12-15  8:38     ` Bharata B Rao
2015-12-15 15:31       ` Eduardo Habkost
2015-12-16 16:54       ` Igor Mammedov
2015-12-16 19:39         ` Eduardo Habkost
2015-12-16 22:26           ` Igor Mammedov
2015-12-17 18:09             ` Eduardo Habkost
2015-12-18 10:46               ` Igor Mammedov
2015-12-18 15:51                 ` Eduardo Habkost
2015-12-18 16:01                   ` Igor Mammedov
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 4/9] cpu: CPU socket backend Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 6/9] cpu: Introduce CPU core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn Bharata B Rao
2015-12-14 17:44   ` Eduardo Habkost
2015-12-15  8:14     ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10 12:35 ` [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Igor Mammedov
2015-12-11  3:57   ` Bharata B Rao
2015-12-15  5:27     ` Zhu Guihua
2015-12-16 15:16       ` Andreas Färber
2015-12-16 15:11     ` Igor Mammedov
2015-12-17  9:19       ` Peter Krempa
2015-12-16 15:46   ` Andreas Färber
2015-12-16 21:58     ` Igor Mammedov
2015-12-24  1:59       ` Zhu Guihua
2015-12-29 13:52         ` Igor Mammedov
2016-01-01  3:47     ` Bharata B Rao
2016-01-04 12:52       ` Igor Mammedov
2015-12-10 20:25 ` Matthew Rosato
2015-12-14  6:25   ` Bharata B Rao
2015-12-16 15:19 ` Andreas Färber
2015-12-16 15:44   ` Igor Mammedov
2015-12-16 15:57     ` Andreas Färber
2015-12-16 17:22       ` Igor Mammedov
2015-12-16 22:37         ` Igor Mammedov
2016-01-12  3:54         ` David Gibson [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=20160112035434.GI22925@voom.redhat.com \
    --to=david@gibson.dropbear.id.au \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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.