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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

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

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.

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.

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

I definitely think it needs a name change though.  "XiveNotify"
perhaps?  And the property to configure it on the XiveSource, maybe
"notify" or "notify_via".

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]