Re: [Qemu-devel] [PATCH v4 01/17] docs: add sPAPR hotplug/dynamic-reconfiguration documentation

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

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.
> 
> As specified in PAPR+ v2.7.
> 
> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> ---
>  docs/specs/ppc-spapr-hotplug.txt | 287 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 287 insertions(+)
>  create mode 100644 docs/specs/ppc-spapr-hotplug.txt
> 
> diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
> new file mode 100644
> index 0000000..6f2863f
> --- /dev/null
> +++ b/docs/specs/ppc-spapr-hotplug.txt
> @@ -0,0 +1,287 @@
> += sPAPR Dynamic Reconfiguration =
> +
> +sPAPR/"pseries" guests make use a facility called dynamic-reconfiguration 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 provided
> +to guests as virtualized resources. The specifics of dynamic-reconfiguration
> +are documented extensively in PAPR+ v2.7, Section 13.1. This document
> +provides a summary of that information as it applies to the implementation
> +within QEMU.
> +
> +== Dynamic-reconfiguration Connectors ==
> +
> +To manage hotplug/unplug of these resources, a firmware abstraction known 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.
> +
> +== Device-tree description of DRCs ==
> +
> +A set of 4 array Open Firmware device tree properties are used to describe
> +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 different
> +paths in the device tree depending on the type of resource the DRCs manage.
> +
> +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 <name> string encoded as a byte array
> +
> +  <name> 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 resources
> +  of that type.
> +
> +  <name> 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 debugging
> +  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 <david@gibson.dropbear.id.au>

-- 
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 --]