Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries

[David Gibson <david@gibson.dropbear.id.au>]

On Sat, Oct 06, 2012 at 06:49:13AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2012-10-05 at 09:42 -0500, Anthony Liguori wrote:
> > >  - 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?
> 
> Because it's a PITA ? We could ... but that means we'd have to write
> some kind of FW blob that is relocatable and capable of "live"
> relocating itself (the versions that would run within SLOF need to
> transfer control to one at a different address that runs within the OS
> context since the OS decides where RTAS lives).
> 
> It would have to know the device-tree to handle DLPAR (thus get "synced"
> by OF on any DT change until OF is killed by the OF).
> 
> Generally writing yet another blob means yet another piece of SW to
> write from scratch, maintain, package, deal with dependencies, debug,
> etc...
> 
> It is an option though, just not a nice one. And a fairly time consuming
> one too.

I also don't see how it helps in this situation.  The hotplug will
still be initiated by qemu, so we'd have to work out how qemu
communicates the info to RTAS, and how RTAS communicates it to the
kernel, doubling the work.

-- 
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