From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQBF2-0006Gu-V3 for qemu-devel@nongnu.org; Tue, 24 Feb 2015 03:53:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQBEy-0001JZ-GA for qemu-devel@nongnu.org; Tue, 24 Feb 2015 03:53:20 -0500 Date: Tue, 24 Feb 2015 17:40:32 +1100 From: David Gibson Message-ID: <20150224064032.GQ4536@voom.redhat.com> References: <1424096872-29868-1-git-send-email-mdroth@linux.vnet.ibm.com> <1424096872-29868-8-git-send-email-mdroth@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oN4OvwWIcd1E23D1" Content-Disposition: inline In-Reply-To: <1424096872-29868-8-git-send-email-mdroth@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v5 07/16] spapr_rtas: add ibm, configure-connector RTAS interface 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 --oN4OvwWIcd1E23D1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2015 at 08:27:43AM -0600, Michael Roth wrote: > This interface is used to fetch an OF device-tree nodes that describes a > newly-attached device to guest. It is called multiple times to walk the > device-tree node and fetch individual properties into a 'workarea'/buffer > provided by the guest. >=20 > The device-tree is generated by QEMU and passed to an sPAPRDRConnector du= ring > the initial hotplug operation, and the state of these RTAS calls is track= ed by > the sPAPRDRConnector. When the last of these properties is successfully > fetched, we report as special return value to the guest and transition > the device to a 'configured' state on the QEMU/DRC side. >=20 > See docs/specs/ppc-spapr-hotplug.txt for a complete description of > this interface. >=20 > Signed-off-by: Michael Roth > --- > hw/ppc/spapr_rtas.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++= ++++++ > 1 file changed, 81 insertions(+) >=20 > diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c > index f80beb2..b8551b0 100644 > --- a/hw/ppc/spapr_rtas.c > +++ b/hw/ppc/spapr_rtas.c > @@ -418,6 +418,85 @@ static void rtas_get_sensor_state(PowerPCCPU *cpu, s= PAPREnvironment *spapr, > rtas_st(rets, 1, entity_sense); > } > =20 > +/* configure-connector work area offsets, int32_t units for field > + * indexes, bytes for field offset/len values. > + * > + * as documented by PAPR+ v2.7, 13.5.3.5 > + */ > +#define CC_IDX_NODE_NAME_OFFSET 2 > +#define CC_IDX_PROP_NAME_OFFSET 2 > +#define CC_IDX_PROP_LEN 3 > +#define CC_IDX_PROP_DATA_OFFSET 4 > +#define CC_VAL_DATA_OFFSET ((CC_IDX_PROP_DATA_OFFSET + 1) * 4) > +#define CC_WA_LEN 4096 > + > +static void rtas_ibm_configure_connector(PowerPCCPU *cpu, > + sPAPREnvironment *spapr, > + uint32_t token, uint32_t nargs, > + target_ulong args, uint32_t nre= t, > + target_ulong rets) > +{ > + uint64_t wa_addr =3D ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(ar= gs, 0); You need to check nargs and nret first. > + uint64_t wa_offset; > + uint32_t drc_index; > + sPAPRDRConnector *drc; > + sPAPRDRConnectorClass *drck; > + sPAPRDRCCResponse resp; > + const struct fdt_property *prop =3D NULL; > + char *prop_name =3D NULL; > + int prop_len, rc; > + > + drc_index =3D rtas_ld(wa_addr, 0); > + drc =3D spapr_dr_connector_by_index(drc_index); > + if (!drc) { > + DPRINTF("rtas_ibm_configure_connector: invalid sensor/DRC index:= %xh\n", > + drc_index); > + rc =3D RTAS_OUT_PARAM_ERROR; > + goto out; > + } > + drck =3D SPAPR_DR_CONNECTOR_GET_CLASS(drc); > + resp =3D drck->configure_connector(drc, &prop_name, &prop, &prop_len= ); You may have answered this last time round, but if so I forgot the reason. Why does the awkward iteration need to go down to the drck callback? Coudln't the drck callback part just supply the fdt fragment blob, then have generic code which streams it out via iteration? Obviously we have to support the horrid PAPR interface, but it would be nice to confine the PAPR derived horridness to as small an area as we can. > + switch (resp) { > + case SPAPR_DR_CC_RESPONSE_NEXT_CHILD: > + /* provide the name of the next OF node */ > + wa_offset =3D CC_VAL_DATA_OFFSET; > + rtas_st(wa_addr, CC_IDX_NODE_NAME_OFFSET, wa_offset); > + rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset, > + (uint8_t *)prop_name, strlen(prop_name) + = 1); > + break; > + case SPAPR_DR_CC_RESPONSE_NEXT_PROPERTY: > + /* provide the name of the next OF property */ > + wa_offset =3D CC_VAL_DATA_OFFSET; > + rtas_st(wa_addr, CC_IDX_PROP_NAME_OFFSET, wa_offset); > + rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset, > + (uint8_t *)prop_name, strlen(prop_name) + = 1); > + > + /* provide the length and value of the OF property. data gets pl= aced > + * immediately after NULL terminator of the OF property's name s= tring > + */ > + wa_offset +=3D strlen(prop_name) + 1, > + rtas_st(wa_addr, CC_IDX_PROP_LEN, prop_len); > + rtas_st(wa_addr, CC_IDX_PROP_DATA_OFFSET, wa_offset); > + rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset, > + (uint8_t *)((struct fdt_property *)prop)->= data, > + prop_len); > + break; > + case SPAPR_DR_CC_RESPONSE_PREV_PARENT: > + case SPAPR_DR_CC_RESPONSE_ERROR: > + case SPAPR_DR_CC_RESPONSE_SUCCESS: > + break; > + default: > + /* drck->configure_connector() should not return anything else */ > + g_assert(false); > + } > + > + rc =3D resp; > +out: > + g_free(prop_name); > + rtas_st(rets, 0, rc); > +} > + > static struct rtas_call { > const char *name; > spapr_rtas_fn fn; > @@ -551,6 +630,8 @@ static void core_rtas_register_types(void) > rtas_set_indicator); > spapr_rtas_register(RTAS_GET_SENSOR_STATE, "get-sensor-state", > rtas_get_sensor_state); > + spapr_rtas_register(RTAS_IBM_CONFIGURE_CONNECTOR, "ibm,configure-con= nector", > + rtas_ibm_configure_connector); > } > =20 > type_init(core_rtas_register_types) --=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 --oN4OvwWIcd1E23D1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU7BzgAAoJEGw4ysog2bOSfuUP/3AnhHecGeWGsdhT+KVdVtto mhI5s9kt5FqEBMT6cn1W5XWCSIMy1irfTUvn8ElUrp62YIBlMIMHaFN5Hm4mzm5M ZXgiKWPAnbkbvVnbEltHRTR0cOzxm+MX7oy40gLct2KHWnvecavkX9oGNY46Ji3M UXmYesq2Sh0cCklOOYb3xdSyyAxILR/Oz0KGLen2q0cSCpqOOmrzSJn2f7U6jjiP Lx8YdrvwsLt26iUV5VdlbKTBvBOGE9gyZ+RitWkKV9hgxYAli+nMPL4KPAFkKD1J xbbjrKlzUVDFtCENtKO5iO/rqWwGGZePTaK8zpaP0wM70sNe65APE4A+LQSkJwLl u7/psC1shifaucXUdMN/JKa/+0gOXUQMc24uHT1OipaTN7nxsvRduo+Vx6Ax/bA8 Qx34pXvmJzeNfU7SyT4HMy+292QgyjhbkNlG1vM3wsKCOJv2GS+RhN5CCsLmr5F5 A91VXfquBRgAPCBWfQvccWiQSaMbxWfHm4dnk9la/J6h8Af3wkQ/otzMwbIyutIi AbnC5+/eTXCU/e4cbiA6Gmcm7d/6r0SD92LhjChwxijGXzrqKAL7XwBZlV0TqfPA wtwbT6qn2y3X2OMa/EkyOdr2hy7rS8LoHECQ4mxec5Q68tfm/FXUPy3jvAraCuso ffGrQCDnIBm64lBQzl/x =vj83 -----END PGP SIGNATURE----- --oN4OvwWIcd1E23D1--