When the Intel IOMMU is operating in the scalable mode, some information
from the root and context table may be used to tag entries in the PASID
cache. Software should invalidate the PASID-cache when changing root or
context table entries.
Suggested-by: Ashok Raj
Fixes: 7373a8cc38197 ("iommu/vt-d
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. Clear the SRE (Supervisor Request Enable) field in the
pasid tab
Hi Joerg,
This series includes some misc fixes for the VT-d iommu driver. Please
help to review and merge.
Best regards,
baolu
Change log:
v1->v2:
- v1:
https://lore.kernel.org/linux-iommu/20210225062654.2864322-1-baolu...@linux.intel.com/
- [PATCH 2/5] iommu/vt-d: Remove WO permissions on
When a present pasid entry is disassembled, all kinds of pasid related
caches need to be flushed. But when a pasid entry is not being used
(PRESENT bit not set), we don't need to do this. Check the PRESENT bit
in intel_pasid_tear_down_entry() and avoid flushing caches if it's not
set.
Signed-off-b
When the first level page table is used for IOVA translation, it only
supports Read-Only and Read-Write permissions. The Write-Only permission
is not supported as the PRESENT bit (implying Read permission) should
always set. When using second level, we still give separate permissions
that allows Wr
The Address field of the Page Request Descriptor only keeps bit [63:12]
of the offending address. Convert it to a full address before reporting
it to device drivers.
Fixes: eb8d93ea3c1d3 ("iommu/vt-d: Report page request faults for guest SVA")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.
The VT-d specification (section 7.6) requires that the value in the
Private Data field of a Page Group Response Descriptor must match
the value in the Private Data field of the respective Page Request
Descriptor.
The private data field of a page group response descriptor is set then
immediately cl
The pasid_lock is used to synchronize different threads from modifying a
same pasid directory entry at the same time. It causes below lockdep splat.
[ 83.296538]
[ 83.296538] WARNING: possible irq lock inversion dependency detected
[ 8
On Fri, 19 Mar 2021, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 19, 2021 at 02:07:31PM +0100, Christoph Hellwig wrote:
> > On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
> > > #ifdef CONFIG_ARM_LPAE
> > > + if (swiotlb_force == SWIOTLB_FORCE ||
> > > + max_pfn > arm_dma_pfn_
The pull request you sent on Fri, 19 Mar 2021 12:15:05 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.12-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/65a103747104368cb1ba6f097dcc3f85b1dcf86b
Thank you!
--
Deet-doot
On Fri, Mar 19, 2021 at 02:07:31PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
> > #ifdef CONFIG_ARM_LPAE
> > + if (swiotlb_force == SWIOTLB_FORCE ||
> > + max_pfn > arm_dma_pfn_limit)
>
> Does arm_dma_pfn_limit do the right thing ev
On 2021-03-19 16:58, John Garry wrote:
On 19/03/2021 16:13, Robin Murphy wrote:
On 2021-03-19 13:25, John Garry wrote:
Move the IOVA size power-of-2 rcache roundup into the IOVA allocator.
This is to eventually make it possible to be able to configure the upper
limit of the IOVA rcache range.
Hi Jason,
On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> > >
On 19/03/2021 17:00, Robin Murphy wrote:
On 2021-03-19 13:25, John Garry wrote:
Add a function to allow the max size which we want to optimise DMA
mappings
for.
It seems neat in theory - particularly for packet-based interfaces that
might have a known fixed size of data unit that they're wor
On 3/19/2021 6:07 AM, Christoph Hellwig wrote:
> On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
>> #ifdef CONFIG_ARM_LPAE
>> +if (swiotlb_force == SWIOTLB_FORCE ||
>> +max_pfn > arm_dma_pfn_limit)
>
> Does arm_dma_pfn_limit do the right thing even with the weirde
Hi Jean,
On 3/2/21 10:26 AM, Jean-Philippe Brucker wrote:
> The SMMU provides a Stall model for handling page faults in platform
> devices. It is similar to PCIe PRI, but doesn't require devices to have
> their own translation cache. Instead, faulting transactions are parked
> and the OS is given
Hi Chenxiang,
On 3/4/21 8:55 AM, chenxiang (M) wrote:
> Hi Eric,
>
>
> 在 2021/2/24 4:56, Eric Auger 写道:
>> Implement domain-selective, pasid selective and page-selective
>> IOTLB invalidations.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v13 -> v14:
>> - Add domain invalidation
>> - do glob
On 19/03/2021 16:25, Robin Murphy wrote:
On 2021-03-19 13:25, John Garry wrote:
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the
Hi Jean-Philippe,
On Fri, 19 Mar 2021 10:58:41 +0100, Jean-Philippe Brucker
wrote:
> > Slightly off the title. As we are moving to use cgroup to limit PASID
> > allocations, it would be much simpler if we enforce on the current
> > task.
>
> Yes I think we should do that. Is there a problem w
On 2021-03-19 13:25, John Garry wrote:
Add a function to allow the max size which we want to optimise DMA mappings
for.
It seems neat in theory - particularly for packet-based interfaces that
might have a known fixed size of data unit that they're working on at
any given time - but aren't the
On 19/03/2021 16:13, Robin Murphy wrote:
On 2021-03-19 13:25, John Garry wrote:
Move the IOVA size power-of-2 rcache roundup into the IOVA allocator.
This is to eventually make it possible to be able to configure the upper
limit of the IOVA rcache range.
Signed-off-by: John Garry
---
driver
On 2021-03-19 13:25, John Garry wrote:
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a
On 2021-03-19 13:25, John Garry wrote:
Move the IOVA size power-of-2 rcache roundup into the IOVA allocator.
This is to eventually make it possible to be able to configure the upper
limit of the IOVA rcache range.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 8 --
drivers/
On 19/03/2021 13:40, Christoph Hellwig wrote:
On Fri, Mar 19, 2021 at 09:25:42PM +0800, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This is much m
On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> >
> > > Although there is no use for it at the moment (only two upstream users and
> +int iommu_device_register(struct iommu_device *iommu, const struct iommu_ops
> *ops,
It would be nice to avoid the pointlessly overlong line here.
> + struct device *hwdev)
> {
> + iommu->ops = ops;
> + if (hwdev)
> + iommu->fwnode = hwdev->fwnode;
On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
>
> > Although there is no use for it at the moment (only two upstream users and
> > it looks like amdkfd always uses current too), I quite like the
> > client-
On Fri, Mar 19, 2021 at 09:25:42PM +0800, John Garry wrote:
> For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
> exceeds the IOVA rcache upper limit (meaning that they are not cached),
> performance can be reduced.
>
> This is much more pronounced from commit 4e89dce7252
On Fri, Mar 19, 2021 at 12:52:01PM +, Robin Murphy wrote:
> It happens that the 3 drivers which first supported being modular are
> also ones which play games with their pgsize_bitmap, so have non-const
> iommu_ops where dynamically setting the owner manages to work out OK.
> However, it's less
Add a function to allow the max size which we want to optimise DMA mappings
for.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 2 +-
include/linux/dma-map-ops.h | 1 +
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 11 +++
4 files changed, 18 insert
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a significant effect on performance, more s
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This is much more pronounced from commit 4e89dce72521 ("iommu/iova: Retry
from last rb tree node if iova search fails"), a
Add a function which allows the max optimised IOMMU DMA size to be set.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 15b7270a5c2a..a5dfbd6c0496 100644
--- a
For IOMMU strict mode, more than doubles throughput in some scenarios.
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 4580e081e489..2
Move the IOVA size power-of-2 rcache roundup into the IOVA allocator.
This is to eventually make it possible to be able to configure the upper
limit of the IOVA rcache range.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 8 --
drivers/iommu/iova.c | 51
To help learn if the domain has regular IOVA nodes, add a count of
reserved nodes, calculated at init time.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 2 ++
include/linux/iova.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index e62e
Hi Krishna,
On 3/18/21 1:16 AM, Krishna Reddy wrote:
> Tested-by: Krishna Reddy
>
> Validated nested translations with NVMe PCI device assigned to Guest VM.
> Tested with both v12 and v13 of Jean-Philippe's patches as base.
Many thanks for that.
>
>> This is based on Jean-Philippe's
>> [PATCH
Hi Keqian,
On 3/2/21 9:35 AM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2021/2/24 4:56, Eric Auger wrote:
>> On attach_pasid_table() we program STE S1 related info set
>> by the guest into the actual physical STEs. At minimum
>> we need to program the context descriptor GPA and compute
>> whether the s
Hi Christoph
On Fri, Mar 19, 2021 at 2:10 PM Christoph Hellwig wrote:
>
> On Fri, Mar 19, 2021 at 02:05:21PM +0100, Ricardo Ribalda wrote:
> > > + uvc_urb->sgt,
> > > + uvc_stream_dir(uvc_urb->stream));
> > > + return usb_s
On Fri, Mar 19, 2021 at 02:05:21PM +0100, Ricardo Ribalda wrote:
> > + uvc_urb->sgt,
> > + uvc_stream_dir(uvc_urb->stream));
> > + return usb_submit_urb(uvc_urb->urb, GFP_KERNEL);
> > +}
>
> We should have mem_flags instead
On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
> #ifdef CONFIG_ARM_LPAE
> + if (swiotlb_force == SWIOTLB_FORCE ||
> + max_pfn > arm_dma_pfn_limit)
Does arm_dma_pfn_limit do the right thing even with the weirdest
remapping ranges? Maybe a commen here would be useful
Hi Christoph
While backporting the patch I realised of a bug.
On Sat, Mar 13, 2021 at 12:55 AM Ricardo Ribalda wrote:
>
> On architectures where there is no coherent caching such as ARM use the
> dma_alloc_noncontiguous API and handle manually the cache flushing using
> dma_sync_sgtable().
>
> I
It happens that the 3 drivers which first supported being modular are
also ones which play games with their pgsize_bitmap, so have non-const
iommu_ops where dynamically setting the owner manages to work out OK.
However, it's less than ideal to force that upon all drivers which want
to be modular -
Rather than have separate opaque setter functions that are easy to
overlook and lead to repetitive boilerplate in drivers, let's pass the
relevant initialisation parameters directly to iommu_device_register().
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/init.c| 3 +--
On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> Although there is no use for it at the moment (only two upstream users and
> it looks like amdkfd always uses current too), I quite like the
> client-server model where the privileged process does bind() and programs
> the ha
On Fri, Mar 19, 2021 at 09:57:50AM +, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/iommu/sprd-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
>
>
Hi Eric,
On Fri, Mar 19, 2021 at 11:58:49AM +0100, Auger Eric wrote:
> Hi Jean,
>
> On 3/16/21 8:16 PM, Jean-Philippe Brucker wrote:
> > Add a driver for the ACPI VIOT table, which enables virtio-iommu on
> > non-devicetree platforms, including x86. This series depends on the
> > ACPICA changes o
Hi Linus,
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.12-rc3
for you to fetch changes up to
On 2021-03-19 01:02, chenxiang (M) wrote:
Hi,
在 2021/3/18 19:01, Robin Murphy 写道:
On 2021-03-18 09:55, chenxiang (M) wrote:
Hi will,
在 2021/3/18 17:34, Will Deacon 写道:
On Thu, Mar 18, 2021 at 11:21:24AM +0800, chenxiang wrote:
From: Xiang Chen
Fix a type "SAC" to "DAC" in the comment of
Hi Jean,
On 3/16/21 8:16 PM, Jean-Philippe Brucker wrote:
> Add a driver for the ACPI VIOT table, which enables virtio-iommu on
> non-devicetree platforms, including x86. This series depends on the
> ACPICA changes of patch 1, which will be included in next release [1]
> and pulled into Linux.
>
Hi Jean,
On 3/16/21 8:16 PM, Jean-Philippe Brucker wrote:
> The ACPI Virtual I/O Translation Table describes topology of
> para-virtual platforms. For now it describes the relation between
> virtio-iommu and the endpoints it manages. Supporting that requires
> three steps:
>
> (1) acpi_viot_init(
Hi Jacob,
On Thu, Mar 18, 2021 at 05:22:34PM -0700, Jacob Pan wrote:
> Hi Jean,
>
> Slightly off the title. As we are moving to use cgroup to limit PASID
> allocations, it would be much simpler if we enforce on the current task.
Yes I think we should do that. Is there a problem with charging the
From: Colin Ian King
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/iommu/sprd-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
index 7100ed17dcce..e1dc2f7d56
Hi Baolu,
On Fri, Mar 19, 2021 at 09:02:34AM +0800, Lu Baolu wrote:
> This code modifies the pasid directory entry. The pasid directory
> entries are allocated on demand and will never be freed.
>
> > What you need to do here is to retry the whole path by adding a goto
> > to before the first ge
54 matches
Mail list logo
