qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device


From: David Gibson
Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device
Date: Tue, 12 Jan 2016 14:54:34 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

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 <address@hidden> wrote:
> 
> > Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> > > On Wed, 16 Dec 2015 16:19:06 +0100
> > > Andreas Färber <address@hidden> 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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]