On 18.03.2013, at 04:38, David Gibson wrote: > 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.
Yeah. So for that you also need the different code order. Sorry for the confusion :). Thanks, applied to ppc-next. Alex
