From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Jwo-0000CK-Cw for qemu-devel@nongnu.org; Mon, 20 Jan 2014 13:51:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Jwa-0000ad-8r for qemu-devel@nongnu.org; Mon, 20 Jan 2014 13:51:46 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:37762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Jwa-0000aK-4n for qemu-devel@nongnu.org; Mon, 20 Jan 2014 13:51:32 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Jan 2014 13:51:30 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: References: <1386282785-466-1-git-send-email-mdroth@linux.vnet.ibm.com> <1386282785-466-2-git-send-email-mdroth@linux.vnet.ibm.com> <52AE6C7E.7080300@ozlabs.ru> <52AE8792.4060205@ozlabs.ru> <20140116205102.32002.50059@loki> <52DC90CC.4030301@ozlabs.ru> <20140120172428.22088.20255@loki> Message-ID: <20140120185127.22088.57265@loki> Date: Mon, 20 Jan 2014 12:51:27 -0600 Subject: Re: [Qemu-devel] [PATCH v2 01/14] spapr: populate DRC entries for root dt node List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Day Cc: Alexey Kardashevskiy , "qemu-devel@nongnu.org" , Alexander Graf , Paul Mackerras , tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, "qemu-ppc@nongnu.org" Quoting Mike Day (2014-01-20 11:59:28) > On Mon, Jan 20, 2014 at 12:24 PM, Michael Roth > wrote: > > Quoting Alexey Kardashevskiy (2014-01-19 20:58:20) > > > > Would need to look at it a bit more closely to say for certain, but aft= er > > discussing it a bit Tyrel/Mike, I think the main considerations would b= e: > > > > 1) PHB hotplug/unplug would need to signal a different event type in it= 's > > check-exception/epow message, we have stubs in place for a PHB event= type, > > so that's mostly a matter of adding special-casing in the hotplug ca= llback > > for spapr-pci-host-bridge devices > > 2) The required properties for the OF node corresponding PHB will be di= fferent. > > Currently these are generated as part of the hotplug callback, and a= ttached > > to the corresponding ConfigureConnectorState node to be fed to the g= uest > > via subsequent ibm,configure-connector RTAS calls, so we'd just hook= the > > PHB's OF node generation code in there as. > > 3) The sysctl/kernel interface for handling PHB hotplug would be differ= ent, > > we'd be relying on the rpadlar kernel module > > (/sys/bus/pci/slots/control/add_slot) rather than rpaphp > > (/sys/bus/pci/slots//power) or the PCI rescan fallback. > > This is mostly a matter of modifying the handling in the guest tools= , namely > > in rtas_errd, to handle the event accordingly. > > > > We also haven't done anything extensive using rpadlpar operations withi= n qemu > > guests, so there may be various odds/ends and possibly kernel changes n= eeded to > > get that working properly (as was the case for rpaphp, though thanks to= the PCI > > rescan workaround a new kernel isn't required for existing guests... a = similar > > fallback likely won't be available for rpadlpar) > > > > But from a high-level view at least it seems fairly straight-forward. I= 'll see > > if we can get a prototype working. > = > The fact that it "just works" now by rescanning the pci filesystem is > a significant benefit. I don't think we want to lose it. There can be > many PHBs on one of these systems. Maybe we could make the PHB > hot-pluggable and also always have one PHB plugged in at startup. Then > the guest will see the bus when it starts and it will build the pci > file system. I'm not sure I understand the proposal, but to be clear this doesn't entail= a change to the existing behavior, just one of the constraints specific to supporting PHB hotplug in the future, PCI devices can still be hotplugged v= ia rpaphp or rescan either way. As far alternatives to PHB hotplug, there's options like introducing a comp= atible pci-bridge device (or perhaps the standard pci-bridge code will work) that = can be hotplugged using rpaphp/rescan to add child busses, but I think that's a se= parate issue (unless the only goal we care about here is increasing the pci device= limit while the guest is running (maybe it is?)) > = > Mike