From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buuby-0008VV-6V for qemu-devel@nongnu.org; Fri, 14 Oct 2016 01:00:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buubt-00039O-SW for qemu-devel@nongnu.org; Fri, 14 Oct 2016 01:00:49 -0400 Date: Fri, 14 Oct 2016 15:35:43 +1100 From: David Gibson Message-ID: <20161014043543.GH28562@umbus> References: <1476314039-9520-1-git-send-email-mdroth@linux.vnet.ibm.com> <1476314039-9520-7-git-send-email-mdroth@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bpVaumkpfGNUagdU" Content-Disposition: inline In-Reply-To: <1476314039-9520-7-git-send-email-mdroth@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH 06/11] spapr: update spapr hotplug documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, jallen@linux.vnet.ibm.com --bpVaumkpfGNUagdU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 06:13:54PM -0500, Michael Roth wrote: > 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. >=20 > Signed-off-by: Michael Roth Reviewed-by: David Gibson > --- > docs/specs/ppc-spapr-hotplug.txt | 55 +++++++++++++++++++++++++++++++++-= ------ > 1 file changed, 46 insertions(+), 9 deletions(-) >=20 > diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotp= lug.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. > =20 > -Note that these events are not yet formally part of the PAPR+ specificat= ion, > -but support for this format has already been implemented in DR-related > -guest tools such as powerpc-utils/librtas, as well as kernel patches tha= t have > -been submitted to handle in-kernel processing of memory/cpu-related hotp= lug > -events[1], and is planned for formal inclusion is PAPR+ specification. T= he > -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" guard= s. > + > +QEMU should assume support only for "legacy" fields/flags unless the gue= st > +advertises support for the "modern" format via ibm,client-architecture-s= upport > +hcall by setting byte 5, bit 6 of it's ibm,architecture-vec-5 option vec= tor > +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 RTA= S 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 form= at > +described in LoPAPR v11, B.6.12.1. > + > +=3D=3D hotplug/unplug event structure =3D=3D > + > +The hotplug-specific payload in QEMU is implemented as follows (with all= values > encoded in big-endian format): > =20 > 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 identifi= er, > * which serves as the discrimin= ator > * for the 'drc' union field bel= ow > */ > +#ifdef GUEST_SUPPORTS_MODERN > + uint8_t capabilities; /* capability flags, currently u= nused > + * 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 whic= h) > */ > +#ifdef GUEST_SUPPORTS_MODERN > + struct { > + uint32_t count; /* number of DR resources to take > + * action on > + */ > + uint32_t index; /* DRC index of first resource t= o take > + * action on. guest will take ac= tion > + * on DRC index through > + * DRC index = in > + * sequential order > + */ > + } count_indexed; > +#endif > char name[1]; /* string representing the name = of the > * DRC to take action on > */ --=20 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 --bpVaumkpfGNUagdU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYAGCfAAoJEGw4ysog2bOSyYEP/j3lrrdX0E9prsfaNXLn9QPV goiOQxBNh0P23UBcjbK2bQeMbEvY3V5uopcN6f8PhJNSZJ+muwWHZS6NYNQroQVM dIa0w99fus46KR6siHiheacgmlDVt10E5F+X+WbZ2K2VLhx0Z8fIboE1xqptkGuP 083Lbia72GXhGpVJ57yUi9lJG1ui/pV6L9H55Of0V9+VFm2qzTk47C9qm9uHpvrX 77SJtLEjIdLkQu0SrJnSjmJIC5RJNJ8rao20ZWiaMfhThU1h7sZaytmsuNi69or4 v72/GY44PxCS/tbD5GzU/7Rh3OJzh7zFa0ebgmj91bD+r0K08pizCL6gDsi7GOYJ PYJcRsZnjC2imgoB/NKNiotajUHrIva9b5fIRc63H3eCWtaODj41l386zjohlrZJ 4zrQvB0iGOgP/WDAv1miLwTNug0TkrjzxlYWMQOWh/YZm5u0BC43uwTWUeshYgdD ukmeSUGXG8jR5aLUQHjv8A4t+ml7t8F4HNbufkiFGbNK+fxXS3839nZ7yu8J01DC npCKDUcv1rDS/Kt4v3ivjZ8NzImw2aBjD9jFBtiIsS5fugAA9eMP/RRSCko4Qrw7 w9ERXHaK+13LxPUvmnlGJrj4CZIVMW8dc19zQzXKX4S0qZN2adeT0ZwNC2gjnzDy UJcYB5pNxMGxDnltJfei =WA8c -----END PGP SIGNATURE----- --bpVaumkpfGNUagdU--