Re: [Qemu-devel] [PATCH v2 01/14] spapr: populate DRC entries for root dt node

[Michael Roth <mdroth@linux.vnet.ibm.com>]

Quoting Mike Day (2014-01-20 11:59:28)
> On Mon, Jan 20, 2014 at 12:24 PM, Michael Roth
> <mdroth@linux.vnet.ibm.com> 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 after
> > discussing it a bit Tyrel/Mike, I think the main considerations would be:
> >
> > 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 callback
> >    for spapr-pci-host-bridge devices
> > 2) The required properties for the OF node corresponding PHB will be different.
> >    Currently these are generated as part of the hotplug callback, and attached
> >    to the corresponding ConfigureConnectorState node to be fed to the guest
> >    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 different,
> >    we'd be relying on the rpadlar kernel module
> >    (/sys/bus/pci/slots/control/add_slot) rather than rpaphp
> >    (/sys/bus/pci/slots/<slot>/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 within qemu
> > guests, so there may be various odds/ends and possibly kernel changes needed 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 via
rpaphp or rescan either way.

As far alternatives to PHB hotplug, there's options like introducing a compatible
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 separate
issue (unless the only goal we care about here is increasing the pci device limit
while the guest is running (maybe it is?))

> 
> Mike