Message-ID: <MN2PR12MB4358CF6B6D2576B35E39328A89249@MN2PR12MB4358.namprd12.prod.outlook.com>
Date:   Fri, 14 Oct 2022 11:18:36 +0000
From:   "Radovanovic, Aleksandar" <aleksandar.radovanovic@....com>
To:     Jason Gunthorpe <jgg@...pe.ca>
CC:     "Gupta, Nipun" <Nipun.Gupta@....com>,
        Marc Zyngier <maz@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "cohuck@...hat.com" <cohuck@...hat.com>,
        "Gupta, Puneet (DCG-ENG)" <puneet.gupta@....com>,
        "song.bao.hua@...ilicon.com" <song.bao.hua@...ilicon.com>,
        "mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "jeffrey.l.hugo@...il.com" <jeffrey.l.hugo@...il.com>,
        "saravanak@...gle.com" <saravanak@...gle.com>,
        "Michael.Srba@...nam.cz" <Michael.Srba@...nam.cz>,
        "mani@...nel.org" <mani@...nel.org>,
        "yishaih@...dia.com" <yishaih@...dia.com>,
        "will@...nel.org" <will@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "okaya@...nel.org" <okaya@...nel.org>,
        "Anand, Harpreet" <harpreet.anand@....com>,
        "Agarwal, Nikhil" <nikhil.agarwal@....com>,
        "Simek, Michal" <michal.simek@....com>,
        "git (AMD-Xilinx)" <git@....com>
Subject: RE: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its
 domain as parent

[AMD Official Use Only - General]



> -----Original Message-----
> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: 13 October 2022 13:43
> To: Radovanovic, Aleksandar <aleksandar.radovanovic@....com>
> Cc: Gupta, Nipun <Nipun.Gupta@....com>; Marc Zyngier
> <maz@...nel.org>; Robin Murphy <robin.murphy@....com>;
> robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org;
> gregkh@...uxfoundation.org; rafael@...nel.org; eric.auger@...hat.com;
> alex.williamson@...hat.com; cohuck@...hat.com; Gupta, Puneet (DCG-
> ENG) <puneet.gupta@....com>; song.bao.hua@...ilicon.com;
> mchehab+huawei@...nel.org; f.fainelli@...il.com;
> jeffrey.l.hugo@...il.com; saravanak@...gle.com;
> Michael.Srba@...nam.cz; mani@...nel.org; yishaih@...dia.com;
> will@...nel.org; joro@...tes.org; masahiroy@...nel.org;
> ndesaulniers@...gle.com; linux-arm-kernel@...ts.infradead.org; linux-
> kbuild@...r.kernel.org; linux-kernel@...r.kernel.org;
> devicetree@...r.kernel.org; kvm@...r.kernel.org; okaya@...nel.org;
> Anand, Harpreet <harpreet.anand@....com>; Agarwal, Nikhil
> <nikhil.agarwal@....com>; Simek, Michal <michal.simek@....com>; git
> (AMD-Xilinx) <git@....com>
> Subject: Re: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its
> domain as parent
> 
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> 
> 
> On Wed, Oct 12, 2022 at 03:09:26PM +0000, Radovanovic, Aleksandar wrote:
> 
> > > On Wed, Oct 12, 2022 at 01:37:54PM +0000, Radovanovic, Aleksandar
> wrote:
> > > > > On Wed, Oct 12, 2022 at 10:34:23AM +0000, Radovanovic,
> > > > > Aleksandar
> > > wrote:
> > > > >
> > > > >
> > > > > > As for GITS_TRANSLATER, we can take up to 4 different IOVAs,
> > > > > > which limits us to 4 CDX devices (should be sufficient for
> > > > > > current HW use-cases). Also, it means that the address part
> > > > > > must be the same for all vectors within a single CDX device.
> > > > > > I'm assuming this is OK as it is going to be a single interrupt and
> IOMMU domain anyway.
> > > > >
> > > > > This is not at all how MSI is supposed to work.
> > > >
> > > > In the general case, no, they're not.
> > >
> > > I don't mean that you can hack this to work - I mean that in MSI the
> > > addr/data is supposed to come from the end point itself, not from
> > > some kind of shared structure. This is important because the actual
> > > act of generating the write has to be coherent with the DMA the
> > > device is doing, as the MSI write must push any DMA data to
> > > visibility to meet the "producer / consumer" model.
> > >
> >
> > I'm not sure I follow your argument, the limitation here is that the
> > MSI address value is shared between vectors of the same device
> > (requester id or endpoint, whichever way you prefer to call it), not
> > between devices.
> 
> That isn't what you said, you said "we can take up to 4 different IOVAs, which
> limits us to 4 CDX devices" - which sounds like HW being shared across
> devices??

And that still does not imply lack of ordering or sharing of MSI target addresses between devices.

This is a highly programmable IP block, at the core of which is an interconnect interfacing to programmable logic (PL), a number of PCIe controllers (either endpoint or root-port), DMA engines, offload engines, the embedded processor subsystem (PSX), etc. DMA and interrupts can be routed across it in almost any (meaningful) direction. The datapath 'endpoints' request DMA and interrupts, but don't concern themselves with the mechanics of delivering that in the target domain. It is the responsibility of the egress bridges to the target domains to convert the interconnect interrupt transactions to whatever the interrupt delivery mechanism for that domain is. E.g. for PCIe controllers in endpoint mode, that would be through PCIe MSI-X tables internal to the controller (and managed by the PCIe host), for PSX that would be the PSX bridge (partially managed by the PSX OS, mediated through firmware, i.e. through CDX bus driver) and so on. It is the responsibility of the interconnect to maintain transaction ordering (including DMA vs. interrupts). It is the responsibility of the firmware to manage the bridges according to the implemented use-case, so everything works as expected. 

The CDX bus driver manages a single aspect of this and that is endpoints implemented in PL/engines, targeting the PSX.

So, yes, the hardware that translates interrupt transactions to GIC AXI writes is shared between endpoints, but what I said above still applies. And that doesn't necessarily make it weird/wrong, it's just more complex than you might think.

Anyway, I think we're straying off topic here, none of this is visible to the kernel anyway. The question that we still need to answer is, are you OK with the limitations I listed originally?

Thanks,
Aleksandar

Powered by blists - more mailing lists