[Top][All Lists]

[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: Mon, 4 Dec 2017 09:32:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 12/04/2017 02:59 AM, David Gibson wrote:
> On Fri, Dec 01, 2017 at 09:10:24AM +0100, Cédric Le Goater wrote:
>> 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;
>>     }
> Ah, sorry, missed that.  Once we have negotiation we'll need to make
> sure the xive_exploitation bit is sent first, of course, but I'm
> pretty sure the machine state is already sent first.
>>> 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.
> Hrm.  I'm less sure about that - I'm not sure the lifetimes line up.
> But I'd like to avoid creating them on earlier machine types, even if
> xive_exploitation can't do the trick.

Yes. I agree. I think we can work something out without introducing
too much complexity. The XIVE object is directly used by the
machine only to set/unset IRQ numbers. Otherwise, it is always 
conditioned by :

    spapr_ovec_test(spapr->ov5_cas, OV5_XIVE_EXPLOIT)

I think adding a couple of more tests on the 'xive_exploitation'
bool should work out for older machines.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]