From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPm93-0000JL-Bj for qemu-devel@nongnu.org; Mon, 23 Feb 2015 01:05:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPm8z-0001nX-QA for qemu-devel@nongnu.org; Mon, 23 Feb 2015 01:05:29 -0500 Date: Mon, 23 Feb 2015 17:05:24 +1100 From: David Gibson Message-ID: <20150223060524.GD4536@voom.redhat.com> References: <1424096872-29868-1-git-send-email-mdroth@linux.vnet.ibm.com> <1424096872-29868-3-git-send-email-mdroth@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: <1424096872-29868-3-git-send-email-mdroth@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v5 02/16] spapr_drc: initial implementation of sPAPRDRConnector device 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 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2015 at 08:27:38AM -0600, Michael Roth wrote: > This device emulates a firmware abstraction used by pSeries guests to > manage hotplug/dynamic-reconfiguration of host-bridges, PCI devices, > memory, and CPUs. It is conceptually similar to an SHPC device, > complete with LED indicators to identify individual slots to physical > physical users and indicate when it is safe to remove a device. In > some cases it is also used to manage virtualized resources, such a > memory, CPUs, and physical-host bridges, which in the case of pSeries > guests are virtualized resources where the physical components are > managed by the host. >=20 > Guests communicate with these DR Connectors using RTAS calls, > generally by addressing the unique DRC index associated with a > particular connector for a particular resource. For introspection > purposes we expose this state initially as QOM properties, and > in subsequent patches will introduce the RTAS calls that make use of > it. This constitutes to the 'guest' interface. >=20 > On the QEMU side we provide an attach/detach interface to associate > or cleanup a DeviceState with a particular sPAPRDRConnector in > response to hotplug/unplug, respectively. This constitutes the > 'physical' interface to the DR Connector. >=20 > Signed-off-by: Michael Roth Reviewed-by: David Gibson Two tiny warts: [...] > +static sPAPRDRConnectorTypeShift get_type_shift(sPAPRDRConnectorType typ= e) > +{ > + uint32_t shift =3D 0; > + > + g_assert(type !=3D SPAPR_DR_CONNECTOR_TYPE_ANY); assert(is_power_of_2(type)) maybe? Nicer than an infinite loop if a bad value is passed in here. [...] > +static sPAPRDREntitySense entity_sense(sPAPRDRConnector *drc) > +{ > + if (drc->dev) { > + if (drc->type !=3D SPAPR_DR_CONNECTOR_TYPE_PCI && > + drc->allocation_state =3D=3D SPAPR_DR_ALLOCATION_STATE_UNUSA= BLE) { > + /* for logical DR, we return a state of UNUSABLE > + * iff the allocation state UNUSABLE. > + * Otherwise, report the state as USABLE/PRESENT, > + * as we would for PCI. > + */ > + return SPAPR_DR_ENTITY_SENSE_UNUSABLE; > + } > + > + /* this assumes all PCI devices are assigned to > + * a 'live insertion' power domain, where QEMU > + * manages power state automatically as opposed > + * to the guest. present, non-PCI resources are > + * unaffected by power state. > + */ > + return SPAPR_DR_ENTITY_SENSE_PRESENT; > + } > + > + if (drc->type =3D=3D SPAPR_DR_CONNECTOR_TYPE_PCI) { > + /* PCI devices, and only PCI devices, use PRESENT s/PRESENT/EMPTY/ ?? --=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 --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU6sMkAAoJEGw4ysog2bOS1OMQAKw3oGkQCTqbBsok0uAPON6C xAK65N++Ep1a7HjCu9ml2jB5mmrV67Mtrryy46bwJ197ngWATOiQlW2IJL5YXsaD 9JeXhaw5a7sRBgHEOXTFz6Sb6iDX6mDv9vLT01TQ4kluJWT6wApQi6Qf4ULmGvDM k0YROBt2+OOTORJCvKIg9rqJGKw813B0DV+I8Q40AgWnvmLWRYKDpqeO7snf7+Vn gkpt8yum3cMNb89SlySY2Bht0lZrtQb3nOmGkhKYVJlN/IvvQXSsJuvZGpZcK3Jk 8fVtT6KixGjtYCB2Dj1Kv8+HYFZh+6RtYqsHxK5nGAuCZl7e1RIw73zb1WeWZj7M vW31I8v+FbgfrGU3RZJArxw4uRAe8JgRai3UgJo4vE1MRGfGT7r0EpCWsn5G8+4m OCLQtwhyErTfTGu1tB6j+cFTWo7rLxpWhB1vep8HTy+mUiUApMNpAsUEcfW87WCI jySVRCiQXDFCrdGDu3ExGsViK9MS/2l29i5YL0xFl5NTmCGJ5Krr+4aN+3GZ5BZj 4c5ti7RLAnYpz5BlixAu0+tBumCKyfQydeTOH4By3yE59OAzV/JC7XgcIi6r8jbt ybQcTM9x+V0ZwRD+g+Va95rZ9MJ9fE0Moa2hL3yA73lxiRkQP8yDmTBfNOsKUmO0 60XkclpXnVO7gdP/+S12 =gziM -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV--