From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK96a-0004d8-Bj for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:42:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK96V-0006eN-01 for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:42:20 -0400 Received: from mail-oa0-f45.google.com ([209.85.219.45]:55714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK96U-0006eJ-RG for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:42:14 -0400 Received: by mail-oa0-f45.google.com with SMTP id i18so1675809oag.4 for ; Fri, 05 Oct 2012 07:42:14 -0700 (PDT) From: Anthony Liguori In-Reply-To: <1347486505.2276.13.camel@pasglop> References: <5050B005.9080500@suse.de> <1347486505.2276.13.camel@pasglop> Date: Fri, 05 Oct 2012 09:42:10 -0500 Message-ID: <878vbl7zgd.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , Alexander Graf Cc: Erlon Cruz , qemu-devel@nongnu.org, David Gibson Benjamin Herrenschmidt writes: > On Wed, 2012-09-12 at 17:53 +0200, Alexander Graf wrote: >> On 09/12/2012 04:54 PM, Erlon Cruz wrote: >> > Hi all, >> > >> > We are planning to implement DLPAR capacity on QEMU pSeries. As we >> >> What is DLPAR? Hotplug support? > > Yes. > >> > lack of experience in the internals of the arch we would like you guys >> > to give us some design directions >> > and confirm if we going in the right direction. Our first idea is: >> > >> > 1 - to patch 'spapr.c' so it can dynamically insert/remove basic >> > items into the device tree. >> >> What exactly would you like to patch into it? We already do have support >> for dynamic dt creation with the spapr target. > > No we don't. We don't have the necessary bits and pieces to pass the DT > updates down to the guest. PAPR defines a mechanism using RTAS calls > which we need to implement, but there are some issues remaining: > > - We don't have a way to "initiate" a DLPAR operation. This is > currently done by proprietary tools that communicate with the HMC. We > want to invent some kind of hotplug "interrupt" (using existing RTAS > event facilities). All it needs to do is indicate the DT path (ie. > connector) where something is to be plugged to or unplugged, which can > then trigger the relevant configure-connector calls to retrieve the DT > bits. > > - We have a problem with PCI. Currently, the content of the PCI > bus(ses) is discovered by SLOF running inside the guest. Not by qemu. > It's SLOF that assigns the BARs and create the device-tree nodes for the > various PCI devices. However, with hotplug, the guest expects to get > fully populated DT nodes for hotplugged PCI devices and fully assigned > BARS. Under pHyp that works because under the hood, RTAS contains an OFW > implementation which does all the assignment before passing the stuff to > the OS, but under qemu, RTAS is actually in qemu. This means we'll > probably have to move back the PCI device node creation and resource > assignment to qemu (like it was in the very early versions of the spapr > support). I know you and I have discussed this in the past, but not on the list and now I don't recall the reasoning. Why not add a proper RTAS and do this work there? Regards, Anthony Liguori