From: David Gibson <david@gibson.dropbear.id.au>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: aik@ozlabs.ru, qemu-devel@nongnu.org, agraf@suse.de,
ncmike@ncultra.org, qemu-ppc@nongnu.org,
tyreld@linux.vnet.ibm.com, bharata.rao@gmail.com,
nfont@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v4 08/17] spapr_events: re-use EPOW event infrastructure for hotplug events
Date: Tue, 27 Jan 2015 16:27:22 +1100 [thread overview]
Message-ID: <20150127052722.GD28888@voom.redhat.com> (raw)
In-Reply-To: <20150126165651.23721.17168@loki>
[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]
On Mon, Jan 26, 2015 at 10:56:51AM -0600, Michael Roth wrote:
> Quoting David Gibson (2015-01-18 22:31:23)
> > On Tue, Dec 23, 2014 at 06:30:22AM -0600, Michael Roth wrote:
> > > From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
[snip]
> > > +static void spapr_hotplug_req_event(sPAPRDRConnector *drc, uint8_t hp_action)
> > > +{
> > > + struct hp_log_full *new_hp;
> > > + struct rtas_error_log *hdr;
> > > + struct rtas_event_log_v6 *v6hdr;
> > > + struct rtas_event_log_v6_maina *maina;
> > > + struct rtas_event_log_v6_mainb *mainb;
> > > + struct rtas_event_log_v6_hp *hp;
> > > + sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > > + sPAPRDRConnectorType drc_type = drck->get_type(drc);
> > > +
> > > + new_hp = g_malloc0(sizeof(struct hp_log_full));
> > > + hdr = &new_hp->hdr;
> > > + v6hdr = &new_hp->v6hdr;
> > > + maina = &new_hp->maina;
> > > + mainb = &new_hp->mainb;
> > > + hp = &new_hp->hp;
> > > +
> > > + hdr->summary = cpu_to_be32(RTAS_LOG_VERSION_6
> > > + | RTAS_LOG_SEVERITY_EVENT
> > > + | RTAS_LOG_DISPOSITION_NOT_RECOVERED
> > > + | RTAS_LOG_OPTIONAL_PART_PRESENT
> > > + | RTAS_LOG_INITIATOR_HOTPLUG
> > > + | RTAS_LOG_TYPE_HOTPLUG);
> > > + hdr->extended_length = cpu_to_be32(sizeof(*new_hp)
> > > + - sizeof(new_hp->hdr));
> > > +
> > > + spapr_init_v6hdr(v6hdr);
> > > + spapr_init_maina(maina, 3 /* Main-A, Main-B, HP */);
> > > +
> > > + mainb->hdr.section_id = cpu_to_be16(RTAS_LOG_V6_SECTION_ID_MAINB);
> > > + mainb->hdr.section_length = cpu_to_be16(sizeof(*mainb));
> > > + mainb->subsystem_id = 0x80; /* External environment */
> > > + mainb->event_severity = 0x00; /* Informational / non-error */
> > > + mainb->event_subtype = 0x00; /* Normal shutdown */
> > > +
> > > + hp->hdr.section_id = cpu_to_be16(RTAS_LOG_V6_SECTION_ID_HOTPLUG);
> > > + hp->hdr.section_length = cpu_to_be16(sizeof(*hp));
> > > + hp->hdr.section_version = 1; /* includes extended modifier */
> > > + hp->hotplug_action = hp_action;
> > > +
> > > +
> > > + switch (drc_type) {
> > > + case SPAPR_DR_CONNECTOR_TYPE_PCI:
> > > + hp->drc.index = cpu_to_be32(drck->get_index(drc));
> > > + hp->hotplug_identifier = RTAS_LOG_V6_HP_ID_DRC_INDEX;
> > > + hp->hotplug_type = RTAS_LOG_V6_HP_TYPE_PCI;
> > > + break;
> > > + default:
> > > + /* skip notification for unknown connector types */
> > > + g_free(new_hp);
> > > + return;
> > > + }
> > > +
> > > + if (pending_hp) {
> > > + /* Just toss any pending hotplug events for now, this will
> > > + * need to be fixed later on.
> > > + */
> >
> > So, we can get away with a 1-element queue for EPOW, because they're
> > just triggering a shutdown - so once the first one's processed, any
> > others aren't going to matter. For hotplug you really do need a
> > proper queue.
>
> Yah, this was discussed in the past, but until now I didn't notice how
> easy it would be to trigger this when hotplugging multiple devices from
> a script or management harness of some sort. Should be simple enough to
> fix for v5 though.
Ok, good.
> > > + g_free(pending_hp);
> > > + }
> > > + pending_hp = new_hp;
> > > +
> > > + qemu_irq_pulse(xics_get_qirq(spapr->icp, spapr->check_exception_irq));
> > > +}
> > > +
> > > +void spapr_hotplug_req_add_event(sPAPRDRConnector *drc)
> > > +{
> > > + spapr_hotplug_req_event(drc, RTAS_LOG_V6_HP_ACTION_ADD);
> > > +}
> > > +
> > > +void spapr_hotplug_req_remove_event(sPAPRDRConnector *drc)
> > > +{
> > > + spapr_hotplug_req_event(drc, RTAS_LOG_V6_HP_ACTION_REMOVE);
> > > }
> > >
> > > static void check_exception(PowerPCCPU *cpu, sPAPREnvironment *spapr,
> > > @@ -298,15 +420,26 @@ static void check_exception(PowerPCCPU *cpu, sPAPREnvironment *spapr,
> > > xinfo |= (uint64_t)rtas_ld(args, 6) << 32;
> > > }
> > >
> > > - if ((mask & EVENT_MASK_EPOW) && pending_epow) {
> > > - if (sizeof(*pending_epow) < len) {
> > > - len = sizeof(*pending_epow);
> > > - }
> > > + if (mask & EVENT_MASK_EPOW) {
> > > + if (pending_epow) {
> > > + if (sizeof(*pending_epow) < len) {
> > > + len = sizeof(*pending_epow);
> > > + }
> > >
> > > - cpu_physical_memory_write(buf, pending_epow, len);
> > > - g_free(pending_epow);
> > > - pending_epow = NULL;
> > > - rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> > > + cpu_physical_memory_write(buf, pending_epow, len);
> > > + g_free(pending_epow);
> > > + pending_epow = NULL;
> > > + rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> > > + } else if (pending_hp) {
> >
> > So.. the hotplug messages are a different type from EPOW, but are
> > still selected by EVENT_MASK_EPOW? Seems a bit odd.
>
> It's a little odd, but it's mainly just due to the way we surface the
> hotplug event. Rather than requiring patched guest kernels, we opted
> to re-use and generalize the EPOW IRQ to also surface hotplug-related
> RTAS events, which is why we still expect the EVENT_MASK_EPOW when
> returning an HP event via check-exception.
>
> EPOW events have well-defined behavior in how they're exposed to
> userspace via rtas_errd, which allows us to add hotplug support for
> older guests via patched userspace tools.
Ok. Kind of a hack, but for good reasons. I kind of think it needs a
comment, but I'm not sure where it would belong.
--
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 #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-01-27 5:37 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 12:30 [Qemu-devel] [PATCH v4 00/17] spapr: add support for pci hotplug Michael Roth
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 01/17] docs: add sPAPR hotplug/dynamic-reconfiguration documentation Michael Roth
2015-01-16 5:28 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 02/17] spapr_drc: initial implementation of sPAPRDRConnector device Michael Roth
2015-01-02 10:32 ` Bharata B Rao
2015-01-26 4:56 ` Michael Roth
2015-01-16 6:19 ` David Gibson
2015-01-26 4:01 ` Michael Roth
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 03/17] spapr_rtas: add get/set-power-level RTAS interfaces Michael Roth
2015-01-16 6:21 ` David Gibson
2015-01-26 5:21 ` Michael Roth
2015-01-27 5:24 ` David Gibson
2015-01-27 21:36 ` Michael Roth
2015-01-27 22:05 ` Tyrel Datwyler
2015-01-28 0:42 ` Michael Roth
2015-02-09 16:29 ` Nathan Fontenot
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 04/17] spapr_rtas: add set-indicator RTAS interface Michael Roth
2015-01-16 6:25 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 05/17] spapr_rtas: add get-sensor-state " Michael Roth
2015-01-16 6:28 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 06/17] spapr: add rtas_st_buffer_direct() helper Michael Roth
2015-01-19 3:25 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 07/17] spapr_rtas: add ibm, configure-connector RTAS interface Michael Roth
2015-01-19 3:44 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 08/17] spapr_events: re-use EPOW event infrastructure for hotplug events Michael Roth
2015-01-19 4:31 ` David Gibson
2015-01-26 16:56 ` Michael Roth
2015-01-27 5:27 ` David Gibson [this message]
2015-01-28 3:56 ` Bharata B Rao
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 09/17] spapr_events: event-scan RTAS interface Michael Roth
2015-01-19 4:34 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 10/17] spapr_drc: add spapr_drc_populate_dt() Michael Roth
2015-01-19 5:15 ` David Gibson
2015-01-26 20:35 ` Michael Roth
2015-01-27 5:30 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 11/17] spapr: introduce pseries-2.3 machine type Michael Roth
2015-01-19 5:16 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 12/17] spapr_pci: add dynamic-reconfiguration option for spapr-pci-host-bridge Michael Roth
2015-01-19 5:18 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 13/17] spapr_pci: create DRConnectors for each PCI slot during PHB realize Michael Roth
2015-01-19 5:20 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 14/17] spapr_pci: populate DRC dt entries for PHBs Michael Roth
2015-01-19 5:22 ` David Gibson
2015-01-26 20:44 ` Michael Roth
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 15/17] pci: make pci_bar useable outside pci.c Michael Roth
2015-01-19 5:24 ` David Gibson
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 16/17] spapr_pci: enable basic hotplug operations Michael Roth
2015-01-19 5:58 ` David Gibson
2015-01-26 21:17 ` Michael Roth
2015-01-27 5:37 ` David Gibson
2015-01-23 5:17 ` Alexey Kardashevskiy
2015-01-26 21:20 ` Michael Roth
2014-12-23 12:30 ` [Qemu-devel] [PATCH v4 17/17] spapr_pci: emit hotplug add/remove events during hotplug Michael Roth
2015-01-19 6:00 ` David Gibson
2015-01-26 21:32 ` 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=20150127052722.GD28888@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=bharata.rao@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--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 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.