All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [FIX PATCH] spapr_drc: Return correct state for logical DR in entity_sense()
Date: Wed, 9 Sep 2015 09:32:32 +0530	[thread overview]
Message-ID: <20150909040232.GB17433@in.ibm.com> (raw)
In-Reply-To: <20150908220325.10296.24993@loki>

On Tue, Sep 08, 2015 at 05:03:25PM -0500, Michael Roth wrote:
> Quoting Michael Roth (2015-09-08 16:03:56)
> > Quoting David Gibson (2015-09-07 20:22:50)
> > > On Mon, Sep 07, 2015 at 11:37:04AM +0530, Bharata B Rao wrote:
> > > > When drmgr is run in the guest to add a device for which device_add
> > > > hasn't been issued in QEMU, configure-connector call fails.
> > > > When configure-connector call fails, the guest would release (*)
> > > > the previously acquired DRC by setting back the DRC isolation state
> > > > to ISOLATED and allocation state to UNUSABLE. These calls will be issued
> > > > only if get-sensor-state call returns PRESENT state. However currently for
> > > > a logical DR, entity_sense() would unconditinally return UNUSABLE
> > > > state only. This prevents any subsequent hotplug of the device with
> > > > that DRC.
> > 
> > This seems a little odd. I think we default to ALLOCATION_STATE_UNUSABLE
> > for logical DR, and it's up the guest to transition to USABLE, which
> > probably happens prior to the configure-connector calls. So I think the
> > net effect of this fix is that guest will see these unallocated/unattached
> > resources the same way they would a resource that was actually attached
> > via device_add, and all we're really doing is working around the
> > eventual configuration failure that that will lead to by pretending a
> > resource was actually there.
> > 
> > According to PAPR+ 2.7:
> > 
> > 13.7.3.1 Acquire Logical Resource from Resource Pool:
> > 
> >   If the state is “unusable” the OS issues set-indicator (allocation-state, usable) to attempt to allocate the re-
> >   source. Similarly, if the state is “available for exchange” the OS issues set-indicator (allocation-state, ex-
> >   change) to attempt to allocate the resource, and if the state is “available for recovery” the OS issues
> >   set-indicator (allocation-state, recover) to attempt to allocate the resource.
> > 
> > and
> > 
> > 13.7 Logical Resource Dynamic Reconfiguration (LRDR):
> > 
> >   The OS may use the get-sensor-state RTAS call with the dr-entity-sense token to deter-
> > mine if a given drc-index refers to a connector that is currently usable for DR operations. If the connector is not
> > currently usable the return state is “DR entity unusable” (2). A set-indicator (isolation state) RTAS call to an unusable
> > connector or (dr-indicator) to any logical resource connector results in a “No such indicator implemented” return sta-
> > tus.  
> > 
> > So I think maybe the proper fix is to make sure that
> > drc->set_indicator_state() fails with an error that indicates to RTAS to
> > return NO_SENSOR (-3) for cases where we haven't attached a resource
> > to the DRC via device_add.
> 
> Patch incoming:
> 
>   spapr_drc: don't allow 'empty' DRCs to be unisolated
> 
> applies to spapr-next but requires revert of this patch.

Yes, please revert this patch in favour of Michael's.

> 
> Bharata, can you give it a spin with CPU hotplug and see if it fixes the
> issue you hit?

Yes it does, thanks.

Regards,
Bharata.

  reply	other threads:[~2015-09-09  4:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07  6:07 [Qemu-devel] [FIX PATCH] spapr_drc: Return correct state for logical DR in entity_sense() Bharata B Rao
2015-09-08  1:22 ` David Gibson
2015-09-08 21:03   ` Michael Roth
2015-09-08 21:06     ` Michael Roth
2015-09-08 22:03     ` Michael Roth
2015-09-09  4:02       ` Bharata B Rao [this message]
2015-09-09  6:05         ` David Gibson
2015-09-09  4:13       ` David Gibson

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=20150909040232.GB17433@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=mdroth@linux.vnet.ibm.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.