Re: [Qemu-ppc] [PATCH 17/25] spapr: add a sPAPRXive object to the machine

[Cédric Le Goater]

On 12/01/2017 05:14 AM, David Gibson wrote:
> On Thu, Nov 30, 2017 at 03:15:09PM +0000, Cédric Le Goater wrote:
>> On 11/30/2017 05:55 AM, David Gibson wrote:
>>> On Thu, Nov 23, 2017 at 02:29:47PM +0100, Cédric Le Goater wrote:
>>>> The XIVE object is designed to be always available, so it is created
>>>> unconditionally on newer machines.
>>>
>>> There doesn't actually seem to be anything dependent on machine
>>> version here.
>>
>> No. I thought that was too early in the patchset. This is handled 
>> in the last patch with a 'xive_exploitation' bool which is set to 
>> false on older machines. 
>>
>> But, nevertheless, the XIVE objects are always created even if not
>> used. Something to discuss.
> 
> That'll definitely break backwards migration, since the destination
> won't understand the (unused but still present) xive state it
> receives. 

no because it's not sent. the vmstate 'needed' op of the sPAPRXive
object discards it :

    static bool vmstate_spapr_xive_needed(void *opaque)
    {
        sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
 
        return spapr->xive_exploitation;
    }

> So xives can only be created on new machine types. 

That would be better I agree. I can probably use the 'xive_exploitation'
bool to condition its creation.

> I'm ok
> (at least tentatively) with always creating them on the newer machine
> types, regardless of whether the guest ends up exploiting it or not.

OK.


>>>> Depending on the configuration and
>>>> the guest capabilities, the CAS negotiation process will decide which
>>>> interrupt model to use, legacy or XIVE.
>>>>
>>>> The XIVE model makes use of the full range of the IRQ number space
>>>> because the IRQ numbers for the CPU IPIs are allocated in the range
>>>> below XICS_IRQ_BASE, which is unused by XICS.
>>>
>>> Ok.  And I take it 4096 is enough space for the XIVE IPIs for the
>>> forseeable future?
>>
>> The biggest real system I am aware of as 16 sockets, 192 cores, SMT8. 
>> That's 1536 cpus. pseries has a max_cpus of 1024.
> 
> Ok, so we can go to double the current system size, but not 4x.  Not
> sure if that seems adequate or not.  Still it's a relatively minor
> detail.
>