From: "Raj, Ashok" <ashok.raj@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
Dave Jiang <dave.jiang@intel.com>,
vkoul@kernel.org, megha.dey@intel.com, maz@kernel.org,
bhelgaas@google.com, alex.williamson@redhat.com,
jacob.jun.pan@intel.com, yi.l.liu@intel.com, baolu.lu@intel.com,
kevin.tian@intel.com, sanjay.k.kumar@intel.com,
tony.luck@intel.com, jing.lin@intel.com,
dan.j.williams@intel.com, kwankhede@nvidia.com,
eric.auger@redhat.com, parav@mellanox.com, rafael@kernel.org,
netanelg@mellanox.com, shahafs@mellanox.com,
yan.y.zhao@linux.intel.com, pbonzini@redhat.com,
samuel.ortiz@intel.com, mona.hossain@intel.com,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org,
Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v3 05/18] dmaengine: idxd: add IMS support in base driver
Date: Wed, 30 Sep 2020 18:07:06 -0700 [thread overview]
Message-ID: <20201001010706.GD26492@otc-nc-03> (raw)
In-Reply-To: <87d023gc71.fsf@nanos.tec.linutronix.de>
Hi Thomas,
On Wed, Sep 30, 2020 at 11:57:22PM +0200, Thomas Gleixner wrote:
> On Wed, Sep 30 2020 at 14:49, Ashok Raj wrote:
> >> It is the weirdest thing, IMHO. Intel defined a dvsec cap in their
> >> SIOV cookbook, but as far as I can see it serves no purpose at
> >> all.
> >>
> >> Last time I asked I got some unclear mumbling about "OEMs".
> >>
> > One of the parameters it has is the "supported system page-sizes" which is
> > usually there in the SRIOV properties. So it needed a place holder for
> > that.
> >
> > IMS is a device specific capability, and I almost forgot why we needed
> > until I had to checking internally. Remember when a device is given to a
> > guest, MSIX routing via Interrupt Remapping is automatic via the VFIO/IRQFD
> > and such.
>
> -ENOPARSE
Let me try again to see if this will turn into ESUCCESS :-)
Devices exposed to guest need host OS support for programming interrupt
entries in the IOMMU interrupt remapping table. VFIO provides those
services for standard interrupt schemes like MSI/MSIx for instance.
Since IMS is device specific VFIO can't provide an intercept when
IMS entries are programmed by the guest OS.
If the virtualisation software doesn't expose vIOMMU with virtual
capabilities to allocate IRTE entries and support for vIRTE in guest
then its expected to turn off the IMS capability. Hence driver running
in guest will not enable IMS.
>
> > When we provision an entire PCI device that is IMS capable. The guest
> > driver does know it can update the IMS entries directly without going to
> > the host. But in order to do remapping we need something like how we manage
> > PASID allocation from guest, so an IRTE entry can be allocated and the host
> > driver can write the proper values for IMS.
>
> And how is that related to that capbility thing?
>
> Also this stuff is host side and not guest side. I seriously doubt that
> you want to hand in the whole PCI device which contains the IMS
You are right, but nothing prevents a user from simply taking a full PCI
device and assign to guest.
> thing. The whole point of IMS was as far as I was told that you can
> create gazillions of subdevices and have seperate MSI interrupts for
> each of them.
Cheers,
Ashok
next prev parent reply other threads:[~2020-10-01 1:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <160021207013.67751.8220471499908137671.stgit@djiang5-desk3.ch.intel.com>
2020-09-15 23:27 ` [PATCH v3 01/18] irqchip: Add IMS (Interrupt Message Storage) driver Dave Jiang
2020-09-30 18:23 ` Thomas Gleixner
2020-10-01 22:59 ` Dey, Megha
2020-09-15 23:27 ` [PATCH v3 02/18] iommu/vt-d: Add DEV-MSI support Dave Jiang
2020-09-30 18:32 ` Thomas Gleixner
2020-10-01 23:26 ` Dey, Megha
2020-10-02 11:13 ` Thomas Gleixner
2020-10-08 7:54 ` David Woodhouse
2020-10-20 21:42 ` Dey, Megha
2020-09-15 23:28 ` [PATCH v3 05/18] dmaengine: idxd: add IMS support in base driver Dave Jiang
2020-09-30 18:47 ` Thomas Gleixner
2020-09-30 18:51 ` Jason Gunthorpe
2020-09-30 21:48 ` Thomas Gleixner
2020-09-30 21:49 ` Raj, Ashok
2020-09-30 21:57 ` Thomas Gleixner
2020-10-01 1:07 ` Raj, Ashok [this message]
2020-10-01 8:44 ` Thomas Gleixner
2020-09-30 22:38 ` Jason Gunthorpe
2020-10-01 20:48 ` Dave Jiang
2020-09-15 23:28 ` [PATCH v3 07/18] dmaengine: idxd: add basic mdev registration and helper functions Dave Jiang
2020-09-15 23:28 ` [PATCH v3 10/18] dmaengine: idxd: virtual device commands emulation Dave Jiang
2020-09-15 23:28 ` [PATCH v3 12/18] dmaengine: idxd: add mdev type as a new wq type Dave Jiang
2020-09-15 23:29 ` [PATCH v3 13/18] dmaengine: idxd: add dedicated wq mdev type Dave Jiang
2020-09-15 23:29 ` [PATCH v3 14/18] dmaengine: idxd: add new wq state for mdev Dave Jiang
2020-09-15 23:29 ` [PATCH v3 15/18] dmaengine: idxd: add error notification from host driver to mediated device Dave Jiang
2020-09-15 23:29 ` [PATCH v3 16/18] dmaengine: idxd: add ABI documentation for mediated device support Dave Jiang
2020-09-17 15:06 ` [PATCH v3 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver Jason Gunthorpe
2020-09-17 17:15 ` Dave Jiang
2020-09-17 17:27 ` Jason Gunthorpe
2020-09-17 17:30 ` Alex Williamson
2020-09-17 17:37 ` Jason Gunthorpe
[not found] ` <160021248280.67751.12525558281536923518.stgit@djiang5-desk3.ch.intel.com>
2020-09-30 18:36 ` [PATCH v3 04/18] dmaengine: idxd: add interrupt handle request support Thomas Gleixner
2020-10-01 20:16 ` Dave Jiang
[not found] ` <160021253189.67751.12686144284999931703.stgit@djiang5-desk3.ch.intel.com>
2020-09-30 19:57 ` [PATCH v3 11/18] dmaengine: idxd: ims setup for the vdcm Thomas Gleixner
2020-10-07 21:54 ` Dave Jiang
2020-10-08 7:39 ` Thomas Gleixner
2020-10-08 16:51 ` Dave Jiang
2020-10-08 23:17 ` Thomas Gleixner
2020-10-08 23:32 ` Jason Gunthorpe
2020-10-09 0:27 ` Dave Jiang
2020-10-09 1:22 ` Raj, Ashok
2020-10-09 11:57 ` Jason Gunthorpe
2020-10-09 12:43 ` Raj, Ashok
2020-10-09 12:49 ` Jason Gunthorpe
2020-10-09 13:02 ` Raj, Ashok
2020-10-09 13:12 ` Jason Gunthorpe
2020-10-09 13:40 ` Raj, Ashok
2020-10-09 14:44 ` Thomas Gleixner
2020-10-09 14:52 ` Jason Gunthorpe
2020-10-09 16:02 ` Thomas Gleixner
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=20201001010706.GD26492@otc-nc-03 \
--to=ashok.raj@intel.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=eric.auger@redhat.com \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=jing.lin@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=maz@kernel.org \
--cc=megha.dey@intel.com \
--cc=mona.hossain@intel.com \
--cc=netanelg@mellanox.com \
--cc=parav@mellanox.com \
--cc=pbonzini@redhat.com \
--cc=rafael@kernel.org \
--cc=samuel.ortiz@intel.com \
--cc=sanjay.k.kumar@intel.com \
--cc=shahafs@mellanox.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkoul@kernel.org \
--cc=x86@kernel.org \
--cc=yan.y.zhao@linux.intel.com \
--cc=yi.l.liu@intel.com \
/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).