Re: [RESEND PATACH 1/1] iommu/vt-d: Use user privilege for RID2PASID translation

2021-05-12 Thread Raj, Ashok
On Wed, May 12, 2021 at 02:44:26PM +0800, Lu Baolu wrote: > When first-level page tables are used for IOVA translation, we use user > privilege by setting U/S bit in the page table entry. This is to make it > consistent with the second level translation, where the U/S enforcement > is not

Re: [PATCH 1/1] iommu/vt-d: Tweak the description of a DMA fault

2021-05-12 Thread Raj, Ashok
On Wed, May 12, 2021 at 02:50:12PM +0800, Lu Baolu wrote: > The Intel IOMMU driver reports the DMA fault reason in a decimal number > while the VT-d specification uses a hexadecimal one. It's inconvenient > that users need to covert them everytime before consulting the spec. > Let's use

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-10 Thread Raj, Ashok
On Mon, May 10, 2021 at 12:31:11PM -0300, Jason Gunthorpe wrote: > On Mon, May 10, 2021 at 08:25:02AM -0700, Raj, Ashok wrote: > > > Global PASID doesn't break anything, but giving that control to vIOMMU > > doesn't seem right. When we have mixed uses cases like hardware that &

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-10 Thread Raj, Ashok
On Mon, May 10, 2021 at 09:37:29AM -0300, Jason Gunthorpe wrote: > On Sat, May 08, 2021 at 09:56:59AM +, Tian, Kevin wrote: > > > From: Raj, Ashok > > > Sent: Friday, May 7, 2021 12:33 AM > > > > > > > Basically it means when the guest's top l

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-07 Thread Raj, Ashok
Hi Jason - Removed lizefan's email due to bounces... On Fri, May 07, 2021 at 03:20:50PM -0300, Jason Gunthorpe wrote: > On Fri, May 07, 2021 at 11:14:58AM -0700, Raj, Ashok wrote: > > On Fri, May 07, 2021 at 02:20:51PM -0300, Jason Gunthorpe wrote: > > > On Thu, May 06, 2021 a

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-07 Thread Raj, Ashok
On Fri, May 07, 2021 at 02:20:51PM -0300, Jason Gunthorpe wrote: > On Thu, May 06, 2021 at 09:32:40AM -0700, Raj, Ashok wrote: > > > For platforms that support ENQCMD, it is required to mandate PASIDs are > > global across the entire system. Maybe its better to call them gP

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-06 Thread Raj, Ashok
Hi Jason On Thu, May 06, 2021 at 09:27:30AM -0300, Jason Gunthorpe wrote: > On Thu, May 06, 2021 at 09:23:48AM +0200, Jean-Philippe Brucker wrote: > > On Wed, May 05, 2021 at 01:04:46PM -0700, Jacob Pan wrote: > > > > > For ARM, since the guest owns the per device PASID table. There is no > > > >

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

2021-05-05 Thread Raj, Ashok
On Wed, May 05, 2021 at 07:21:20PM -0300, Jason Gunthorpe wrote: > On Wed, May 05, 2021 at 01:04:46PM -0700, Jacob Pan wrote: > > Hi Jason, > > > > On Wed, 5 May 2021 15:00:23 -0300, Jason Gunthorpe wrote: > > > > > On Wed, May 05, 2021 at 10:22:59AM -0700, Jacob Pan wrote: > > > > > > >

Re: [PATCH 2/5] iommu/vt-d: Remove WO permissions on second-level paging entries

2021-03-08 Thread Raj, Ashok
Hi Joerg On Mon, Mar 08, 2021 at 09:58:26AM +0800, Lu Baolu wrote: > Hi Joerg, > > On 3/4/21 8:26 PM, Joerg Roedel wrote: > >On Thu, Feb 25, 2021 at 02:26:51PM +0800, Lu Baolu wrote: > >>When the first level page table is used for IOVA translation, it only > >>supports Read-Only and Read-Write

Re: [PATCH v13 06/10] iommu: Add a page fault handler

2021-03-02 Thread Raj, Ashok
On Tue, Mar 02, 2021 at 10:26:42AM +0100, Jean-Philippe Brucker wrote: [snip] > + > +static enum iommu_page_response_code > +iopf_handle_single(struct iopf_fault *iopf) > +{ > + vm_fault_t ret; > + struct mm_struct *mm; > + struct vm_area_struct *vma; > + unsigned int access_flags

Re: [PATCH 2/3] iommu/vt-d: Parse SATC reporting structure

2021-02-02 Thread Raj, Ashok
On Tue, Feb 02, 2021 at 12:40:56PM +0800, Lu Baolu wrote: > From: Yian Chen > > Software should parse every SATC table and all devices in the tables > reported by the BIOS and keep the information in kernel list for further > SATC policy deployment. > The last part seems bit vague? Are you

Re: [PATCH 1/3] iommu/vt-d: Add new enum value and structure for SATC

2021-02-02 Thread Raj, Ashok
On Tue, Feb 02, 2021 at 12:40:55PM +0800, Lu Baolu wrote: > From: Yian Chen > > Starting from Intel Platform VT-d v3.2, BIOS may provide new remapping > structure SATC for SOC integrated devices, according to section 8.8 of > Intel VT-d architecture specification v3.2. The SATC structure reports

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-21 Thread Raj, Ashok
On Wed, Oct 21, 2020 at 08:32:18PM -0300, Jason Gunthorpe wrote: > On Wed, Oct 21, 2020 at 01:03:15PM -0700, Raj, Ashok wrote: > > > I'm not sure why you tie in IDXD and VDPA here. How IDXD uses native > > SVM is orthogonal to how we achieve mdev passthrough to guest and >

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-21 Thread Raj, Ashok
On Wed, Oct 21, 2020 at 03:24:42PM -0300, Jason Gunthorpe wrote: > > > Contrary to your argument, vDPA went with a half blown device only > > iommu user without considering existing abstractions like containers > > VDPA IOMMU was done *for Intel*, as the kind of half-architected thing > you are

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-21 Thread Raj, Ashok
On Wed, Oct 21, 2020 at 08:48:29AM -0300, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote: > > On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote: > > > On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote: > > > &

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-20 Thread Raj, Ashok
On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote: > > On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote: > > > On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote: > > > &g

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-20 Thread Raj, Ashok
On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote: > > I think we agreed (or agree to disagree and commit) for device types that > > we have for SIOV, VFIO based approach works well without having to

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-20 Thread Raj, Ashok
On Tue, Oct 20, 2020 at 02:03:36PM -0300, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 09:24:30AM -0700, Raj, Ashok wrote: > > Hi Jason, > > > > > > On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote: > > > On Tue, Oct 20, 2020

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-20 Thread Raj, Ashok
Hi Jason, On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote: > On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote: > > > > I'm sure there will be some > > > weird overlaps because we can't delete any of the existing VFIO APIs, but > > > that > > > should not be a blocker. >

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-19 Thread Raj, Ashok
Hi Jean On Mon, Oct 19, 2020 at 04:08:24PM +0200, Jean-Philippe Brucker wrote: > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2): > > > > > > To stop [using a PASID] witho

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-17 Thread Raj, Ashok
Hi Jean On Fri, Oct 16, 2020 at 09:59:23AM +0200, Jean-Philippe Brucker wrote: > On Thu, Oct 15, 2020 at 11:22:11AM -0700, Raj, Ashok wrote: > > Hi Jean > > > > + Baolu who is looking into this. > > > > > > On Thu, Oct 15, 2020 at 11:00:27AM +0200,

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-15 Thread Raj, Ashok
Hi Jean + Baolu who is looking into this. On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote: > Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver > whether the PRI queue needs flushing. When looking at the PCIe spec > again I noticed that most of the

Re: [Patch V8 0/3] iommu: Add support to change default domain of an iommu group

2020-10-01 Thread Raj, Ashok
Hi Joerg On Thu, Oct 01, 2020 at 02:58:41PM +0200, Joerg Roedel wrote: > Hi Ashok, > > On Fri, Sep 25, 2020 at 12:06:17PM -0700, Ashok Raj wrote: > > Sai Praneeth Prakhya (3): > > iommu: Add support to change default domain of an iommu group > > iommu: Take lock before reading iommu group

Re: [PATCH V7 0/3] iommu: Add support to change default domain of an iommu group

2020-09-28 Thread Raj, Ashok
Hi Joerg On Fri, Sep 25, 2020 at 09:34:23AM +0200, Joerg Roedel wrote: > Hi Ashok, > > On Thu, Sep 24, 2020 at 10:21:48AM -0700, Raj, Ashok wrote: > > Just trying to followup on this series. > > > > Sai has moved out of Intel, hence I'm trying to followup on his b

Re: [PATCH V7 0/3] iommu: Add support to change default domain of an iommu group

2020-09-25 Thread Raj, Ashok
Hi Joerg, thanks! On Fri, Sep 25, 2020 at 09:34:23AM +0200, Joerg Roedel wrote: > Hi Ashok, > > On Thu, Sep 24, 2020 at 10:21:48AM -0700, Raj, Ashok wrote: > > Just trying to followup on this series. > > > > Sai has moved out of Intel, hence I'm trying to followup

Re: [bugzilla-dae...@bugzilla.kernel.org: [Bug 209149] New: "iommu/vt-d: Enable PCI ACS for platform opt in hint" makes NVMe config space not accessible after S3]

2020-09-24 Thread Raj, Ashok
On Wed, Sep 23, 2020 at 12:45:11PM -0700, Rajat Jain wrote: > On Wed, Sep 23, 2020 at 9:19 AM Raj, Ashok wrote: > > > > Hi Bjorn > > > > > > On Wed, Sep 23, 2020 at 11:03:27AM -0500, Bjorn Helgaas wrote: > > > [+cc IOMMU and NVMe folks] > > >

Re: [bugzilla-dae...@bugzilla.kernel.org: [Bug 209149] New: "iommu/vt-d: Enable PCI ACS for platform opt in hint" makes NVMe config space not accessible after S3]

2020-09-24 Thread Raj, Ashok
Hi Alex > > Apparently it also requires to disable RR, and I'm not able to confirm if > > CML requires that as well. > > > > pci_quirk_disable_intel_spt_pch_acs_redir() also seems to consult the same > > table, so i'm not sure why we need the other patch in bugzilla is required. > > If we're

Re: [bugzilla-dae...@bugzilla.kernel.org: [Bug 209149] New: "iommu/vt-d: Enable PCI ACS for platform opt in hint" makes NVMe config space not accessible after S3]

2020-09-24 Thread Raj, Ashok
Hi Kai + Alex, since he had some of the early quirks authored. On Thu, Sep 24, 2020 at 12:31:53AM +0800, Kai-Heng Feng wrote: > [+Cc Christoph] > > > On Sep 24, 2020, at 00:03, Bjorn Helgaas wrote: > > > > [+cc IOMMU and NVMe folks] > > > > Sorry, I forgot to forward this to linux-pci when

Re: [PATCH V7 0/3] iommu: Add support to change default domain of an iommu group

2020-09-24 Thread Raj, Ashok
Hi Joerg, On Mon, Sep 07, 2020 at 08:54:44PM -0700, Prakhya, Sai Praneeth wrote: > Presently, the default domain of an iommu group is allocated during boot time > and it cannot be changed later. So, the device would typically be either in > identity (pass_through) mode or the device would be in

Re: [bugzilla-dae...@bugzilla.kernel.org: [Bug 209149] New: "iommu/vt-d: Enable PCI ACS for platform opt in hint" makes NVMe config space not accessible after S3]

2020-09-23 Thread Raj, Ashok
Hi Bjorn On Wed, Sep 23, 2020 at 11:03:27AM -0500, Bjorn Helgaas wrote: > [+cc IOMMU and NVMe folks] > > Sorry, I forgot to forward this to linux-pci when it was first > reported. > > Apparently this happens with v5.9-rc3, and may be related to > 50310600ebda ("iommu/vt-d: Enable PCI ACS for

Re: [PATCH v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-17 Thread Raj, Ashok
Thanks Boris. multiple "again" makes it funny again :-) On Thu, Sep 17, 2020 at 07:18:49PM +0200, Borislav Petkov wrote: > On Thu, Sep 17, 2020 at 07:56:09AM -0700, Raj, Ashok wrote: > > Just tweaked it a bit: > > > > "When ATS lookup fails for a vi

Re: [PATCH v8 3/9] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-17 Thread Raj, Ashok
Hi Boris, On Thu, Sep 17, 2020 at 09:53:38AM +0200, Borislav Petkov wrote: > On Tue, Sep 15, 2020 at 09:30:07AM -0700, Fenghua Yu wrote: > > +Background > > +== > > + > > +Shared Virtual Addressing (SVA) allows the processor and device to use the > > +same virtual addresses avoiding the

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-16 Thread Raj, Ashok
On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote: > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote: > > > If user space wants to bind page tables, create the PASID with > > > /dev/sva, use ioctls there to setup the page table the way it wants, > > > then pass the

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-15 Thread Raj, Ashok
On Tue, Sep 15, 2020 at 03:45:10PM -0300, Jason Gunthorpe wrote: > On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote: > > > PASID applies widely to many device and needs to be introduced with a > > > wide community agreement so all scenarios will be supportable. &

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-15 Thread Raj, Ashok
On Tue, Sep 15, 2020 at 08:33:41AM -0300, Jason Gunthorpe wrote: > On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote: > > Hi Jason, > > > > I thought we discussed this at LPC, but still seems to be going in > > circles :-(. > > We discused mdev at L

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-14 Thread Raj, Ashok
Hi Jason, I thought we discussed this at LPC, but still seems to be going in circles :-(. On Mon, Sep 14, 2020 at 04:00:57PM -0300, Jason Gunthorpe wrote: > On Mon, Sep 14, 2020 at 12:23:28PM -0600, Alex Williamson wrote: > > On Mon, 14 Sep 2020 14:41:21 -0300 > > Jason Gunthorpe wrote: > > >

Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-09-14 Thread Raj, Ashok
Hi Jason, On Mon, Sep 14, 2020 at 10:47:38AM -0300, Jason Gunthorpe wrote: > On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote: > > > > Jason suggest something like /dev/sva. There will be a lot of other > > > subsystems that could benefit from this (e.g vDPA). > > > > Do

Re: [PATCH] intel-iommu: don't disable ATS for device without page aligned request

2020-09-10 Thread Raj, Ashok
On Wed, Sep 09, 2020 at 10:17:35PM -0400, Jason Wang wrote: > > > - Original Message - > > Hi Jason > > > > On Wed, Sep 09, 2020 at 04:34:32PM +0800, Jason Wang wrote: > > > Commit 61363c1474b1 ("iommu/vt-d: Enable ATS only if the device uses > > > page aligned address.") disables ATS

Re: [PATCH] intel-iommu: don't disable ATS for device without page aligned request

2020-09-09 Thread Raj, Ashok
Hi Jason On Wed, Sep 09, 2020 at 04:34:32PM +0800, Jason Wang wrote: > Commit 61363c1474b1 ("iommu/vt-d: Enable ATS only if the device uses > page aligned address.") disables ATS for device that can do unaligned > page request. Did you take a look at the PCI specification? Page Aligned Request

Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI

2020-09-03 Thread Raj, Ashok
Hi Thomas, Thanks a ton for jumping in helping on straightening it for IMS!!! On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote: > This is the second version of providing a base to support device MSI (non > PCI based) and on top of that support for IMS (Interrupt Message Storm)

Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID

2020-08-03 Thread Raj, Ashok
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote: > On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote: > > > > On 7/31/20 4:34 PM, Andy Lutomirski wrote: > > >> Thomas suggested to provide a reason for the #GP caused by executing > > >> ENQCMD > > >> without a valid PASID value

Re: [PATCH v3 1/1] PCI/ATS: Check PRI supported on the PF device when SRIOV is enabled

2020-07-28 Thread Raj, Ashok
Hi Sasha On Mon, Jul 27, 2020 at 09:24:35PM +, Sasha Levin wrote: > Hi > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag > fixing commit: b16d0cb9e2fc ("iommu/vt-d: Always enable PASID/PRI PCI > capabilities before ATS"). > > The bot

Re: [PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

2020-07-23 Thread Raj, Ashok
Hi Bjorn On Tue, Jul 21, 2020 at 09:54:01AM -0500, Bjorn Helgaas wrote: > On Mon, Jul 20, 2020 at 09:43:00AM -0700, Ashok Raj wrote: > > PASID and PRI capabilities are only enumerated in PF devices. VF devices > > do not enumerate these capabilites. IOMMU drivers also need to enumerate > > them

Re: [PATCH v4 4/4] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices

2020-07-10 Thread Raj, Ashok
Hi Bjorn On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote: > On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote: > > When enabling ACS, enable translation blocking for external facing ports > > and untrusted devices. > > > > Signed-off-by: Rajat Jain > > --- > > v4: Add

Re: [PATCH 3/4] pci: acs: Enable PCI_ACS_TB for untrusted/external-facing devices

2020-06-19 Thread Raj, Ashok
Hi Rajat On Mon, Jun 15, 2020 at 06:17:41PM -0700, Rajat Jain wrote: > When enabling ACS, currently the bit "translation blocking" was > not getting changed at all. Set it to disable translation blocking Maybe you meant "enable translation blocking" ? Keep the commit log simple: When enabling

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Raj, Ashok
Hi Greg, On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > > Hello, > > > > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > > wrote: > > > > > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > > > wrote:

Re: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs

2020-06-16 Thread Raj, Ashok
On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote: > On Tue, Jun 16, 2020 at 02:26:38AM +, Tian, Kevin wrote: > > > From: Stefan Hajnoczi > > > Sent: Monday, June 15, 2020 6:02 PM > > > > > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote: > > > > Shared Virtual

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Raj, Ashok
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > I don't get why you need a rdmsr here, or why not having one would > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > > +*/ > > > > + rdmsrl(MSR_IA32_PASID, pasid_msr); > > > > +

Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices

2020-06-02 Thread Raj, Ashok
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote: > Currently, an external malicious PCI device can masquerade the VID:PID > of faulty gfx devices, and thus apply iommu quirks to effectively > disable the IOMMU restrictions for itself. > > Thus we need to ensure that the device we are

Re: [PATCH] iommu/vt-d: Don't apply gfx quirks to untrusted devices

2020-06-02 Thread Raj, Ashok
On Tue, Jun 02, 2020 at 06:43:00PM +, Rajat Jain wrote: > Hi MIka, > > Thanks for taking a look. > > On Tue, Jun 2, 2020 at 2:50 AM Mika Westerberg > wrote: > > > > On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote: > > > Currently, an external malicious PCI device can masquerade

Re: [PATCH v2] iommu/vt-d: Don't apply gfx quirks to untrusted devices

2020-06-02 Thread Raj, Ashok
Hi Rajat On Tue, Jun 02, 2020 at 11:41:33AM -0700, Rajat Jain wrote: > Currently, an external malicious PCI device can masquerade the VID:PID > of faulty gfx devices, and thus apply iommu quirks to effectively > disable the IOMMU restrictions for itself. > > Thus we need to ensure that the

Re: [PATCH] PCI: Relax ACS requirement for Intel RCiEP devices.

2020-06-01 Thread Raj, Ashok
On Mon, Jun 01, 2020 at 04:25:19PM -0500, Bjorn Helgaas wrote: > On Thu, May 28, 2020 at 01:57:42PM -0700, Ashok Raj wrote: > > All Intel platforms guarantee that all root complex implementations > > must send transactions up to IOMMU for address translations. Hence for > > RCiEP devices that are

Re: [PATCH] PCI: Relax ACS requirement for Intel RCiEP devices.

2020-05-28 Thread Raj, Ashok
On Thu, May 28, 2020 at 03:38:26PM -0600, Alex Williamson wrote: > On Thu, 28 May 2020 13:57:42 -0700 > Ashok Raj wrote: > > > All Intel platforms guarantee that all root complex implementations > > must send transactions up to IOMMU for address translations. Hence for > > RCiEP devices that are

Re: [PATCH] iommu: Relax ACS requirement for Intel RCiEP devices.

2020-05-28 Thread Raj, Ashok
Hi Alex On Tue, May 26, 2020 at 05:07:15PM -0600, Alex Williamson wrote: > > --- > > drivers/iommu/iommu.c | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > index 2b471419e26c..31b595dfedde 100644 > >

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-26 Thread Raj, Ashok
On Tue, May 26, 2020 at 12:26:54PM -0600, Alex Williamson wrote: > > > > > > I don't think the language in the spec is anything sufficient to handle > > > RCiEP uniquely. We've previously rejected kernel command line opt-outs > > > for ACS, and the extent to which those patches still float

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-26 Thread Raj, Ashok
Hi Alex, I was able to find better language in the IOMMU spec that gaurantees the behavior we need. See below. On Tue, May 05, 2020 at 09:34:14AM -0600, Alex Williamson wrote: > On Tue, 5 May 2020 07:56:06 -0700 > "Raj, Ashok" wrote: > > > On Tue, May 05, 2020

Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement

2020-05-18 Thread Raj, Ashok
On Mon, May 18, 2020 at 04:47:17PM +0100, David Woodhouse wrote: > On Fri, 2020-05-15 at 10:19 -0700, Raj, Ashok wrote: > > Hi Christoph > > > > On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote: > > > Can you please lift the untrusted flag

Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement

2020-05-15 Thread Raj, Ashok
Hi Christoph On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote: > Can you please lift the untrusted flag into struct device? It really > isn't a PCI specific concept, and we should not have code poking into > pci_dev all over the iommu code. Just for clarification: All IOMMU's

Re: (a design open) RE: [PATCH v1 6/8] vfio/type1: Bind guest page tables to host

2020-05-15 Thread Raj, Ashok
evin > > > -Original Message- > > From: Liu, Yi L > > Sent: Sunday, March 22, 2020 8:32 PM > > To: alex.william...@redhat.com; eric.au...@redhat.com > > Cc: Tian, Kevin ; jacob.jun@linux.intel.com; > > j...@8bytes.org; Raj, Ashok ; Liu, Yi L > >

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Raj, Ashok
On Tue, May 05, 2020 at 08:05:14AM -0600, Alex Williamson wrote: > On Mon, 4 May 2020 23:11:07 -0700 > "Raj, Ashok" wrote: > > > Hi Alex > > > > + Joerg, accidently missed in the Cc. > > > > On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Wil

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Raj, Ashok
Hi Alex + Joerg, accidently missed in the Cc. On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Williamson wrote: > On Mon, 4 May 2020 21:42:16 -0700 > Ashok Raj wrote: > > > PCIe Spec recommends we can relax ACS requirement for RCIEP devices. > > > > PCIe 5.0 Specification. > > 6.12 Access

Re: [PATCH 6/7] x86/traps: Fix up invalid PASID

2020-04-27 Thread Raj, Ashok
Hi Thomas, On Tue, Apr 28, 2020 at 02:54:59AM +0200, Thomas Gleixner wrote: > Ashok, > > "Raj, Ashok" writes: > > On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote: > >> Just for the record I also suggested to have a proper errorcode in the &g

Re: [PATCH 6/7] x86/traps: Fix up invalid PASID

2020-04-27 Thread Raj, Ashok
Hi Thomas On Sun, Apr 26, 2020 at 05:25:06PM +0200, Thomas Gleixner wrote: > Fenghua Yu writes: > > A #GP fault is generated when ENQCMD instruction is executed without > > a valid PASID value programmed in. > > Programmed in what? > > > The #GP fault handler will initialize the current

Re: [PATCH v1 0/2] vfio/pci: expose device's PASID capability to VMs

2020-04-16 Thread Raj, Ashok
Hi Zhao On Thu, Apr 16, 2020 at 06:12:26PM -0400, Yan Zhao wrote: > On Tue, Mar 31, 2020 at 03:08:25PM +0800, Lu, Baolu wrote: > > On 2020/3/31 14:35, Tian, Kevin wrote: > > >> From: Liu, Yi L > > >> Sent: Sunday, March 22, 2020 8:33 PM > > >> > > >> From: Liu Yi L > > >> > > >> Shared Virtual

Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-12 Thread Raj, Ashok
Hi Alex Going through the PCIe Spec, there seems a lot of such capabilities that are different between PF and VF. Some that make sense and some don't. On Sun, Apr 12, 2020 at 08:10:43PM -0700, Raj, Ashok wrote: > > > > > I agree though, I don't know why the SIG would preclu

Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-12 Thread Raj, Ashok
On Wed, Apr 08, 2020 at 10:19:40AM -0600, Alex Williamson wrote: > On Tue, 7 Apr 2020 21:00:21 -0700 > "Raj, Ashok" wrote: > > > Hi Alex > > > > + Bjorn > > + Don > > > FWIW I can't understand why PCI SIG went different ways with ATS,

Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-08 Thread Raj, Ashok
Hi Alex On Wed, Apr 08, 2020 at 10:19:40AM -0600, Alex Williamson wrote: > On Tue, 7 Apr 2020 21:00:21 -0700 > "Raj, Ashok" wrote: > > > Hi Alex > > > > + Bjorn > > + Don > > > FWIW I can't understand why PCI SIG went different w

Re: [PATCH v1 2/2] vfio/pci: Emulate PASID/PRI capability for VFs

2020-04-07 Thread Raj, Ashok
Hi Alex + Bjorn FWIW I can't understand why PCI SIG went different ways with ATS, where its enumerated on PF and VF. But for PASID and PRI its only in PF. I'm checking with our internal SIG reps to followup on that. On Tue, Apr 07, 2020 at 09:58:01AM -0600, Alex Williamson wrote: > > Is

Re: [PATCH 2/2] iommu/vt-d: Replace intel SVM APIs with generic SVA APIs

2020-03-23 Thread Raj, Ashok
Hi Jean On Fri, Mar 20, 2020 at 10:29:55AM +0100, Jean-Philippe Brucker wrote: > > +#define to_intel_svm_dev(handle) container_of(handle, struct > > intel_svm_dev, sva) > > +struct iommu_sva * > > +intel_svm_bind(struct device *dev, struct mm_struct *mm, void *drvdata) > > +{ > > + struct

Re: [PATCH v12 2/4] uacce: add uacce driver

2020-02-24 Thread Raj, Ashok
Hi Kenneth, sorry for waking up late on this patchset. On Wed, Jan 15, 2020 at 10:12:46PM +0800, Zhangfei Gao wrote: [... trimmed] > + > +static int uacce_fops_open(struct inode *inode, struct file *filep) > +{ > + struct uacce_mm *uacce_mm = NULL; > + struct uacce_device *uacce; > +

Re: [PATCH v6 03/10] iommu/vt-d: Replace Intel specific PASID allocator with IOASID

2019-10-22 Thread Raj, Ashok
On Tue, Oct 22, 2019 at 04:53:16PM -0700, Jacob Pan wrote: > Make use of generic IOASID code to manage PASID allocation, > free, and lookup. Replace Intel specific code. > > Signed-off-by: Jacob Pan > --- > drivers/iommu/intel-iommu.c | 12 ++-- > drivers/iommu/intel-pasid.c | 36

Re: [PATCH v6 02/10] iommu/vt-d: Add custom allocator for IOASID

2019-10-22 Thread Raj, Ashok
On Tue, Oct 22, 2019 at 04:53:15PM -0700, Jacob Pan wrote: > When VT-d driver runs in the guest, PASID allocation must be > performed via virtual command interface. This patch registers a > custom IOASID allocator which takes precedence over the default > XArray based allocator. The resulting

Re: [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation

2019-10-22 Thread Raj, Ashok
On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote: > From: Lu Baolu > > If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the > IOMMU driver should rely on the emulation software to allocate > and free PASID IDs. The Intel vt-d spec revision 3.0 defines a > register set to

Re: [PATCH v6 00/10] Nested Shared Virtual Address (SVA) VT-d support

2019-10-22 Thread Raj, Ashok
Hi Jacob On Tue, Oct 22, 2019 at 04:53:13PM -0700, Jacob Pan wrote: > Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel > platforms allow address space sharing between device DMA and applications. > SVA can reduce programming complexity and enhance security. > This series

Re: [RFC PATCH 2/4] iommu/vt-d: Add first level page table interfaces

2019-09-23 Thread Raj, Ashok
On Mon, Sep 23, 2019 at 08:24:52PM +0800, Lu Baolu wrote: > This adds functions to manipulate first level page tables > which could be used by a scalale mode capable IOMMU unit. s/scalale/scalable > > intel_mmmap_range(domain, addr, end, phys_addr, prot) Maybe think of a different name..?

Re: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest

2019-09-23 Thread Raj, Ashok
Hi Jacob On Mon, Sep 23, 2019 at 12:27:15PM -0700, Jacob Pan wrote: > > > > In VT-d 3.0, scalable mode is introduced, which offers two level > > translation page tables and nested translation mode. Regards to > > GIOVA support, it can be simplified by 1) moving the GIOVA support > > over

Re: [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support

2019-07-16 Thread Raj, Ashok
Hi Eric Jacob is on sabbatical, so i'll give it my best shot :-) Yi/Kevin can jump in... On Tue, Jul 16, 2019 at 06:45:51PM +0200, Auger Eric wrote: > Hi Jacob, > > On 6/9/19 3:44 PM, Jacob Pan wrote: > > When supporting guest SVA with emulated IOMMU, the guest PASID > > table is shadowed in

Re: Device specific pass through in host systems - discuss user interface

2019-06-10 Thread Raj, Ashok
On Mon, Jun 10, 2019 at 09:38:11PM -0700, Sai Praneeth Prakhya wrote: > Hi All, > > + Sohil and Rob Clark (as there are dropped from CC'list) > > > > > Most iommu vendor drivers have switched from per-device to per-group > > > > domain (a.k.a. default domain). So per-group pass-through mode

Re: Device specific pass through in host systems - discuss user interface

2019-06-10 Thread Raj, Ashok
Hi Sai On Sun, Jun 09, 2019 at 10:41:10PM -0700, Sai Praneeth Prakhya wrote: > > > I am working on an IOMMU driver feature that allows a user to specify > > > if the DMA from a device should be translated by IOMMU or not. > > > Presently, we support only all devices or none mode i.e. if user > >

Re: [PATCH 1/1] iommu: Bind process address spaces to devices

2019-02-28 Thread Raj, Ashok
On Thu, Feb 28, 2019 at 01:15:49PM -0800, Jacob Pan wrote: > On Thu, 28 Feb 2019 15:09:50 +0100 > Joerg Roedel wrote: > > > Hi Jacob, > > > > On Wed, Feb 27, 2019 at 01:41:29PM -0800, Jacob Pan wrote: > > > On Tue, 26 Feb 2019 12:17:43 +0100 > > > Joerg Roedel wrote: > > > > > Just trying

Re: [PATCH v2 2/2] iommu/vt-d: Enable PASID only if device expects PASID in PRG Response.

2019-02-13 Thread Raj, Ashok
On Wed, Feb 13, 2019 at 12:26:33AM -0800, Tian, Kevin wrote: > > > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > > index 1457f931218e..af2e4a011787 100644 > > --- a/drivers/iommu/intel-iommu.c > > +++ b/drivers/iommu/intel-iommu.c > > @@ -1399,7 +1399,8 @@ static void

Re: [PATCH v1 1/2] PCI: ATS: Add function to check ATS page aligned request status.

2019-02-11 Thread Raj, Ashok
On Fri, Feb 08, 2019 at 11:49:55PM -0500, Sinan Kaya wrote: > On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote: > >>This means that you should probably have some kind of version check > >>here. > > > >There is no version field in ATS v1.0 spec. Also, If I follow the history > >log in PCI

Re: [PATCH v1 1/1] iommu/vt-d: Enable PRI only if the device enables PASID.

2019-02-07 Thread Raj, Ashok
On Thu, Feb 07, 2019 at 09:15:24PM +, David Woodhouse wrote: > On Thu, 2019-02-07 at 13:09 -0800, Raj, Ashok wrote: > > You are right.. they are completely orthogonal. We just don't have > > a way to handle the page-requests for request without PASID's. > > > > T

Re: [PATCH v1 1/1] iommu/vt-d: Enable PRI only if the device enables PASID.

2019-02-07 Thread Raj, Ashok
On Thu, Feb 07, 2019 at 08:08:06PM +, David Woodhouse wrote: > On Thu, 2019-02-07 at 10:44 -0800, sathyanarayanan.kuppusw...@linux.intel.com > wrote: > > From: Kuppuswamy Sathyanarayanan > > > > > > Intel IOMMU Page Request Services (PRS) only works with devices which > > supports/uses

Re: [PATCH 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint

2018-11-12 Thread Raj, Ashok
On Mon, Nov 12, 2018 at 11:09:00AM -0700, Alex Williamson wrote: > On Mon, 12 Nov 2018 19:06:26 +0300 > Mika Westerberg wrote: > > > From: Lu Baolu > > > > Intel VT-d spec added a new DMA_CTRL_PLATFORM_OPT_IN_FLAG flag > > in DMAR ACPI table for BIOS to report compliance about platform > >

Re: [PATCH 3/4] iommu/vt-d: Do not enable ATS for external devices

2018-11-12 Thread Raj, Ashok
On Mon, Nov 12, 2018 at 07:06:27PM +0300, Mika Westerberg wrote: > Currently Linux automatically enables ATS (Address Translation Service) > for any device that supports it (and IOMMU is turned on). ATS is used to > accelerate DMA access as the device can cache translations locally so > there is

Re: [PATCH 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint

2018-11-12 Thread Raj, Ashok
On Mon, Nov 12, 2018 at 07:06:26PM +0300, Mika Westerberg wrote: > From: Lu Baolu > > Intel VT-d spec added a new DMA_CTRL_PLATFORM_OPT_IN_FLAG flag > in DMAR ACPI table for BIOS to report compliance about platform > initiated DMA restricted to RMRR ranges when transferring control > to the OS.

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-10-23 Thread Raj, Ashok
On Mon, 2018-10-22 at 17:03 +0100, Jean-Philippe Brucker wrote: > On 22/10/2018 11:07, Raj, Ashok wrote: > > > For my own convenience I've been using the SVA infrastructure > > > since > > > I already had the locking and IOMMU ops in place. The > > &g

Re: [RFC PATCH 2/6] drivers core: Add I/O ASID allocator

2018-10-22 Thread Raj, Ashok
On Mon, Oct 22, 2018 at 12:49:47PM +0800, Lu Baolu wrote: > Hi, > > On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote: > > Some devices might support multiple DMA address spaces, in particular > > those that have the PCI PASID feature. PASID (Process Address Space ID) > > allows to share process

Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3

2018-10-22 Thread Raj, Ashok
On Fri, Oct 19, 2018 at 07:11:52PM +0100, Jean-Philippe Brucker wrote: > This is a first prototype adding auxiliary domain support to Arm SMMUv3, > following Lu Baolu's latest proposal for IOMMU aware mediated devices > [1]. It works, but the attach() API still doesn't feel right. See (2) > below.

Re: source-id verification failures

2018-10-05 Thread Raj, Ashok
On Thu, Oct 04, 2018 at 03:07:46PM -0700, Jacob Pan wrote: > On Thu, 4 Oct 2018 13:57:24 -0700 > Jerry Snitselaar wrote: > > > On Thu Oct 04 18, Joerg Roedel wrote: > > >Hi Jerry, > > > > > >thanks for the report. > > > > > >On Tue, Oct 02, 2018 at 10:25:29AM -0700, Jerry Snitselaar wrote: > >

Re: [PATCH V3] PCI: Enable PASID when End-to-End TLP is supported by all bridges

2018-09-26 Thread Raj, Ashok
Hi Sinan + IOMMU list. On Sat, Jun 30, 2018 at 11:24:24AM -0400, Sinan Kaya wrote: > A PCIe endpoint carries the process address space identifier (PASID) in > the TLP prefix as part of the memory read/write transaction. The address > information in the TLP is relevant only for a given PASID

Re: [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx.

2018-09-19 Thread Raj, Ashok
Hi Alex On Tue, Sep 18, 2018 at 09:59:57PM -0600, Alex Williamson wrote: > On Wed, 12 Sep 2018 10:46:19 -0700 > "Raj, Ashok" wrote: > > > On Thu, Aug 09, 2018 at 01:44:17PM -0600, Alex Williamson wrote: > > > On Thu, 9 Aug 2018 12:

Re: [RFC PATCH v2 00/10] vfio/mdev: IOMMU aware mediated device

2018-09-13 Thread Raj, Ashok
On Thu, Sep 13, 2018 at 04:03:01PM +0100, Jean-Philippe Brucker wrote: > On 13/09/2018 01:19, Tian, Kevin wrote: > >>> This is proposed for architectures which support finer granularity > >>> second level translation with no impact on architectures which only > >>> support Source ID or the similar

Re: [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx.

2018-09-12 Thread Raj, Ashok
On Thu, Aug 09, 2018 at 01:44:17PM -0600, Alex Williamson wrote: > On Thu, 9 Aug 2018 12:37:06 -0700 > Ashok Raj wrote: > > > PCI_INTERRUPT_PIN should always read 0 for SRIOV Virtual Functions. > > > > Some SRIOV devices have some bugs in RTL and VF's end up reading 1 > > instead of 0 for the

Re: [PATCH v2 06/12] iommu/vt-d: Add second level page table interface

2018-09-07 Thread Raj, Ashok
On Fri, Sep 07, 2018 at 10:47:11AM +0800, Lu Baolu wrote: > > >>+ > >>+ intel_pasid_clear_entry(dev, pasid); > >>+ > >>+ if (!ecap_coherent(iommu->ecap)) { > >>+ pte = intel_pasid_get_entry(dev, pasid); > >>+ clflush_cache_range(pte, sizeof(*pte)); > >>+ } > >>+ > >>+

Re: [PATCH 1/1] iommu/vt-d: Handle memory shortage on pasid table allocation

2018-09-06 Thread Raj, Ashok
On Sat, Sep 01, 2018 at 02:24:16PM +0800, Lu Baolu wrote: > Pasid table memory allocation could return failure due to memory > shortage. Limit the pasid table size to 1MiB because current 8MiB > contiguous physical memory allocation can be hard to come by. W/o > a PASID table, the device could

Re: [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx.

2018-08-10 Thread Raj, Ashok
On Fri, Aug 10, 2018 at 05:48:36PM +0100, Alan Cox wrote: > > The hardware isn't public yet, so can't talk about it :-(. Once this patch > > gets > > merged, will let the OSV engagement folks drive it for inclusions. We > > could mark this for stable, but i would rather wait until we know the

Re: [PATCH] vfio/pci: Some buggy virtual functions incorrectly report 1 for intx.

2018-08-09 Thread Raj, Ashok
On Thu, Aug 09, 2018 at 01:44:17PM -0600, Alex Williamson wrote: > On Thu, 9 Aug 2018 12:37:06 -0700 > Ashok Raj wrote: > > > PCI_INTERRUPT_PIN should always read 0 for SRIOV Virtual Functions. > > > > Some SRIOV devices have some bugs in RTL and VF's end up reading 1 > > instead of 0 for the

Re: [RFC PATCH 3/7] vfio: add spimdev support

2018-08-06 Thread Raj, Ashok
On Mon, Aug 06, 2018 at 09:49:40AM -0600, Alex Williamson wrote: > On Mon, 6 Aug 2018 09:40:04 +0800 > Kenneth Lee wrote: > > > > 1. It supports thousands of processes. Take zip accelerator as an example, > > any > > application need data compression/decompression will need to interact with >

  1   2   >