On Mon, Mar 18, 2013 at 04:12:11AM +0100, Alexander Graf wrote: > > On 18.03.2013, at 03:55, David Gibson wrote: > > > On Fri, Mar 15, 2013 at 01:33:18PM +0100, Alexander Graf wrote: > >> > >> On 14.03.2013, at 02:53, David Gibson wrote: > >> > >>> Currently, the pseries machine initializes the cpus, then the XICS > >>> interrupt controller. However, to support the upcoming in-kernel XICS > >>> implementation we will need to initialize the irq controller before the > >>> vcpus. This patch makes the necesssary rearrangement. This means the > >> > >> We're changing that notion in the in-kernel XICS discussions. The flow > >> will look like this: > >> > >> * create vcpus > >> * create XICS > >> * foreach (vcpu) > >> * enable_cap(vcpu, CAP_XICS_SERVER, xics_handle) > >> > >> However, that means we still need to know the maximum number of > >> supported vcpus during the create phase. That number can be bigger > >> than smp_cpus though, since you probably want to support hotplug add > >> of CPUs later on. > >> > >> Can't we just make the number of supported "interrupt servers" a > >> constant? > > > > I suppose, but we need an allocation for each one, so its a bit ugly. > > In any case although the comment is a bit out of date, this patch also > > creates a logical place to put per-cpu XICS initialization which we > > will still need for the new interface. > > So how would you model CPU hotplug add?
Add headroom to the XICS setup based on whatever information we have
about maximum pluggable CPUs. To use the PAPR hotplug interfaces we
already need a notion of max # CPUs, we can't have that just be open
ended. We'd also add a call to xics_cpu_setup() to the hotplug add
path, obviously.
--
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
signature.asc
Description: Digital signature
