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

[Cédric Le Goater]

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. 

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.   

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.
>>
>