qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: nfont@linux.vnet.ibm.com, david@gibson.dropbear.id.au,
	qemu-ppc@nongnu.org, jallen@linux.vnet.ibm.com,
	bharata@linux.vnet.ibm.com
Subject: [Qemu-devel] [PATCH 05/10] spapr: update spapr hotplug documentation
Date: Mon, 24 Oct 2016 23:47:31 -0500	[thread overview]
Message-ID: <1477370856-8940-6-git-send-email-mdroth@linux.vnet.ibm.com> (raw)
In-Reply-To: <1477370856-8940-1-git-send-email-mdroth@linux.vnet.ibm.com>

This updates the existing documentation to reflect recent updates to
the hotplug event structure, which are in draft form but slated
for inclusion in PAPR/LoPAPR.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
 docs/specs/ppc-spapr-hotplug.txt | 55 +++++++++++++++++++++++++++++++++-------
 1 file changed, 46 insertions(+), 9 deletions(-)

diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
index 631b0ca..f57e2a0 100644
--- a/docs/specs/ppc-spapr-hotplug.txt
+++ b/docs/specs/ppc-spapr-hotplug.txt
@@ -233,12 +233,27 @@ tools by host-level management such as an HMC. This level of management is not
 applicable to PowerKVM, hence the reason for extending the notification
 framework to support hotplug events.
 
-Note that these events are not yet formally part of the PAPR+ specification,
-but support for this format has already been implemented in DR-related
-guest tools such as powerpc-utils/librtas, as well as kernel patches that have
-been submitted to handle in-kernel processing of memory/cpu-related hotplug
-events[1], and is planned for formal inclusion is PAPR+ specification. The
-hotplug-specific payload is QEMU implemented as follows (with all values
+The format for these EPOW-signalled events is described below under
+"hotplug/unplug event structure". Note that these events are not
+formally part of the PAPR+ specification, and have been superseded by a
+newer format, also described below under "hotplug/unplug event structure",
+and so are now deemed a "legacy" format. The formats are similar, but the
+"modern" format contains additional fields/flags, which are denoted for the
+purposes of this documentation with "#ifdef GUEST_SUPPORTS_MODERN" guards.
+
+QEMU should assume support only for "legacy" fields/flags unless the guest
+advertises support for the "modern" format via ibm,client-architecture-support
+hcall by setting byte 5, bit 6 of it's ibm,architecture-vec-5 option vector
+structure (as described by LoPAPR v11, B.6.2.3). As with "legacy" format events,
+"modern" format events are surfaced to the guest via check-exception RTAS calls,
+but use a dedicated event source to signal the guest. This event source is
+advertised to the guest by the addition of a "hot-plug-events" node under
+"/event-sources" node of the guest's device tree using the standard format
+described in LoPAPR v11, B.6.12.1.
+
+== hotplug/unplug event structure ==
+
+The hotplug-specific payload in QEMU is implemented as follows (with all values
 encoded in big-endian format):
 
 struct rtas_event_log_v6_hp {
@@ -263,14 +278,23 @@ struct rtas_event_log_v6_hp {
 #define RTAS_LOG_V6_HP_ACTION_ADD       1
 #define RTAS_LOG_V6_HP_ACTION_REMOVE    2
     uint8_t hotplug_action;             /* action (add/remove) */
-#define RTAS_LOG_V6_HP_ID_DRC_NAME      1
-#define RTAS_LOG_V6_HP_ID_DRC_INDEX     2
-#define RTAS_LOG_V6_HP_ID_DRC_COUNT     3
+#define RTAS_LOG_V6_HP_ID_DRC_NAME          1
+#define RTAS_LOG_V6_HP_ID_DRC_INDEX         2
+#define RTAS_LOG_V6_HP_ID_DRC_COUNT         3
+#ifdef GUEST_SUPPORTS_MODERN
+#define RTAS_LOG_V6_HP_ID_DRC_COUNT_INDEXED 4
+#endif
     uint8_t hotplug_identifier;         /* type of the resource identifier,
                                          * which serves as the discriminator
                                          * for the 'drc' union field below
                                          */
+#ifdef GUEST_SUPPORTS_MODERN
+    uint8_t capabilities;               /* capability flags, currently unused
+                                         * by QEMU
+                                         */
+#else
     uint8_t reserved;
+#endif
     union {
         uint32_t index;                 /* DRC index of resource to take action
                                          * on
@@ -278,6 +302,19 @@ struct rtas_event_log_v6_hp {
         uint32_t count;                 /* number of DR resources to take
                                          * action on (guest chooses which)
                                          */
+#ifdef GUEST_SUPPORTS_MODERN
+        struct {
+            uint32_t count;             /* number of DR resources to take
+                                         * action on
+                                         */
+            uint32_t index;             /* DRC index of first resource to take
+                                         * action on. guest will take action
+                                         * on DRC index <index> through
+                                         * DRC index <index + count - 1> in
+                                         * sequential order
+                                         */
+        } count_indexed;
+#endif
         char name[1];                   /* string representing the name of the
                                          * DRC to take action on
                                          */
-- 
1.9.1

  parent reply	other threads:[~2016-10-25  4:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25  4:47 [Qemu-devel] [PATCH 00/10] spapr: option vector re-work and memory unplug support Michael Roth
2016-10-25  4:47 ` [Qemu-devel] [PATCH 01/10] spapr_ovec: initial implementation of option vector helpers Michael Roth
2016-10-25 23:54   ` David Gibson
2016-10-25  4:47 ` [Qemu-devel] [PATCH 02/10] spapr_hcall: use spapr_ovec_* interfaces for CAS options Michael Roth
2016-10-25  4:47 ` [Qemu-devel] [PATCH 03/10] spapr: add option vector handling in CAS-generated resets Michael Roth
2016-10-25 23:56   ` David Gibson
2016-10-25  4:47 ` [Qemu-devel] [PATCH 04/10] spapr: improve ibm, architecture-vec-5 property handling Michael Roth
2016-10-25 23:58   ` David Gibson
2016-10-26  1:34     ` David Gibson
2016-10-25  4:47 ` Michael Roth [this message]
2016-10-25  4:47 ` [Qemu-devel] [PATCH 06/10] spapr: add hotplug interrupt machine options Michael Roth
2016-10-26  0:25   ` David Gibson
2016-10-25  4:47 ` [Qemu-devel] [PATCH 07/10] spapr_events: add support for dedicated hotplug event source Michael Roth
2016-10-26  0:42   ` David Gibson
2016-10-26 21:44     ` Michael Roth
2016-10-25  4:47 ` [Qemu-devel] [PATCH 08/10] spapr: Add DRC count indexed hotplug identifier type Michael Roth
2016-10-26  0:48   ` David Gibson
2016-10-25  4:47 ` [Qemu-devel] [PATCH 09/10] spapr: use count+index for memory hotplug Michael Roth
2016-10-26  0:49   ` David Gibson
2016-10-25  4:47 ` [Qemu-devel] [PATCH 10/10] spapr: Memory hot-unplug support Michael Roth
2016-10-26  0:57   ` David Gibson
2016-10-26  0:02 ` [Qemu-devel] [PATCH 00/10] spapr: option vector re-work and memory unplug support 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=1477370856-8940-6-git-send-email-mdroth@linux.vnet.ibm.com \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=jallen@linux.vnet.ibm.com \
    --cc=nfont@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 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).