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
Date: Thu, 19 Sep 2019 18:25:42 +0000 [thread overview]
Message-ID: <20190919182537.GS30961@mellanox.com> (raw)
In-Reply-To: <20190913202710.GA999@otc-nc-03>
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:
> >
> > > This series is a basic patchset to get the ball rolling and receive some
> > > inital comments. As per my discussion with Marc Zyngier and Thomas Gleixner
> > > at the Linux Plumbers, I need to do the following:
> > > 1. Since a device can support MSI-X and IMS simultaneously, ensure proper
> > > locking mechanism for the 'msi_list' in the device structure.
> > > 2. Introduce dynamic allocation of IMS vectors perhaps by using a group ID
> > > 3. IMS support of a device needs to be discoverable. A bit in the vendor
> > > specific capability in the PCI config is to be added rather than getting
> > > this information from each device driver.
> >
> > 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.
> >
> > 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.
>
> 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.
>
> 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.
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
prev parent reply other threads:[~2019-09-19 18:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 1:32 [RFC V1 0/7] Add support for a new IMS interrupt mechanism Megha Dey
2019-09-13 1:32 ` [RFC V1 1/7] genirq/msi: Differentiate between various MSI based interrupts Megha Dey
2019-09-13 4:40 ` Greg KH
2019-09-13 14:40 ` Jason Gunthorpe
2019-09-26 21:50 ` Bjorn Helgaas
2019-09-13 1:32 ` [RFC V1 2/7] drivers/base: Introduce callbacks for IMS interrupt domain Megha Dey
2019-09-13 4:39 ` Greg KH
2019-09-13 14:50 ` Jason Gunthorpe
2019-09-13 1:32 ` [RFC V1 3/7] x86/ims: Add support for a new IMS irq domain Megha Dey
2019-09-13 14:52 ` Jason Gunthorpe
2019-09-13 22:07 ` Alex Williamson
2019-09-13 1:32 ` [RFC V1 4/7] irq_remapping: New interfaces to support IMS irqdomain Megha Dey
2019-09-13 1:32 ` [RFC V1 5/7] x86/ims: Introduce x86_ims_ops Megha Dey
2019-09-13 14:54 ` Jason Gunthorpe
2019-09-13 1:32 ` [RFC V1 6/7] ims-msi: Add APIs to allocate/free IMS interrupts Megha Dey
2019-09-26 21:44 ` Bjorn Helgaas
2019-09-13 1:32 ` [RFC V1 7/7] ims: Add the set_desc callback Megha Dey
2019-09-26 21:47 ` Bjorn Helgaas
2019-09-13 19:50 ` [RFC V1 0/7] Add support for a new IMS interrupt mechanism Jason Gunthorpe
2019-09-13 20:27 ` Raj, Ashok
2019-09-19 18:25 ` Jason Gunthorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190919182537.GS30961@mellanox.com \
--to=jgg@mellanox.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=maz@kernel.org \
--cc=megha.dey@intel.com \
--cc=megha.dey@linux.intel.com \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).