Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

[Cédric Le Goater]

On 04/12/2018 07:10 AM, David Gibson wrote:
> On Wed, Jan 17, 2018 at 10:18:43AM +0100, Cédric Le Goater wrote:
>>>>> Also, have we decided how the process of switching between XICS and
>>>>> XIVE will work vs. CAS ? 
>>>>
>>>> That's how it is described in the architecture. The current choice is
>>>> to create both XICS and XIVE objects and choose at CAS which one to
>>>> use. It relies today on the capability of the pseries machine to 
>>>> allocate IRQ numbers for both interrupt controller backends. These
>>>> patches have been merged in QEMU.
>>>>
>>>> A change of interrupt mode results in a reset. The device tree is 
>>>> populated accordingly and the ICPs are switched for the model in 
>>>> use. 
>>>
>>> For KVM we need to only instanciate one of them though.
>>
>> Hmm,
>>
>> How would we handle a guest rebooting on a kernel without XIVE support ? 
>> Are you suggesting to create the XICS or XIVE device in the CAS negotiation 
>> process ? So, the machine would not have any interrupt controller before 
>> CAS. That seems really late to me. grub uses the console for instance. 
>>
>> I think it should prepare for both options, start in XIVE legacy mode, 
>> which is XICS, then possibly switch to XIVE exploitation mode.
> 
> I think for our first draft we should have XIVE and XICS based
> platforms as separate machine types (or a machine option, I guess).

OK. This is my current choice for KVM. 

Emulated mode is rather simple to handle, and this is why I have  
kept the reset after CAS if there is a change in the interrupt mode. 
 
> We do want to allow this to be autonegotiated, but I feel like
> emphasising that at the beginning is causing unnatural design
> decisions in the XIVE model itself.

Yes. This is mostly a KVM problem which also has impacts on XICS 
of course ...

C.  
 
>>
>>>>> And how that will interact with KVM ?
>>>>
>>>> I expect we will do the same, which is to create two KVM devices to 
>>>> be able to handle both interrupt controller backends depending on the 
>>>> mode negotiated by the guest.  
>>>
>>> That will be an ungodly mess, I'd rather we only instanciate the right
>>> one.
>>
>> It's rather transparent currently in the emulated version. There are two 
>> sets of objects in QEMU, switching is done in CAS. KVM support should not 
>> change anything in that area. 
>>
>> I expect the 'xive-kvm' object to get/set states for migration, just like 
>> for XICS and to setup the ESB+TIMA memory regions, which is new. 
>>
>> C. 
>>  
>>>>> I was
>>>>> thinking the kernel would implement a different KVM device type, ie
>>>>> the "emulated XICS" would remain KVM_DEV_TYPE_XICS and XIVE would be
>>>>> KVM_DEV_TYPE_XIVE.
>>>>
>>>> yes. it makes sense. The new device will have a lot in common with the 
>>>> KVM_DEV_TYPE_XICS using kvm_xive_ops.
>>>
>>> Ben.
>>>
>>
>