Message-ID: <MN2PR12MB43586084670E14691920952889229@MN2PR12MB4358.namprd12.prod.outlook.com>
Date:   Wed, 12 Oct 2022 10:34:23 +0000
From:   "Radovanovic, Aleksandar" <aleksandar.radovanovic@....com>
To:     "Gupta, Nipun" <Nipun.Gupta@....com>,
        Marc Zyngier <maz@...nel.org>,
        Robin Murphy <robin.murphy@....com>
CC:     "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>,
        "jgg@...pe.ca" <jgg@...pe.ca>, "jgg@...dia.com" <jgg@...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: Gupta, Nipun <Nipun.Gupta@....com>
> Sent: 12 October 2022 11:04
> To: Marc Zyngier <maz@...nel.org>; Robin Murphy
> <robin.murphy@....com>
> Cc: 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;
> jgg@...pe.ca; jgg@...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>;
> Radovanovic, Aleksandar <aleksandar.radovanovic@....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]
> 
> 
> <snip>
> 
> >
> > > +}
> > > +
> > > +static void cdx_msi_write_msg(struct irq_data *irq_data,
> > > +                           struct msi_msg *msg) {
> > > +     /*
> > > +      * Do nothing as CDX devices have these pre-populated
> > > +      * in the hardware itself.
> > > +      */
> >
> > We talked about this in a separate thread. This is a major problem.
> 
> We discussed this further with the hardware design team and now have the
> correct and complete understanding here. As the CDX devices are FPGA
> based, they don't exist yet, so it would be possible to construct them in such
> a way that the eventid is programable.
> 
> To make it generic for CDX devices, we have added a firmware API which
> provide the mappings (MSI vector ID to eventID) to the fabric, that can be
> referred by the device while generating the MSI interrupt.
> 
> Also, there is an existing table to have GITS_TRANSLATOR iova address
> (address in
> msi_msg) for CDX devices, which can be programmed by the firmware. So,
> providing IOVA address to device would also not be a problem here.
> 
> We would be rolling out RFC v4 with these changes soon.
> 
> Regards,
> Nipun

Just to be clear, there will be some HW limitations with the proposed solution,
so let's just make sure that we're all OK with it.

For the MSI EventID, the HW interrupt logic assumes the MSI write value is 
equal to the MSI vector number. However, the vector number is programmable
for most (all) of the interrupt sources, which isn't exactly the same as saying
EventID is programmable for a vector number, but can be used to emulate the
desired behaviour, with a translation table in firmware. 

The limitation here is that we support at most 16 bits of EventID (and this still
needs to be confirmed for all interrupt sources)

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.

Thanks,
Aleksandar

Powered by blists - more mailing lists