From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3W53-0002O3-94 for qemu-devel@nongnu.org; Tue, 23 Dec 2014 15:29:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3W4u-0003zJ-Kr for qemu-devel@nongnu.org; Tue, 23 Dec 2014 15:29:21 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:37752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3W4u-0003yu-DF for qemu-devel@nongnu.org; Tue, 23 Dec 2014 15:29:12 -0500 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 23 Dec 2014 13:29:10 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: References: <1408407718-10835-1-git-send-email-mdroth@linux.vnet.ibm.com> <1408407718-10835-5-git-send-email-mdroth@linux.vnet.ibm.com> <53FC7159.6040406@suse.de> <20140930220813.19243.5956@loki> <542C1001.8050802@suse.de> <20141126062758.1187.29139@loki> Message-ID: <20141223151239.15420.96705@loki> Date: Tue, 23 Dec 2014 09:12:39 -0600 Subject: Re: [Qemu-devel] [PATCH 04/12] spapr_pci: add set-indicator RTAS interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: aik@ozlabs.ru, Alexander Graf , "qemu-devel@nongnu.org" , ncmike@ncultra.org, "qemu-ppc@nongnu.org" , tyreld@linux.vnet.ibm.com, Nathan Fontenot Quoting Bharata B Rao (2014-11-30 22:57:48) > On Wed, Nov 26, 2014 at 11:57 AM, Michael Roth > wrote: > > https://github.com/mdroth/qemu/commits/spapr-pci-hotplug-ppc-next-clean= up4.2 > > > > The sPAPRDREntry stuff is now modeled by the sPAPRDRConnector QOM objec= t in > > hw/ppc/spapr_drc.c, which manages the device's life-cycle based on > > rtas-set-sensor-state calls from the guest. As part of qemu-side hotplu= g/unplug > > you use the attach/detach methods of the DRC to associate DT bits and c= allbacks > > for things like device cleanup or rtas calls to fetch a DT node from th= e device > > associated with a particular DRC. > > > > I still need to fix endian issues, and am realizing the dr connectors a= nd DT > > bits for PHBs are not actually a prereq for PCI hotplug, so I may be pu= lling > > that out to a separate series specific to enabling PHB hotplug (namely = for > > VFIO hotplug). I realize your CPU/MEM sort of depend on the top-level P= HB > > device tree code so I'm not sure how best to deal with that. Worse case= we'd > > roll the initial code into your series and base a follow-up series on t= hat of > > that instead. > = > Thanks Michael for pointing me to your git tree. > = > I started rebasing my patchset on top of yours and realized that the > generic DT setup code from the below commits of your branch are needed > for CPU and memory hotplug too. They all apply in the order I have > listed below. > = > 71b32999c4eb spapr_drc: initial implementation > 255c50200848 spapr: populate DRC entries for root dt node (don't need > code that adds PHB DT entries) > 408206fc627e3 spapr_rtas: add set-indicator RTAS interface > da7a232fa6a44 spapr_rtas: add get-sensor-state RTAS interface > 1c575d5b29688 spapr_rtas: add ibm,configure-connector RTAS interface > 0c5d72833666c spapr_events: re-use EPOW event infrastructure for hotplug = events > 82ee5a9c88155 spapr_events: event-scan RTAS interface > = > If you can make the above set an independent patchset, it will become > easy to maintain and post CPU and memory hotplug patchsets. Hi Bharata, I've submitted v4 of PCI hotplug. The development branch is here: https://github.com/mdroth/qemu/commits/spapr-hotplug-pci and is based on top of a 'core' branch organized similar to what you propos= ed: https://github.com/mdroth/qemu/commits/spapr-hotplug-core I'll be rolling changes for core/pci code into the branches as we go. The endian fixes you provided are included, and PCI hotplug has been tested on ppc64le. There's a pseries-2.3 in the core patchset to enable/disable dynamic-reconfiguration for individual resources on a machine basis to maintain backward migration compatibility. There's a PHB hotplug patchset based on core that might be a good reference for re-basing CPU/memory: https://github.com/mdroth/qemu/commits/spapr-hotplug-phb > = > I am facing some endian issues in your patchset and I will send fixes > for those separately. > = > Regards, > Bharata.