Hi David/Joerg
Haven't heard about it from David yet, but can we queue this for 4.10?
If you have any questions/concerns please let us know.
Cheers,
Ashok
On Wed, Dec 14, 2016 at 02:36:40PM +0200, Mika Kuoppala wrote:
> >
> > cc: Mika Kuoppala
> > cc: Ashok Raj
> > Signed-off-by: Jacob Pan
Hi Bjorn
On Thu, Dec 22, 2016 at 02:28:03PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 22, 2016 at 05:27:14PM +0100, Joerg Roedel wrote:
> > Hi Bjorn,
> >
> > On Mon, Dec 19, 2016 at 03:20:44PM -0600, Bjorn Helgaas wrote:
> > > I have some questions about dmar_init_reserved_ranges(). On systems
>
3:32:38PM -0800, Raj, Ashok wrote:
> Let me check and keep you posted if we have such platforms to make sure if
> we need this considerations for _TRA.
Cheers,
Ashok
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation
Hi Bjorn,
On Tue, Dec 27, 2016 at 05:44:17PM -0600, Bjorn Helgaas wrote:
>
> dmar_init_reserved_ranges()
> {
> ...
> for_each_pci_dev(pdev) {
> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> r = &pdev->resource[i];
> reserve_iova(r)
>
> But I assume it's possible t
On Wed, Mar 01, 2017 at 04:09:38PM -0500, Konrad Rzeszutek Wilk wrote:
> .snip..
> >
> > No. SVM is purely about sharing CPU address space with device. Command
> > submission is still through kernel driver which controls rings (with SVM
> > then
> > you can put VA into those commands). There are
Hi David,
Good to hear back from you!
On Fri, Mar 03, 2017 at 09:40:44AM +, David Woodhouse wrote:
>
> Intel slightly deviates from the "one PASID per process" vision too,
> because it currently has a PASID allocator idr per IOMMU. That wants
> making system-wide. And probably not Intel-spe
Hi Joerg,
On Thu, Apr 27, 2017 at 06:12:38PM +0200, j...@8bytes.org wrote:
> On Thu, Apr 27, 2017 at 03:34:06PM +, Zhuo, Qiuxu wrote:
> > It looks like the printk is misleading and it’s nothing actually
> > failed, but just it isn’t copying if the new kernel is not a kdump
> > kernel.
>
> Yes
On Thu, May 04, 2017 at 02:28:53PM -0600, Alex Williamson wrote:
> On Thu, 27 Apr 2017 18:53:17 +0800
> Peter Xu wrote:
>
> > On Wed, Apr 26, 2017 at 06:06:33PM +0800, Liu, Yi L wrote:
> > > Expose "Shared Virtual Memory" to guest by using "svm" option.
> > > Also use "svm" to expose SVM related
Hi Jean
On Thu, May 11, 2017 at 11:50:24AM +0100, Jean-Philippe Brucker wrote:
> Hi,
>
> On 10/05/17 19:39, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> Since your series is likely to go in much earlier than my SVM mess, maybe
> you could
On Thu, May 11, 2017 at 11:50:24AM +0100, Jean-Philippe Brucker wrote:
> Hi,
>
> On 10/05/17 19:39, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> Since your series is likely to go in much earlier than my SVM mess, maybe
> you could carry tha
On Tue, May 30, 2017 at 02:50:33PM -0500, Bjorn Helgaas wrote:
> On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> The above patch (9593891) is not in my tree or Linus' tree, so I can't
> do anything with
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.
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 ad
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
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. T
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 no
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
> > init
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 PASI
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.
> >
&
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 spec,
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
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 to
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;
> +
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 iommu
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 there
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 ways
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,
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 wo
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 Ad
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 thread'
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
> &
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 Cont
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
; Thanks
> Kevin
>
> > -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,
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 to
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
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
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 around
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
> > --
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
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 V
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 device
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 th
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 ap
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);
> > > > + i
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 Addres
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 1st-leve
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..? mmmap
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 i
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 suppor
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 IOASI
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 ---
On Fri, Aug 04, 2017 at 10:42:41AM +0100, Jean-Philippe Brucker wrote:
> Hi Kevin,
>
>
> Consider the situation where a userspace driver (no virtualization) is
> built in a client-server fashion: the server controls a device and spawns
> new processes (clients), each sharing a context with the de
Hi Joerg
I haven't received any update to this patchset..
Could you help get this merged through your tree? we have tested this
series internally.
Cheers,
Ashok
On Tue, Aug 08, 2017 at 01:29:26PM -0700, Ashok Raj wrote:
> Hi
>
> Sorry for resending.. iommu list email was mistyped :-(
>
> The
Thanks Joerg
On Fri, Aug 18, 2017 at 11:35:21AM +0200, Joerg Roedel wrote:
> Hi Ashok,
>
> On Tue, Aug 15, 2017 at 07:59:29AM -0700, Raj, Ashok wrote:
> > I haven't received any update to this patchset..
> >
> > Could you help get this merged through your tree
On Mon, Sep 25, 2017 at 12:45:00PM +0100, Jean-Philippe Brucker wrote:
[snip]
> This format tells how the guest organizes its PASID tables. Depending on
> 'format', the PASID table can be:
> * A flat array of descriptors
> * One array of 1st-level descriptors pointing to a 2nd level of
> descripto
Hi Casey
Sorry, somehow didn't see this one come by.
On Mon, Sep 25, 2017 at 05:46:40PM +, Casey Leedom wrote:
> | From: Robin Murphy
> | Sent: Wednesday, September 20, 2017 3:12 AM
> |
> | On 20/09/17 09:01, Herbert Xu wrote:
> | >
> | > Harsh Jain wrote:
> | >>
> | >> While debugging DMA
Hi
On Mon, Sep 25, 2017 at 01:11:04PM -0700, Dan Williams wrote:
> On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
> > | From: Dan Williams
> > | Sent: Monday, September 25, 2017 12:31 PM
> > | ...
> > | IIUC it looks like this has been broken ever since commit e1605495c716
> > | "intel-iom
On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 6784a05dd6b2..d7f7def81613 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -2254,10 +2254,12 @@ static int __domain_mapp
Oops..minor typo.. VTD_PAGE_SHIFT instead of VTD_PAGE_MASK
On Tue, Sep 26, 2017 at 07:34:41AM -0700, Ashok Raj wrote:
> On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index 6784a05dd6b2..d7f7def81613 100
Hi Robin
On Wed, Sep 27, 2017 at 06:18:02PM +0100, Robin Murphy wrote:
> On Wed, 27 Sep 2017 16:31:04 +
> Casey Leedom wrote:
>
> > | From: Dan Williams
> > | Sent: Tuesday, September 26, 2017 9:10 AM
> > |
> > | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> > wrote: | > | From: Robin
Hi Casey
looking at the debug output i got from Harsh it still looks like
a bug in the code.
[ 538.284589] __domain_mapping nr_pages 0x1
[ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
0x38 pteval 0x3cbce3003 phys_pfn 0x3cbce3
[ 538.284604] chelsio driver - offse
Thanks for trying that Harsh.
sp_off turns of super page support. Which this mode, do you still see offsets
greater than 4k?
On Thu, Sep 28, 2017 at 07:08:21PM +0530, Harsh Jain wrote:
>
>
> Today I tried with "Intel_iommu=sp_off" boot option. Traffic runs without any
> error for more than 1
Hi Casey
On Thu, Sep 28, 2017 at 04:17:59PM +, Casey Leedom wrote:
> Thanks Robin. Harsh can certainly test your latest patch as soon as he's
> back in the office tomorrow morning India time. If your patch works and is
> accepted, it sounds like the commit would be important enough to cons
Hi Robin
thanks.. i have no idea.. i see all the other patches from you :-)
my email has decided to play games with me i suppose :-)
On Thu, Sep 28, 2017 at 05:59:11PM +0100, Robin Murphy wrote:
> I hope our email server hasn't got blacklisted again... Said patch is
> the top of this very thread
Hi Jean
On Thu, Sep 28, 2017 at 12:21:34PM +0100, Jean-Philippe Brucker wrote:
> On 27/09/17 14:40, Joerg Roedel wrote:
> > Hi,
> >
> > On Wed, Sep 20, 2017 at 01:09:47PM +0100, Jean-Philippe Brucker wrote:
> >> For binding page tables instead of PASID tables (e.g. virtio-iommu), the
> >> generic
Hi Ronan
has it worked ever with intel_iommu=on?
This is on my list to look, but didn't get a chance to look into it.
I suspect that after suspend, we do save some of the registers that might
loose context. But the driver needs to reinitialize the uarch states
again. for e.g. need to go throug
Hi Robin
I now see your patch and it does seem to be fix the problem.
On Thu, Sep 28, 2017 at 08:43:46AM -0700, Ashok Raj wrote:
> Hi Robin
>
>
> On Thu, Sep 28, 2017 at 05:59:11PM +0100, Robin Murphy wrote:
> > I hope our email server hasn't got blacklisted again... Said patch is
> > the top o
On Fri, Oct 06, 2017 at 04:43:09PM +0200, Joerg Roedel wrote:
> On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote:
> > Now, there are indeed plenty of drivers and subsystems which do work on
> > lists of explicitly single pages - anything doing some variant of
> > "addr = kmap_atomic(sg_
Hi Jean
On Mon, Oct 23, 2017 at 01:17:07PM +0100, Jean-Philippe Brucker wrote:
> On 23/10/17 12:04, Liu, Yi L wrote:
> >> + idr_preload(GFP_KERNEL);
> >> + spin_lock(&iommu_process_lock);
> >> + pasid = idr_alloc_cyclic(&iommu_process_idr, process, domain->min_pasid,
> >> +
Hi Alex
On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote:
> On Wed, 15 Nov 2017 15:54:56 -0800
> Jacob Pan wrote:
>
> > Hi Alex and all,
> >
> > Just wondering if you could merge Robin's patch for the next rc. From
> > all our testing, this seems to be a solid fix and should be i
On Thu, Nov 16, 2017 at 12:20:47PM +0200, nick klingsman wrote:
> * Note: Please 'CC'/Reply my email as I'm not subscribed to the list yet.
>
> Hi,
>
> During __iommu_flush_iotlb() we set the WD (WriteDrain) bit if the
> iommu supports cap_write_drain(). This part of the logic exists from
> day o
Hi Nick
On Fri, Nov 17, 2017 at 01:57:19AM +0200, nick klingsman wrote:
>
> Oh - now I understand the confusion. Although the subject said 'deferred'
> I used the word 'Batched' in the email body. I meant 'deferred'. Not batching.
> If it was only batching, than it would make sens as 'Ashok' poin
Hi Alex
On Fri, Nov 17, 2017 at 09:18:14AM -0700, Alex Williamson wrote:
> On Thu, 16 Nov 2017 13:09:33 -0800
> "Raj, Ashok" wrote:
>
> > >
> > > What do we do about this? I certainly can't rip out large page support
> > > and put a stabl
Hi Alex
you can add for the whole series
Reviewed By: Ashok Raj
On Wed, Nov 22, 2017 at 11:25:40AM -0800, Mehta, Sohil wrote:
> Hi all,
>
> This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
> registers, internal context and dumps individual table entries to help debug
>
On Wed, Dec 06, 2017 at 09:49:59AM -0700, Jerry Snitselaar wrote:
> It is unlikely request_threaded_irq will fail, but if it does for some
> reason we should clear iommu->pr_irq in the error path. Also
> intel_svm_finish_prq shouldn't try to clean up the page request
> interrupt if pr_irq is 0. Wit
Hi Bob
On Thu, Dec 14, 2017 at 02:07:38PM +0800, Bob Liu wrote:
> On 2017/12/14 11:38, Lu Baolu wrote:
> We already have an existing MMU notifiers for userspace updates,
> however we lack the same thing for kernel page table updates. To
> >> Sorry, I didn't get which situation need this
Hi Joerg,
On Tue, Feb 13, 2018 at 03:03:03PM +0100, Joerg Roedel wrote:
> On Fri, Feb 02, 2018 at 04:49:56PM -0800, Sohil Mehta wrote:
> > This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
> > registers, internal context and dumps individual table entries to help debug
> >
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
> > >
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 makes
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 VM
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:
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
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 bra
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 be
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 has
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 prog
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)
s/
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 is
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 fo
On Thu, Jun 09, 2022 at 03:08:10PM +0800, Lu Baolu wrote:
> The IOMMU page tables are updated using iommu_map/unmap() interfaces.
> Currently, there is no mandatory requirement for drivers to use locks
> to ensure concurrent updates to page tables, because it's assumed that
> overlapping IOVA range
On Tue, Jun 07, 2022 at 09:49:32AM +0800, Lu Baolu wrote:
> Use this field to keep the number of supported PASIDs that an IOMMU
> hardware is able to support. This is a generic attribute of an IOMMU
> and lifting it into the per-IOMMU device structure makes it possible
There is also a per-device
On Tue, Jun 07, 2022 at 09:49:33AM +0800, Lu Baolu wrote:
> Use this field to save the number of PASIDs that a device is able to
> consume. It is a generic attribute of a device and lifting it into the
> per-device dev_iommu struct could help to avoid the boilerplate code
> in various IOMMU drivers
Hi Baolu
some minor nits.
On Tue, Jun 07, 2022 at 09:49:35AM +0800, Lu Baolu wrote:
> The sva iommu_domain represents a hardware pagetable that the IOMMU
> hardware could use for SVA translation. This adds some infrastructure
> to support SVA domain in the iommu common layer. It includes:
>
> -
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
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 tryin
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
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 pe
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:
> > >
> > > > Global
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
> > > >
1 - 100 of 148 matches
Mail list logo
