qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus lis


From: Peter Krempa
Subject: Re: [Qemu-devel] [RFC 1/2] spapr: Reverse order of hotpluggable cpus list
Date: Wed, 20 Jul 2016 09:01:11 +0200
User-agent: Mutt/1.6.2 (2016-06-11)

On Wed, Jul 20, 2016 at 11:00:05 +1000, David Gibson wrote:
> On Tue, Jul 19, 2016 at 01:52:40PM +0200, Peter Krempa wrote:
> > On Mon, Jul 18, 2016 at 19:19:19 +1000, David Gibson wrote:
> > > The spapr implementation of query-hotpluggable-cpus builds the list of
> > > hotpluggable cores from the end (most removed from the list head)
> > > because that's the easiest way with a singly linked list.  Because it
> > > also traverses the possible CPU cores starting from low indexes the
> > > resulting list has the cpu cores listed in reverse order by core-id.
> > > 
> > > That's not generally harmful, but it means the output from "info
> > > hotpluggable-cpus" is a little harder to read than it could be.
> > > 
> > > Therefore, traverse the cpus in reverse order so that the final list
> > > ends up in increasing-core-id order.
> > 
> > To make this interface usable with in-order hotplug the ordering of the
> > entries should be codified in the schema documentation. (see my response
> > on the cover letter for justification).
> 
> I'm not really sure what you mean by this.

Currently the order of entries in reply of query-hotpluggable-cpus is
arbitrary as this patch hints.

If qemu won't support arbitrary order hotplug but libvirt should be able
to use the new interface, then the order of replies of
query-hotpluggable-cpus need to corelate (in a documented fashion) with
the order we need to plug the cpus in. By not documenting any order
libvirt can just guess it (by reimplementing the algorithm in qemu).

I've pointed this out in a sub-thread of the cover-letter.

Peter



reply via email to

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