Re: [Qemu-ppc] [RFC PATCH v2 00/21] Guest exploitation of the XIVE interrupt controller (POWER9)

[Cédric Le Goater]

On 09/22/2017 12:33 PM, David Gibson wrote:
> On Thu, Sep 21, 2017 at 04:18:33PM +0200, Cédric Le Goater wrote:
>> On 09/21/2017 03:25 AM, David Gibson wrote:
>>> On Wed, Sep 20, 2017 at 02:33:37PM +0200, Cédric Le Goater wrote:
>>>> On 09/19/2017 10:46 AM, David Gibson wrote:
>>>>> On Tue, Sep 19, 2017 at 06:20:20PM +1000, David Gibson wrote:
>>>>>> On Mon, Sep 11, 2017 at 07:12:14PM +0200, Cédric Le Goater wrote:
>>>>>>> On a POWER9 sPAPR machine, the Client Architecture Support (CAS)
>>>>>>> negotiation process determines whether the guest operates with an
>>>>>>> interrupt controller using the XICS legacy model, as found on POWER8,
>>>>>>> or in XIVE exploitation mode, the newer POWER9 interrupt model. This
>>>>>>> patchset is a proposal to add XIVE support in POWER9 sPAPR machine.
>>>>>>>
>>>>>>> Follows a model for the XIVE interrupt controller and support for the
>>>>>>> Hypervisor's calls which are used to configure the interrupt sources
>>>>>>> and the event/notification queues of the guest. The last patch
>>>>>>> integrates XIVE in the sPAPR machine.
>>>>>>>
>>>>>>> Code is here:
>>>>>>
>>>>>>
>>>>>> An overall comment:
>>>>>>
>>>>>> I note in several replies here that I think the way XICS objects are
>>>>>> re-used for XIVE is really ugly, and I think it will make future
>>>>>> maintenance pretty painful.
>>>>
>>>> I agree. That was one way to identify what we need for migration 
>>>> compatibility and CAS reset.   
>>>>
>>>>>> I'm thinking maybe trying to support the CAS negotiation of interrupt
>>>>>> controller from day 1 is warping the design.  A better approach might
>>>>>> be first to implement XIVE only when given a specific machine option -
>>>>>> guest gets one or the other and can't negotiate.
>>>>
>>>> ok. 
>>>>
>>>> CAS is not the most complex problem, we mostly need to share 
>>>> the ICSIRQState array and the source offset. migration from older
>>>> machine is a problem.
>>>
>>> Uh.. what?  Migration from an older machine isn't a thing.  We can
>>> migrate from an older qemu, but the machine type (and version) has to
>>> be identical at each end.  That's *why* we keep around the older
>>> machine types on newer qemus.
>>
>> yes. I am just wondering how I am going to handle a xics-only 
>> machine migrating to a xics/xive machine. 
> 
> Won't ever happen.  Older machine types will always be xics, newer
> machine type will always be xive (at least with POWER9).
> 
>> The xive machine option we are talking about will activate 
>> the xive interrupt mode and instantiate the objects behind it. 
>> So when we migrate from an older machine we will need to start 
>> the target machine with xive=off. I guess that is OK.
> 
> Again, we *don't* migrate from an older machine.  Ever.  We only ever
> migrate from an older qemu version to a newer qemu using the older
> machine type.

Sorry I was talking about QEMU version, and not machine version.
I still have to look at how both machines will cohabitate in the 
newer QEMU. 

Thanks,

C. 


>>
>> Thanks for the insights and the time to review the code,
>>
>> C. 
>>
>>>> We are doomed to keep the existing XICS
>>>> framework available.
>>>>
>>>>>> That should allow a more natural XIVE design to emerge, *then* we can
>>>>>> look at what's necessary to make boot-time negotiation possible.
>>>>>
>>>>> Actually, it just occurred to me that we might be making life hard for
>>>>> ourselves by trying to actually switch between full XICS and XIVE
>>>>> models.  Coudln't we have new machine types always construct the XIVE
>>>>> infrastructure, 
>>>>
>>>> yes.
>>>>
>>>>> but then implement the XICS RTAS and hcalls in terms of the XIVE virtual 
>>>>> hardware.
>>>>
>>>> ok but migration will not be supported.
>>>
>>> Right, this would only be for newer machine types, and you can never
>>> migrate between different machine types.
>>>
>>>>> Since something more or less equivalent
>>>>> has already been done in both OPAL and the host kernel, I'm guessing
>>>>> this shouldn't be too hard at this point.
>>>>
>>>> Indeed that is how it is working currently on P9 kvm guests. hcalls are
>>>> implemented on top of XIVE native.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> C.
>>>>
>>>
>>
>