Hi Jason,
On 12/8/21 7:31 PM, Jason Gunthorpe wrote:
> On Wed, Dec 08, 2021 at 05:20:39PM +, Jean-Philippe Brucker wrote:
>> On Wed, Dec 08, 2021 at 08:56:16AM -0400, Jason Gunthorpe wrote:
>>> From a progress perspective I would like to start with simple 'page
>>> tables in userspace', ie no
This patch dumps all active mapping entries from pagetable to a
debugfs directory named "mappings".
Part of this patch for listing all swgroup names in a group_soc
is provided by Dmitry Osipenko
Attaching an example:
[SWGROUP: xusb_host] [as: (id: 5), (attr: R|W|-), (pd_dma: 0x80005000)
This patch changes in struct tegra_smmu_group to use swgrp
pointer instead of swgroup, as a preparational change for
the "mappings" debugfs feature.
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 12
1 file changed, 8 insertions(+), 4 deletion
The existing function tegra_smmu_find_group really finds group->soc
pointer, so naming it "find_group" might not be clear by looking at
it alone. This patch renames it to tegra_smmu_group_soc in order to
disambiguate the use of "group" in this driver.
Signed-off-by: Nicolin Chen
---
drivers/iomm
There are both tegra_smmu_swgroup and tegra_smmu_group structs
using "group" for their pointer instances. This gets confusing
to read the driver sometimes.
So this patch renames "group" of struct tegra_smmu_swgroup to
"swgrp" as a cleanup. Also renames its "find" function.
Note that we already ha
This could ease driver to access corresponding as pointer
when having tegra_smmu_group pointer only, which can help
new mappings debugfs nodes.
Also moving tegra_smmu_find_group_soc() upward, for using
it in new tegra_smmu_attach_as(); and it's better to have
all tegra_smmu_find_* functions togeth
This series of patches adds a new mappings node to debugfs for
tegra-smmu driver. The first five patches are all preparational
changes for PATCH-6, based on Thierry's review feedback against
v5.
Changelog
v8:
* No changes for PATCH 1-4
* PATCH-5:
* * bypassed "group->as == as" to fix KMSG bug r
There are a few structs using "group" for their pointer instances.
This gets confusing sometimes. The instance of struct iommu_group
is used in local function with an alias "grp", which can separate
it from others.
So this patch simply renames "group" to "grp" as a cleanup.
Acked-by: Thierry Redi
On Thu, 2021-12-09 at 00:04 +, Sean Christopherson wrote:
> On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> > Host crash while running 32 bit VM and another 32 bit VM nested in it:
> >
> > [ 751.182290] BUG: kernel NULL pointer dereference, address:
> > 0025
> > [ 751.198234] #PF:
On Wed, 2021-12-08 at 23:43 +, Sean Christopherson wrote:
> On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> > > KVM: SVM: Remove unnecessary APICv/AVIC update in vCPU unblocking path
>
> ...
>
> > Probably just luck (can't reproduce this anymore) but
> > while running some kvm unit tests with
On Thu, 2021-12-09 at 01:37 +, Sean Christopherson wrote:
> On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> > On Thu, 2021-12-09 at 01:00 +0200, Maxim Levitsky wrote:
> > > Probably just luck (can't reproduce this anymore) but
> > > while running some kvm unit tests with this patch series (and fe
> From: Jason Gunthorpe
> Sent: Saturday, December 4, 2021 12:41 AM
>
> > Or has each queue and controlblock and whatever access to a shared large
> > array where the messages are stored and the indices are handed out to
> > the queues and controlblocks?
>
> > If each of them have their own smal
On Thu, Dec 9, 2021 at 1:41 PM Tian, Kevin wrote:
>
> > From: Jason Gunthorpe
> > Sent: Thursday, December 2, 2021 9:55 PM
> >
> > Further, there is no reason why IMS should be reserved exclusively for
> > VFIO!
>
> This is correct. Just as what you agreed with Thomas, the only difference
> betwe
> From: Jason Gunthorpe
> Sent: Thursday, December 2, 2021 9:55 PM
>
> Further, there is no reason why IMS should be reserved exclusively for
> VFIO!
This is correct. Just as what you agreed with Thomas, the only difference
between IMS and MSI is on where the messages are stored. Physically
it
> From: Thomas Gleixner
> Sent: Thursday, December 2, 2021 5:45 AM
>
> On Wed, Dec 01 2021 at 14:21, Dave Jiang wrote:
> > On 12/1/2021 1:25 PM, Thomas Gleixner wrote:
> >>> The hardware implementation does not have enough MSIX vectors for
> >>> guests. There are only 9 MSIX vectors total (8 for
> From: Tian, Kevin
> Sent: Thursday, December 9, 2021 10:58 AM
>
> For ARM it's SMMU's PASID table format. There is no step-2 since PASID
> is already within the address space covered by the user PASID table.
>
One correction here. 'no step-2' is definitely wrong here as it means
more than user
> From: Jason Gunthorpe
> Sent: Wednesday, December 8, 2021 8:56 PM
>
> On Wed, Dec 08, 2021 at 08:33:33AM +0100, Eric Auger wrote:
> > Hi Baolu,
> >
> > On 12/8/21 3:44 AM, Lu Baolu wrote:
> > > Hi Eric,
> > >
> > > On 12/7/21 6:22 PM, Eric Auger wrote:
> > >> On 12/6/21 11:48 AM, Joerg Roedel w
> From: Jason Gunthorpe
> Sent: Thursday, December 9, 2021 2:31 AM
>
> On Wed, Dec 08, 2021 at 05:20:39PM +, Jean-Philippe Brucker wrote:
> > On Wed, Dec 08, 2021 at 08:56:16AM -0400, Jason Gunthorpe wrote:
> > > From a progress perspective I would like to start with simple 'page
> > > tables
On 12/9/21 3:16 AM, Jacob Pan wrote:
Hi Jason,
On Wed, 8 Dec 2021 09:22:55 -0400, Jason Gunthorpe wrote:
On Tue, Dec 07, 2021 at 05:47:13AM -0800, Jacob Pan wrote:
Between DMA requests with and without PASID (legacy), DMA mapping APIs
are used indiscriminately on a device. Therefore, we shou
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 PASID even there's no system
IOMMU
or the system IOMMU is disabled?
Good point.
If IOMMU is not enabled, device cannot issue DMA requests with PASID. This
AP
> From: Jiang, Dave
> Sent: Thursday, December 9, 2021 8:12 AM
> >>>
> >> Do you mean wq completion record address? It is already using DMA API.
> >>wq->compls = dma_alloc_coherent(dev, wq->compls_size,
> >> &wq->compls_addr, GFP_KERNEL);
> >>desc->compl_dma = wq->compls_addr + idxd->data-
> From: Jacob Pan
> Sent: Thursday, December 9, 2021 2:50 AM
>
> > Can a device issue DMA requests with PASID even there's no system
> IOMMU
> > or the system IOMMU is disabled?
> >
> Good point.
> If IOMMU is not enabled, device cannot issue DMA requests with PASID. This
> API will not be availa
> From: Jason Gunthorpe
> Sent: Thursday, December 9, 2021 1:51 AM
>
> > > > + /*
> > > > +* Try to enable both in-kernel and user DMA request with PASID.
> > > > +* PASID is supported unless both user and kernel PASID are
> > > > +* supported. Do not fail probe here
On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> On Thu, 2021-12-09 at 01:00 +0200, Maxim Levitsky wrote:
> > Probably just luck (can't reproduce this anymore) but
> > while running some kvm unit tests with this patch series (and few my patches
> > for AVIC co-existance which shouldn't affect this) I
On 12/7/21 9:16 PM, Jason Gunthorpe wrote:
On Tue, Dec 07, 2021 at 10:57:25AM +0800, Lu Baolu wrote:
On 12/6/21 11:06 PM, Jason Gunthorpe wrote:
On Mon, Dec 06, 2021 at 06:36:27AM -0800, Christoph Hellwig wrote:
I really hate the amount of boilerplate code that having this in each
bus type cau
On 12/8/2021 4:39 PM, Jason Gunthorpe wrote:
On Wed, Dec 08, 2021 at 01:59:45PM -0800, Jacob Pan wrote:
Hi Jason,
On Wed, 8 Dec 2021 16:30:22 -0400, Jason Gunthorpe wrote:
On Wed, Dec 08, 2021 at 11:55:16AM -0800, Jacob Pan wrote:
Hi Jason,
On Wed, 8 Dec 2021 09:13:58 -0400, Jason Guntho
On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> Host crash while running 32 bit VM and another 32 bit VM nested in it:
>
> [ 751.182290] BUG: kernel NULL pointer dereference, address: 0025
> [ 751.198234] #PF: supervisor read access in kernel mode
> [ 751.209982] #PF: error_code(0x000
On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> Also got this while trying a VM with passed through device:
>
> [mlevitsk@amdlaptop ~]$[ 34.926140] usb 5-3: reset full-speed USB device
> number 3 using xhci_hcd
> [ 42.583661] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some
> data m
On Thu, Dec 09, 2021, Maxim Levitsky wrote:
> > KVM: SVM: Remove unnecessary APICv/AVIC update in vCPU unblocking path
...
> Probably just luck (can't reproduce this anymore) but
> while running some kvm unit tests with this patch series (and few my patches
> for AVIC co-existance which shouldn
On Wed, Dec 08, 2021 at 01:59:45PM -0800, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 8 Dec 2021 16:30:22 -0400, Jason Gunthorpe wrote:
>
> > On Wed, Dec 08, 2021 at 11:55:16AM -0800, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe
> > > wrote:
> >
On Thu, 2021-12-09 at 01:16 +0200, Maxim Levitsky wrote:
> On Thu, 2021-12-09 at 01:00 +0200, Maxim Levitsky wrote:
> > On Wed, 2021-12-08 at 01:52 +, Sean Christopherson wrote:
> > > Overhaul and cleanup APIC virtualization (Posted Interrupts on Intel VMX,
> > > AVIC on AMD SVM) to streamline
On Thu, 2021-12-09 at 01:00 +0200, Maxim Levitsky wrote:
> On Wed, 2021-12-08 at 01:52 +, Sean Christopherson wrote:
> > Overhaul and cleanup APIC virtualization (Posted Interrupts on Intel VMX,
> > AVIC on AMD SVM) to streamline things as much as possible, remove a bunch
> > of cruft, and docu
On Wed, 2021-12-08 at 01:52 +, Sean Christopherson wrote:
> Overhaul and cleanup APIC virtualization (Posted Interrupts on Intel VMX,
> AVIC on AMD SVM) to streamline things as much as possible, remove a bunch
> of cruft, and document the lurking gotchas along the way.
>
> Patch 01 is a fix fr
Hi Jason,
On Wed, 8 Dec 2021 16:30:22 -0400, Jason Gunthorpe wrote:
> On Wed, Dec 08, 2021 at 11:55:16AM -0800, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe
> > wrote:
> > > > This patch utilizes iommu_enable_pasid_dma() to enable DSA to
> > > > pe
On Wed, Dec 08, 2021 at 07:09:37PM +0300, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
>
>
> 08.12.2021 11:47, Nicolin Chen пишет:
> > static void tegra_smmu_attach_as(struct tegra_smmu *smmu,
> >struct tegra_smmu_as *as,
> >
On Wed, Dec 08, 2021 at 11:55:16AM -0800, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe wrote:
>
> > > This patch utilizes iommu_enable_pasid_dma() to enable DSA to perform
> > > DMA requests with PASID under the same mapping managed by DMA mapping
> > > API
> -Original Message-
> From: Tianyu Lan
> Sent: Tuesday, December 7, 2021 2:56 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
> Hemminger ; wei@kernel.org; Dexuan Cui
> ;
> t...@linutronix.de; mi...@redhat.com; b...@alien8.de;
> dave.han...@linux.intel.com;
> x...@kernel.org;
Hi Jason,
On Wed, 8 Dec 2021 09:13:58 -0400, Jason Gunthorpe wrote:
> > This patch utilizes iommu_enable_pasid_dma() to enable DSA to perform
> > DMA requests with PASID under the same mapping managed by DMA mapping
> > API. In addition, SVA-related bits for kernel DMA are removed. As a
> > resu
Hi Jason,
On Wed, 8 Dec 2021 09:22:55 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 07, 2021 at 05:47:13AM -0800, Jacob Pan wrote:
> > Between DMA requests with and without PASID (legacy), DMA mapping APIs
> > are used indiscriminately on a device. Therefore, we should always match
> > the address
Hi Lu,
On Wed, 8 Dec 2021 10:31:36 +0800, Lu Baolu
wrote:
> Hi Jacob,
>
> On 12/7/21 9:47 PM, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some modern devices such as Intel Data Stre
On 2021-12-08 18:17, John Garry wrote:
Did you notice any performance change with this change?
Hi John:
Thanks for the tip. I wrote a test case today, and I found that the
performance did not go up but down.
I very quickly tested on a DMA mapping benchmark very similar to the
kernel DMA b
Hi Jacob,
I love your patch! Yet something to improve:
[auto build test ERROR on joro-iommu/next]
[also build test ERROR on vkoul-dmaengine/next linux/master linus/master
v5.16-rc4 next-20211208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Wed, Dec 08, 2021 at 05:20:39PM +, Jean-Philippe Brucker wrote:
> On Wed, Dec 08, 2021 at 08:56:16AM -0400, Jason Gunthorpe wrote:
> > From a progress perspective I would like to start with simple 'page
> > tables in userspace', ie no PASID in this step.
> >
> > 'page tables in userspace' m
Did you notice any performance change with this change?
Hi John:
Thanks for the tip. I wrote a test case today, and I found that the
performance did not go up but down.
I very quickly tested on a DMA mapping benchmark very similar to the
kernel DMA benchmark module - I got mixed results. F
Hi Jason,
Thanks for the quick review.
On Wed, 8 Dec 2021 09:10:38 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 07, 2021 at 05:47:10AM -0800, Jacob Pan wrote:
> > Modern accelerators such as Intel's Data Streaming Accelerator (DSA) can
> > perform DMA requests with PASID, which is a finer granul
On Wed, Dec 08 2021 at 11:53, Jason Gunthorpe wrote:
> On Mon, Dec 06, 2021 at 11:39:28PM +0100, Thomas Gleixner wrote:
>> static void xen_pv_teardown_msi_irqs(struct pci_dev *dev)
>> {
>> -struct msi_desc *msidesc = first_pci_msi_entry(dev);
>> -
>> -if (msidesc->pci.msi_attrib.is_msix)
On Wed, Dec 08, 2021 at 08:35:49AM -0700, Dave Jiang wrote:
>
> On 12/8/2021 6:13 AM, Jason Gunthorpe wrote:
> > On Tue, Dec 07, 2021 at 05:47:14AM -0800, Jacob Pan wrote:
> > > In-kernel DMA should be managed by DMA mapping API. The existing kernel
> > > PASID support is based on the SVA machiner
Hi Vinod,
On Wed, 8 Dec 2021 10:26:22 +0530, Vinod Koul wrote:
> Pls resend collecting acks. I dont have this in my queue
Will do. Sorry I missed the dmaengine list.
Thanks,
Jacob
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.
On Wed, Dec 08, 2021 at 08:56:16AM -0400, Jason Gunthorpe wrote:
> From a progress perspective I would like to start with simple 'page
> tables in userspace', ie no PASID in this step.
>
> 'page tables in userspace' means an iommufd ioctl to create an
> iommu_domain where the IOMMU HW is directly
08.12.2021 11:47, Nicolin Chen пишет:
> static void tegra_smmu_attach_as(struct tegra_smmu *smmu,
>struct tegra_smmu_as *as,
>unsigned int swgroup)
> @@ -517,6 +646,12 @@ static void tegra_smmu_attach_as(struct tegra_smmu *smmu,
>
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
> ---
> V2: Use the setter function
> ---
> drivers/pci/msi/msi.c |8
>
On Mon, Dec 06, 2021 at 11:39:33PM +0100, Thomas Gleixner wrote:
> @@ -209,10 +209,10 @@ static int setup_msi_msg_address(struct
> return -ENODEV;
> }
>
> - entry = first_pci_msi_entry(dev);
> + is_64bit = msi_device_has_property(&dev->dev, MSI_PROP_64BIT);
How about
On Mon, Dec 06, 2021 at 11:39:28PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> arch/x86/pci/xen.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
On Mon, Dec 06, 2021 at 11:39:34PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> arch/powerpc/platforms/pseries/msi.c |4 ++--
> 1 file changed, 2 insertions(+)
I've force pushed out the fixed version, thanks!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Dec 06, 2021 at 11:39:29PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
> ---
> arch/x86/kernel/apic/msi.c |5 +
> 1 file changed, 1 insertion(+), 4
Hi Christoph,
On 11.11.2021 07:50, Christoph Hellwig wrote:
> Add a helper to check if a potentially blocking operation should
> dip into the atomic pools.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Robin Murphy
> ---
> kernel/dma/direct.c | 18 --
> 1 file changed, 1
On Wed, Dec 08, 2021, Paolo Bonzini wrote:
> On 12/8/21 02:52, Sean Christopherson wrote:
> > + /*
> > +* Unload the AVIC when the vCPU is about to block,_before_ the vCPU
> > +* actually blocks. The vCPU needs to be marked IsRunning=0 before the
> > +* final pass over the vIRR via
On 12/8/2021 6:13 AM, Jason Gunthorpe wrote:
On Tue, Dec 07, 2021 at 05:47:14AM -0800, Jacob Pan wrote:
In-kernel DMA should be managed by DMA mapping API. The existing kernel
PASID support is based on the SVA machinery in SVA lib that is intended
for user process SVA. The binding between a ke
On Wed, Dec 8, 2021 at 3:37 PM Robin Murphy wrote:
>
> Jon,
>
> On 2021-12-08 13:26, Jon Nettleton wrote:
> [...]
> >>> Even marking them as IOMMU_READ/WRITE is as much of an assumption as
> >>> using IOMMU_MMIO or IOMMU_CACHE. It just seems IOMMU_MMIO is the most
> >>> popular since all the examp
On Wed, 2021-12-08 at 15:43 +0100, Paolo Bonzini wrote:
> On 12/8/21 02:52, Sean Christopherson wrote:
> > + /*
> > +* Unload the AVIC when the vCPU is about to block,_before_ the vCPU
> > +* actually blocks. The vCPU needs to be marked IsRunning=0 before the
> > +* final pass over
On 12/8/21 02:52, Sean Christopherson wrote:
Overhaul and cleanup APIC virtualization (Posted Interrupts on Intel VMX,
AVIC on AMD SVM) to streamline things as much as possible, remove a bunch
of cruft, and document the lurking gotchas along the way.
Patch 01 is a fix from Paolo that's already b
08.12.2021 11:47, Nicolin Chen пишет:
> + seq_printf(s, "\t\t%-14s | %-4s | %-10s%s | %-10s%s | %-11s\n",
> +"PTE RANGE", "ATTR",
> +"PHYS", sizeof(phys_addr_t) > 4 ? "" : "",
> +"IOVA", sizeof(dma_addr_t)
On 12/8/21 02:52, Sean Christopherson wrote:
+ /*
+* Unload the AVIC when the vCPU is about to block,_before_ the vCPU
+* actually blocks. The vCPU needs to be marked IsRunning=0 before the
+* final pass over the vIRR via kvm_vcpu_check_block(). Any IRQs that
+
Jon,
On 2021-12-08 13:26, Jon Nettleton wrote:
[...]
Even marking them as IOMMU_READ/WRITE is as much of an assumption as
using IOMMU_MMIO or IOMMU_CACHE. It just seems IOMMU_MMIO is the most
popular since all the examples use it for MSI doorbells in the
documentation.
We don't merge code base
Hi,
08.12.2021 11:47, Nicolin Chen пишет:
> This patch dumps all active mapping entries from pagetable to a
> debugfs directory named "mappings".
>
> Attaching an example:
>
> [SWGROUP: xusb_host] [as: (id: 5), (attr: R|W|-), (pd_dma:
> 0x80005000)]
> {
> [index: 1023] 0xf008004
On 2021/12/8 0:17, John Garry wrote:
>
>> +
>> return 0;
>> }
>
> Did you notice any performance change with this change?
Hi John:
Thanks for the tip. I wrote a test case today, and I found that the
performance did not go up but down. It's so weird. So I decided not to
change it, bec
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 07 December 2021 11:06
> To: Zhangfei Gao ; eric.auger@gmail.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu; j...@8bytes.org;
> w
On Wed, Dec 8, 2021 at 1:19 PM Lorenzo Pieralisi
wrote:
>
> On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote:
> > On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote:
> > >
> > > On 2021-10-09 08:06, Jon Nettleton wrote:
> > > [...]
> > > >>> + if (rmr->flags & IOMMU_RMR_R
On Tue, Dec 07, 2021 at 05:47:13AM -0800, Jacob Pan wrote:
> Between DMA requests with and without PASID (legacy), DMA mapping APIs
> are used indiscriminately on a device. Therefore, we should always match
> the addressing mode of the legacy DMA when enabling kernel PASID.
>
> This patch adds sup
On Tue, Dec 07, 2021 at 05:47:14AM -0800, Jacob Pan wrote:
> In-kernel DMA should be managed by DMA mapping API. The existing kernel
> PASID support is based on the SVA machinery in SVA lib that is intended
> for user process SVA. The binding between a kernel PASID and kernel
> mapping has many fla
On Tue, Dec 07, 2021 at 05:47:10AM -0800, Jacob Pan wrote:
> Modern accelerators such as Intel's Data Streaming Accelerator (DSA) can
> perform DMA requests with PASID, which is a finer granularity than the
> device's requester ID(RID). In fact, work submissions on DSA shared work
> queues require
On Wed, Dec 08, 2021 at 08:33:33AM +0100, Eric Auger wrote:
> Hi Baolu,
>
> On 12/8/21 3:44 AM, Lu Baolu wrote:
> > Hi Eric,
> >
> > On 12/7/21 6:22 PM, Eric Auger wrote:
> >> On 12/6/21 11:48 AM, Joerg Roedel wrote:
> >>> On Wed, Oct 27, 2021 at 12:44:20PM +0200, Eric Auger wrote:
> Signed-o
On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote:
> On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote:
> >
> > On 2021-10-09 08:06, Jon Nettleton wrote:
> > [...]
> > >>> + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
> > >>> + type = IOMMU_RESV_DIREC
From: Yong Wu
The tlb_flush_all touches the registers controlling tlb operations.
Protect it with the tlb_lock spinlock.
This also require the range_sync func to release that spinlock before
calling tlb_flush_all.
Signed-off-by: Yong Wu
[refactor commit log]
Signed-off-by: Dafna Hirschfeld
---
Often devices allocate DMA buffers before they do
runtime pm resume. This is the case for example with v4l2
devices where buffers are allocated during 'VIDIOC_REQBUFS`
and runtime resume happens later usually during 'VIDIOC_STREAMON'.
In such cases the partial tlb flush when allocating will fail
si
From: Yong Wu
Prepare for 2 HWs that sharing pgtable in different power-domains.
When there are 2 M4U HWs, it may has problem in the flush_range in which
we get the pm_status via the m4u dev, BUT that function don't reflect the
real power-domain status of the HW since there may be other HW also
From: Yong Wu
The tlb_sync_all is called from these three functions:
a) flush_iotlb_all: it will be called for each a iommu HW.
b) tlb_flush_range_sync: it already has for_each_m4u.
c) in irq: When IOMMU HW translation fault, Only need flush itself.
Thus, No need for_each_m4u in this tlb_sync_al
From: Yong Wu
To simplify the code, Remove the power status checking in the
tlb_flush_all, remove this:
if (pm_runtime_get_if_in_use(data->dev) <= 0)
continue;
The mtk_iommu_tlb_flush_all is called from
a) isr
b) tlb flush range fail case
c) iommu_create_device_direct_mappings
In
From: Sebastian Reichel
In case of v4l2_reqbufs() it is possible, that a TLB flush is done
without runtime PM being enabled. In that case the "Partial TLB flush
timed out, falling back to full flush" warning is printed.
Commit c0b57581b73b ("iommu/mediatek: Add power-domain operation")
introduce
On 08.12.21 11:50, Dafna Hirschfeld wrote:
On 07.12.21 10:31, Dafna Hirschfeld wrote:
On 27.11.21 04:46, Yong Wu wrote:
Hi Dafna,
Sorry for reply late.
On Mon, 2021-11-22 at 12:43 +0200, Dafna Hirschfeld wrote:
From: Yong Wu
Prepare for 2 HWs that sharing pgtable in different power-d
On 07.12.21 10:31, Dafna Hirschfeld wrote:
On 27.11.21 04:46, Yong Wu wrote:
Hi Dafna,
Sorry for reply late.
On Mon, 2021-11-22 at 12:43 +0200, Dafna Hirschfeld wrote:
From: Yong Wu
Prepare for 2 HWs that sharing pgtable in different power-domains.
When there are 2 M4U HWs, it may has
On 12/8/21 02:52, Sean Christopherson wrote:
Overhaul and cleanup APIC virtualization (Posted Interrupts on Intel VMX,
AVIC on AMD SVM) to streamline things as much as possible, remove a bunch
of cruft, and document the lurking gotchas along the way.
Patch 01 is a fix from Paolo that's already b
This series of patches adds a new mappings node to debugfs for
tegra-smmu driver. The first five patches are all preparational
changes for PATCH-6, based on Thierry's review feedback against
v5.
Changelog
v7:
* Added "Acked-by" from Thierry to PATCH1,4,5
* No other changes for PATCH1,3,4,5
* PA
There are a few structs using "group" for their pointer instances.
This gets confusing sometimes. The instance of struct iommu_group
is used in local function with an alias "grp", which can separate
it from others.
So this patch simply renames "group" to "grp" as a cleanup.
Acked-by: Thierry Redi
This patch dumps all active mapping entries from pagetable to a
debugfs directory named "mappings".
Attaching an example:
[SWGROUP: xusb_host] [as: (id: 5), (attr: R|W|-), (pd_dma: 0x80005000)]
{
[index: 1023] 0xf0080040 (count: 52)
{
PTE RANGE | ATTR
There are both tegra_smmu_swgroup and tegra_smmu_group structs
using "group" for their pointer instances. This gets confusing
to read the driver sometimes.
So this patch renames "group" of struct tegra_smmu_swgroup to
"swgrp" as a cleanup. Also renames its "find" function.
Note that we already ha
This patch changes in struct tegra_smmu_group to use swgrp
pointer instead of swgroup, as a preparational change for
the "mappings" debugfs feature.
Acked-by: Thierry Reding
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 12
1 file changed, 8 insertions(+), 4 deletion
The existing function tegra_smmu_find_group really finds group->soc
pointer, so naming it "find_group" might not be clear by looking at
it alone. This patch renames it to tegra_smmu_group_soc in order to
disambiguate the use of "group" in this driver.
Signed-off-by: Nicolin Chen
---
drivers/iomm
This could ease driver to access corresponding as pointer
when having tegra_smmu_group pointer only, which can help
new mappings debugfs nodes.
Also moving tegra_smmu_find_group_soc() upward, for using
it in new tegra_smmu_attach_as(); and it's better to have
all tegra_smmu_find_* functions togeth
90 matches
Mail list logo
