Re: [Qemu-devel] [Qemu-ppc] [PATCH 5/5] pseries: Move XICS initialization before cpu initialization

[Alexander Graf <agraf@suse.de>]

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