From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC0O6-0004tk-Vr for qemu-devel@nongnu.org; Fri, 16 Jan 2015 01:28:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YC0O4-0005CX-EU for qemu-devel@nongnu.org; Fri, 16 Jan 2015 01:28:06 -0500 Date: Fri, 16 Jan 2015 16:28:19 +1100 From: David Gibson Message-ID: <20150116052819.GI5297@voom.fritz.box> References: <1419337831-16552-1-git-send-email-mdroth@linux.vnet.ibm.com> <1419337831-16552-2-git-send-email-mdroth@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liqSWPDvh3eyfZ9k" Content-Disposition: inline In-Reply-To: <1419337831-16552-2-git-send-email-mdroth@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v4 01/17] docs: add sPAPR hotplug/dynamic-reconfiguration documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth 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 --liqSWPDvh3eyfZ9k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 23, 2014 at 06:30:15AM -0600, Michael Roth wrote: > This adds a general overview of hotplug/dynamic-reconfiguration > for sPAPR/pSeries guest. >=20 > As specified in PAPR+ v2.7. >=20 > Signed-off-by: Michael Roth > --- > docs/specs/ppc-spapr-hotplug.txt | 287 +++++++++++++++++++++++++++++++++= ++++++ > 1 file changed, 287 insertions(+) > create mode 100644 docs/specs/ppc-spapr-hotplug.txt >=20 > diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotp= lug.txt > new file mode 100644 > index 0000000..6f2863f > --- /dev/null > +++ b/docs/specs/ppc-spapr-hotplug.txt > @@ -0,0 +1,287 @@ > +=3D sPAPR Dynamic Reconfiguration =3D > + > +sPAPR/"pseries" guests make use a facility called dynamic-reconfiguratio= n to > +handle hotplugging of dynamic "physical" resources like PCI cards, or > +"logical"/paravirtual resources like memory, CPUs, and "physical" > +host-bridges, which are generally managed by the host/hypervisor and pro= vided > +to guests as virtualized resources. The specifics of dynamic-reconfigura= tion > +are documented extensively in PAPR+ v2.7, Section 13.1. This document > +provides a summary of that information as it applies to the implementati= on > +within QEMU. > + > +=3D=3D Dynamic-reconfiguration Connectors =3D=3D > + > +To manage hotplug/unplug of these resources, a firmware abstraction know= n as > +a Dynamic Resource Connector (DRC) is used to assign a particular dynamic > +resource to the guest, and provide an interface for the guest to manage > +configuration/removal of the resource associated with it. > + > +=3D=3D Device-tree description of DRCs =3D=3D > + > +A set of 4 array Open Firmware device tree properties are used to descri= be > +the name/index/power-domain/type of each DRC allocated to a guest at > +boot-time. There may be multiple sets of these arrays, rooted at differe= nt > +paths in the device tree depending on the type of resource the DRCs mana= ge. > + > +In some cases, the DRCs themselves may be provided by a dynamic resource, > +such as the DRCs managed PCI slots on a hotplugged PHB. In this case the > +arrays would be fetched as part of the device tree retrieval interfaces > +for hotplugged resources described under "Guest->Host interface". > + > +The array properties are described below. Each entry/element in an array > +describes the DRC identified by the element in the corresponding position > +of ibm,drc-indexes: > + > +ibm,drc-names: > + first 4-bytes: BE-encoded integer denoting the number of entries > + each entry: a NULL-terminated string encoded as a byte array > + > + values for logical/virtual resources are defined in PAPR+ v2.7, > + Section 13.5.2.4, and basically consist of the type of the resource > + followed by a space and a numerical value that's unique across resourc= es > + of that type. > + > + values for "physical" resources such as PCI or VIO devices are > + defined as being "location codes", which are the "location labels" of > + each encapsulating device, starting from the chassis down to the > + individual slot for the device, concatenated by a hyphen. This provides > + a mapping of resources to a physical location in a chassis for debuggi= ng > + purposes. For QEMU, this mapping is less important, so we assign a > + location code that confirms to naming specifications, but is simply a s/confirms/conforms/ Otherwise, nice write up. Reviewed-by: David Gibson --=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 --liqSWPDvh3eyfZ9k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUuKFzAAoJEGw4ysog2bOSblYP/iVT6cYYBWZcsb3a2zH4SXPo 4BRahbJeb1vWdJJ+5EIK+A8NnVeoPHa+NlnDvGHTEOGZvhpBaAb9tig84PcuPM9/ Dfad1HBCpa6WD7TYmj+0eF0dZfEZRoto7akhZNfNlEh2OgEHd0zGXvzACEZfNKZm lf4Tgp9dMYgv1qyaL7KWgbltCPscEdX3fxwAH36mM+KzMhxNQAsqeMyzpa1jh8c5 08sUJYlYHh13y/rkDi3FDUJ4Efx5ZbbNCHj0PXWoCtkL0FNFpbveCjCSD2jFtEh2 FGZM7S49Df7HbHlrn1NLmPEbim64+wLKumQW6hetcLaFCd4kPJhljVveU3nXN3O7 7MHy6zXsDZXoFYnXpJ7ms1lsrYp/THBl9+hWVb0y3Drhj4UxTr4adPqbXaO+m4pb CNfPS6XzLNYcEGYnvkJ/EDi8tpkhTWYIwdEe5TNYH1l0bStrNrCmQgXJqCpuz7ia fDxnDvlTtop9Yji5uOi+YD69oT0UP4DWW9u9eDpmVUra8rAbQUP13i8DFE50UiMg 6g+KBWp50O7wPvXK6tM1DVd8lmHT7ycsunrQ8XF4d2MjHhaO5+22g5BZZpR4DOLc xkLK2i2fvsrf5ngLf/0Vj7p+KX5UnMAgC0wfbNkiVzkEvO63sXNguiAp8zOAND6c FDQcPbXHA99/JC+VDHu3 =XAnX -----END PGP SIGNATURE----- --liqSWPDvh3eyfZ9k--