Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Jason Gunthorpe <jgg@mellanox.com>
To:     "Raj, Ashok" <ashok.raj@intel.com>
CC:     Megha Dey <megha.dey@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        "maz@kernel.org" <maz@kernel.org>,
        "bhelgaas@google.com" <bhelgaas@google.com>,
        "rafael@kernel.org" <rafael@kernel.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "megha.dey@intel.com" <megha.dey@intel.com>,
        "jacob.jun.pan@intel.com" <jacob.jun.pan@intel.com>
Subject: Re: [RFC V1 0/7] Add support for a new IMS interrupt mechanism
Thread-Topic: [RFC V1 0/7] Add support for a new IMS interrupt mechanism
Thread-Index: AQHVadCis80jNXQJ7ESbv2tE+P8b86cpe96AgACTvQCACUwHgA==
Date:   Thu, 19 Sep 2019 18:25:42 +0000
Message-ID: <20190919182537.GS30961@mellanox.com>
References: <1568338328-22458-1-git-send-email-megha.dey@linux.intel.com>
 <VI1PR05MB4141EAE19EE47DA20A75AE21CFB30@VI1PR05MB4141.eurprd05.prod.outlook.com>
 <20190913202710.GA999@otc-nc-03>
In-Reply-To: <20190913202710.GA999@otc-nc-03>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [142.167.223.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 925894c2-f9f7-42af-4564-08d73d2ec7bc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020);SRVR:VI1PR05MB5967;
x-ms-traffictypediagnostic: VI1PR05MB5967:
x-microsoft-antispam-prvs: <VI1PR05MB59671A1E67F514948067DBFCCF890@VI1PR05MB5967.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(396003)(346002)(199004)(189003)(81156014)(81166006)(6246003)(256004)(33656002)(76176011)(14454004)(316002)(52116002)(36756003)(7416002)(5660300002)(6916009)(6486002)(54906003)(99286004)(1076003)(6512007)(11346002)(6436002)(86362001)(66476007)(66066001)(71190400001)(66556008)(8936002)(229853002)(66446008)(8676002)(4326008)(305945005)(6506007)(64756008)(71200400001)(66946007)(26005)(2906002)(7736002)(2616005)(476003)(25786009)(386003)(446003)(486006)(6116002)(3846002)(478600001)(186003)(102836004);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR05MB5967;H:VI1PR05MB4141.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: mellanox.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 862ZkM4epSk+udoBZqLa6r30v1jZ9vuwfdsXrEdS7gbZRFVp3Dgrh4ZteQRVXfFfbV2r0r+qZ8sC86wAZ7I8/D4ngNdy8AR/jp1ZcFvEZFxTJ9syhZS8fA/NSVtb6w4I1knG2ZmMLICe4ETpCpiQXJ2wgJub2X12kGO4hp/370eOOF619GcorkFE6OTQUZnIhPcAjbr5dT3XZm47MF8Yf4/ljK6zem2m6VrDXiUNUL6Kd9wNfWgDw7z863coexKTgWMukTvtxJn9dEJuwGX+OoAU8bduGt84Mocx75Abjy+wpwGovHIlilS2nRMuQ91Hzx3Lb9JdPsvxztm7eJwGlfIDLmnbh6w2FnT4n5s3fGF+o9La4ERCtvg8JDsfCm+0/lR5tX0rItwmPpPFG7wwJsPT+/CQN/R4t9w81tgewk4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DFA492F5B86A2B49B5A2935F788CD314@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 925894c2-f9f7-42af-4564-08d73d2ec7bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 18:25:42.6308
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TkZXkF/5MHPq96veannt+eapaD3czEPGp1Mpi/t+7PvAcs2SsM2IJykFj6jaFBH/G0WzmBK4zJmk1rBIIAsc8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB5967
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 13, 2019 at 01:27:10PM -0700, Raj, Ashok wrote:
> On Fri, Sep 13, 2019 at 07:50:50PM +0000, Jason Gunthorpe wrote:
> > On Thu, Sep 12, 2019 at 06:32:01PM -0700, Megha Dey wrote:
> >=20
> > > This series is a basic patchset to get the ball rolling and receive s=
ome
> > > inital comments. As per my discussion with Marc Zyngier and Thomas Gl=
eixner
> > > at the Linux Plumbers, I need to do the following:
> > > 1. Since a device can support MSI-X and IMS simultaneously, ensure pr=
oper
> > >    locking mechanism for the 'msi_list' in the device structure.
> > > 2. Introduce dynamic allocation of IMS vectors perhaps by using a gro=
up ID
> > > 3. IMS support of a device needs to be discoverable. A bit in the ven=
dor
> > >    specific capability in the PCI config is to be added rather than g=
etting
> > >    this information from each device driver.
> >=20
> > Why #3? The point of this scheme is to delegate programming the
> > addr/data pairs to the driver so it can be done in some
> > device-specific way. There is no PCI standard behind this, and no
> > change in PCI semantics.=20
> >=20
> > I think it would be a tall ask to get a config space bit from PCI-SIG
> > for something that has little to do with PCI.
>=20
> This isn't a standard config capability. Its Designated Vendor Specific
> Capability (DVSEC). The device is responsible for managing the addr-data
> pair. This provides a hint to the OS framework that this device has
> device specific methods.
>=20
> Agreed its not required, but some OSV's like a generic way to discover
> these capabilities, hence its there so device vendors can have
> a common guideline.

I think it would be reasonable for a specific device driver to test
the DVSEC, if it wishes too.=20

Since it is not required it does not make sense for the core kernel to
enforce this on all devices, at least for such a nebulous reason.

Jason