[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 17/25] spapr: add a sPAPRXive object to the machin
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [PATCH 17/25] spapr: add a sPAPRXive object to the machine |
Date: |
Fri, 1 Dec 2017 09:10:24 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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.
>