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.
