[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v2 01/14] spapr: populate DRC entries for root dt
From: |
Mike Day |
Subject: |
Re: [Qemu-ppc] [PATCH v2 01/14] spapr: populate DRC entries for root dt node |
Date: |
Mon, 20 Jan 2014 12:59:28 -0500 |
On Mon, Jan 20, 2014 at 12:24 PM, Michael Roth
<address@hidden> 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.
Mike