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 gPASID
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, 2
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
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 hardw
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 hexadecimal
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 available
On Fri, Jun 18, 2021 at 12:15:06PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 18, 2021 at 03:47:51PM +0200, Joerg Roedel wrote:
> > Hi Kevin,
> >
> > On Thu, Jun 17, 2021 at 07:31:03AM +, Tian, Kevin wrote:
> > > Now let's talk about the new IOMMU behavior:
> > >
> > > - A device is blocke
On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
>
> > No. You are right on this case. I don't think there is a way to
> > differentiate one mdev from the other if they come from the
> > same parent and attached by the
On Thu, Jul 15, 2021 at 12:23:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> > On Thu, Jul 15, 2021 at 09:48:13AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jul 15, 2021 at 06:49:54AM +, Tian, Kevin wrote:
> > >
&
On Thu, Jul 15, 2021 at 02:18:26PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 09:21:41AM -0700, Raj, Ashok wrote:
> > On Thu, Jul 15, 2021 at 12:23:25PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Jul 15, 2021 at 06:57:57AM -0700, Raj, Ashok wrote:
> > > &
On Thu, Jul 15, 2021 at 02:53:36PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 10:48:36AM -0700, Raj, Ashok wrote:
>
> > > > Do we have any isolation requirements here? its the same process. So if
> > > > the
> > > > page-request it sent to
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 you
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:
> >
>
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
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.
&
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 now
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 ne
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 virtu
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 pl
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 D
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 it
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 ta
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]
> > >
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 foll
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
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 def
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 tim
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, J
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]
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.
>
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
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
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
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:
> > > &
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
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
On Thu, Dec 09, 2021 at 08:32:49AM -0800, Jacob Pan wrote:
> Hi Lu,
>
> On Thu, 9 Dec 2021 10:21:38 +0800, Lu Baolu
> wrote:
>
> > On 12/9/21 9:56 AM, Tian, Kevin wrote:
> > >> From: Jacob Pan
> > >> Sent: Thursday, December 9, 2021 2:50 AM
> > >>
> > >>> Can a device issue DMA requests with
Hi Alex
On Mon, Jul 16, 2018 at 03:17:57PM -0600, Alex Williamson wrote:
> > static bool vfio_pci_nointx(struct pci_dev *pdev)
> > {
> > + /*
> > +* Per PCI, no VF's should have INTx
> > +* Simply disable it here
> > +*/
> > + if (pdev->is_virtfn)
> > + return true;
> >
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
> >
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
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
>
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 cont
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));
> >>+ }
> >>+
> >>+ p
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
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
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:
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 conte
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:
> >
101 - 148 of 148 matches
Mail list logo
