From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Bharata B Rao <bharata.rao@gmail.com>
Cc: aik@ozlabs.ru, Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
ncmike@ncultra.org, "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
tyreld@linux.vnet.ibm.com,
Nathan Fontenot <nfont@linux.vnet.ibm.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v6 02/15] spapr_drc: initial implementation of sPAPRDRConnector device
Date: Fri, 27 Feb 2015 12:30:33 -0600 [thread overview]
Message-ID: <20150227183033.433.28805@loki> (raw)
In-Reply-To: <CAGZKiBrgzVJnA-th9nq96knx2d950mMB_CgKV77H_36L0KT-0w@mail.gmail.com>
Quoting Bharata B Rao (2015-02-27 03:52:09)
> On Fri, Feb 27, 2015 at 8:41 AM, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > +static void attach(sPAPRDRConnector *drc, DeviceState *d, void *fdt,
> > + int fdt_start_offset, bool coldplug, Error **errp)
> > +{
> > + DPRINTFN("drc: %x, attach", get_index(drc));
> > +
> > + if (drc->isolation_state != SPAPR_DR_ISOLATION_STATE_ISOLATED) {
> > + error_setg(errp, "an attached device is still awaiting release");
> > + return;
> > + }
> > + g_assert(drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_UNUSABLE);
> > + g_assert(fdt || coldplug);
> > +
> > + /* NOTE: setting initial isolation state to UNISOLATED means we can't
> > + * detach unless guest has a userspace/kernel that moves this state
> > + * back to ISOLATED in response to an unplug event, or this is done
> > + * manually by the admin prior. if we force things while the guest
> > + * may be accessing the device, we can easily crash the guest, so we
> > + * we defer completion of removal in such cases to the reset() hook.
> > + */
> > + drc->isolation_state = SPAPR_DR_ISOLATION_STATE_UNISOLATED;
> > + drc->allocation_state = SPAPR_DR_ALLOCATION_STATE_USABLE;
>
> BTW shouldn't isolation_state and allocation_state be set to
> UNISOLATED and USABLE in response to guest's rtas-set-indicator calls
> ? At least, that is how it is done/expected for CPU hotplug case. Ref:
Well, for PCI we always start in USABLE (state diagram in PAPR+ 13.4), and
stay there. So set_allocation_state() should actually be a no-op for PCI;
there's no valid transition to UNUSABLE (or EXCHANGE/RECOVER).
For non-PCI, it looks like we should start in UNUSABLE, and let RTAS take it
from there. It also looks like the resource removal shouldn't be finalized
until there's a transition from ISOLATED/USABLE to ISOLATED/UNUSABLE.
I just pushed a patch here that I'm hoping will fix the non-PCI cases. Can
you give it a spin and let me know?
https://github.com/mdroth/qemu/commit/d91b0c6d6f794292e384cf129368aaae90294f5b
> kernel code arch/powerpc/platforms/pseries/dlpar.c:
> dlpar_acquire[release]_drc().
>
> Same question for detach().
>
> Regards,
> Bharata.
next prev parent reply other threads:[~2015-02-27 18:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 3:11 [Qemu-devel] [PATCH v6 00/15] spapr: add support for pci hotplug Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 01/15] docs: add sPAPR hotplug/dynamic-reconfiguration documentation Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 02/15] spapr_drc: initial implementation of sPAPRDRConnector device Michael Roth
2015-02-27 8:02 ` Bharata B Rao
2015-02-27 9:52 ` Bharata B Rao
2015-02-27 18:30 ` Michael Roth [this message]
2015-02-28 9:19 ` Bharata B Rao
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 03/15] spapr_rtas: add get/set-power-level RTAS interfaces Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 04/15] spapr_rtas: add set-indicator RTAS interface Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 05/15] spapr_rtas: add get-sensor-state " Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 06/15] spapr: add rtas_st_buffer_direct() helper Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 07/15] spapr_rtas: add ibm, configure-connector RTAS interface Michael Roth
2015-03-02 7:02 ` David Gibson
2015-03-03 4:40 ` Michael Roth
2015-03-03 5:33 ` David Gibson
2015-03-04 5:50 ` Michael Roth
2015-03-04 13:37 ` Michael Roth
2015-03-05 4:30 ` David Gibson
2015-03-05 14:12 ` Michael Roth
2015-03-12 5:52 ` David Gibson
2015-03-17 3:31 ` Michael Roth
2015-03-23 0:48 ` David Gibson
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 08/15] spapr_events: re-use EPOW event infrastructure for hotplug events Michael Roth
2015-03-03 5:45 ` David Gibson
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 09/15] spapr_events: event-scan RTAS interface Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 10/15] spapr_drc: add spapr_drc_populate_dt() Michael Roth
2015-03-03 5:52 ` David Gibson
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 11/15] spapr_pci: add dynamic-reconfiguration option for spapr-pci-host-bridge Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 12/15] spapr_pci: create DRConnectors for each PCI slot during PHB realize Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 13/15] pci: make pci_bar useable outside pci.c Michael Roth
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 14/15] spapr_pci: enable basic hotplug operations Michael Roth
2015-03-03 6:08 ` David Gibson
2015-02-27 3:11 ` [Qemu-devel] [PATCH v6 15/15] spapr_pci: emit hotplug add/remove events during hotplug Michael Roth
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=20150227183033.433.28805@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=bharata.rao@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=ncmike@ncultra.org \
--cc=nfont@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=tyreld@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).