Re: [Qemu-ppc] [PATCH v5 04/36] ppc/xive: introduce the XiveRouter model

[Cédric Le Goater]

On 11/27/18 2:54 AM, David Gibson wrote:
> On Fri, Nov 23, 2018 at 09:06:07AM +0100, Cédric Le Goater wrote:
>> On 11/23/18 4:50 AM, David Gibson wrote:
>>> On Thu, Nov 22, 2018 at 08:53:00AM +0100, Cédric Le Goater wrote:
>>>> On 11/22/18 5:11 AM, David Gibson wrote:
>>>>> On Fri, Nov 16, 2018 at 11:56:57AM +0100, Cédric Le Goater
>> wrote:
> [snip]
>>>>> So as far as I can see so far, the XiveFabric interface will
>>>>> essentially have to be implemented on the router object, so I'm not
>>>>> seeing much point to having the interface rather than just a direct
>>>>> call on the router object.  But I haven't read the whole series yet,
>>>>> so maybe I'm missing something.
>>>>
>>>> The PSIHB and PHB4 models are using it but there are not in the series.
>>>>
>>>> I can send the PSIHB patch in the next version if you like, it's the 
>>>> patch right after PnvXive. It's attached below for the moment. Look at 
>>>> pnv_psi_notify().
>>>
>>> Hrm, I see.  This seems like a really convoluted way of achieving what
>>> you need here.  We want to abstract exactly how the source delivers
>>> notifies, 
>>
>> on sPAPR, I agree that the forwarding of event notification could be a 
>> simple XiveRouter call but the XiveRouter covers both machines :/
>>
>> On PowerNV, HW uses MMIOs to forward events and only the device knows 
>> about the IRQ number offset in the global IRQ number space and the 
>> notification port to use for the MMIO store. A PowerNV XIVE source 
>> would forward the event notification to a piece of logic which sends 
>> a PowerBUS event notification message. How it reaches the XIVE IC is
>> beyong QEMU as it would means modeling the PowerBUS. 
>>
>>> but doing it with an interface on some object that's not necessarily
>>> either the source or the router seems odd.  
>> There is no direct link between the device owing the source and the 
>> XIVE controller, they could be on the same Power chip but the routing 
>> could be done by some other chips. This scenario is covered btw.
>>
>> See it as a connector object.
>>
>>> At the very least the names need to change (of both interface and > 
>>> property for the target object).
>>
>> I am fine with renaming it. With the above explanations, if they are 
>> clear enough, how do see them ?
> 
> TBH, I didn't find the info above particularly illuminating.

This is really a PowerNV need. So, I can reshuffle the code and make 
a direct link between the XiveSource and the XiveRouter models for sPAPR.
It's a small change. and reintroduce XiveFabric (or whatever name we choose) 
later before the PowerNV Xive and PSIHB model. 

>  However,
> I think perusing the code has finally gotten my head around the model
> (sorry it's taken so long).  I think two things were confusing me.
> 
> 1) The name had be thinking in terms of the XicsFabric, but the
> function here is totally different.

Yes. I agree. It's not the same thing at all.

> 2) I was thinking of the XiveSource as handling all source-side irq
> related logic, but I guess it's real function is a bit more limited.
> As I now understand it, it's only really handling the ESB and
> immediately surrounding logic - the "owning" device (e.g. PHB or PSI)
> is responsible for the connection "up the stack" as it were.

yes.

> So, I'm ok with the model.  Just to verify that my understanding is
> correct, can you confirm my reasoning below:
> 
>   * For PowerNV, we'd generally expect the notify function to be
>     implemented by the "owning" device.  For the XIVE internal source,
>     that would be the XiveRouter itself, immediately triggering the
>     right EAS.  For the PHB and PSI irq sources, that will code in the
>     PHB/PSI which performs the MMIO to poke a router.

exactly.
 
>   * For PAPR, for simplicity, we'd expect to wire all sources direct
>     to a single system-wide router object.

yes. 

> 
> I definitely think it needs a name change though.  "XiveNotify"
> perhaps?  

Yes. XiveNotifier may be ? to use a noun and not a verb.

> And the property to configure it on the XiveSource, maybe "notify" 
> or "notify_via".

What the XIVE engines are doing is forwarding a trigger event to the 
next engine that can possibly do the routing to the final target. 
  
In the specs, the verbs 'trigger', 'forward', 'notify', 'route' are 
commonly used. I think 'notify' is the most frequent.

ok for 'notify'.

Thanks,

C.