All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org, agraf@suse.de,
	pkrempa@redhat.com
Subject: Re: [Qemu-devel] [PATCH] spapr: Don't support query-hotpluggable-cpus on earlier pseries machine types
Date: Tue, 2 Aug 2016 10:13:19 +0200	[thread overview]
Message-ID: <20160802101319.3eaf6a79@nial.brq.redhat.com> (raw)
In-Reply-To: <20160802062050.GZ2588@voom.fritz.box>

On Tue, 2 Aug 2016 16:20:50 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Tue, Aug 02, 2016 at 10:34:34AM +0530, Bharata B Rao wrote:
> > On Tue, Aug 02, 2016 at 02:25:08PM +1000, David Gibson wrote:  
> > > On Power, support for vCPU hotplug is new in qemu 2.7.  However, we
> > > currently implement the query_hotpluggable_cpus hook the same for all
> > > pseries machine type versions.
> > > 
> > > However, the old-style CPU initialization doesn't work with the new query
> > > code, meaning that attempting to use query-hotpluggable-cpus on a
> > > pseries-2.6 or earlier VM will cause qemu to SEGV.
> > > 
> > > This fixes the problem by simply disabling the hook for earlier machine
> > > types.  
> > 
> > I had sent a patch to fix this and a couple of other related issues
> > some time back and it indeed was accepted into your ppc-for-2.7 branch.
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01539.html
> > 
> > Only now I am realizing that somehow that patch didn't make it to mainline.  
> 
> Oh.. good point.  Sorry, that one somehow slipped through the cracks.
> 
> So, the remaining question is, what's the preferred behaviour for
> older machine types:
> 
>   1) should query-hotpluggable-cpus give an error, the same as it does
>      on machine types which have never supported it (this is what my
>      patch does)
> 
> or
> 
>   2) Should query-hotpluggable-cpus succeed, but return an empty list?
>      (this is what Bharata's patch does)
> 
> Igor and / or Peter, do you have an opinion on which behaviour is preferable?
> 

If it doesn't have any output then it makes sense to set handler to NULL
so it would return error.

      parent reply	other threads:[~2016-08-02  8:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1470111908-8456-1-git-send-email-david@gibson.dropbear.id.au>
     [not found] ` <20160802050434.GC16350@in.ibm.com>
2016-08-02  6:20   ` [Qemu-devel] [PATCH] spapr: Don't support query-hotpluggable-cpus on earlier pseries machine types David Gibson
2016-08-02  6:24     ` Peter Krempa
2016-08-03  2:15       ` David Gibson
2016-08-02  8:13     ` Igor Mammedov [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=20160802101319.3eaf6a79@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=pkrempa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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.