> On Mar 16, 2021, at 8:16 PM, Longpeng (Mike, Cloud Infrastructure Service
> Product Dept.) wrote:
>
> Hi guys,
>
> We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
> situation, it would cause DMA fails or get wrong data.
>
> The reproducer (based on Alex's vfio
Hi Longpeng,
On 3/17/21 11:16 AM, Longpeng (Mike, Cloud Infrastructure Service
Product Dept.) wrote:
Hi guys,
We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
situation, it would cause DMA fails or get wrong data.
The reproducer (based on Alex's vfio testsuite[1]) is
Hi guys,
We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
situation, it would cause DMA fails or get wrong data.
The reproducer (based on Alex's vfio testsuite[1]) is in attachment, it can
reproduce the problem with high probability (~50%).
The machine we used is:
On 21-03-16 19:39:47, Keqian Zhu wrote:
> Hi Yi,
>
> On 2021/3/16 17:17, Yi Sun wrote:
> > On 21-03-10 17:06:07, Keqian Zhu wrote:
> >> From: jiangkunkun
> >>
> >> Block descriptor is not a proper granule for dirty log tracking.
> >> Take an extreme example, if DMA writes one byte, under 1G
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
[
On Mon, Mar 01, 2021 at 08:44:25AM +0100, Christoph Hellwig wrote:
> Move the code to find and validate the original buffer address and size
> from the callers into swiotlb_bounce. This means a tiny bit of extra
> work in the swiotlb_map path, but avoids code duplication and a leads to
> a better
On Mon, Mar 01, 2021 at 08:44:24AM +0100, Christoph Hellwig wrote:
> Now that swiotlb remembers the allocation size there is no need to pass
> it back to swiotlb_tbl_unmap_single.
Reviewed-by: Konrad Rzeszutek Wilk
___
iommu mailing list
16.03.2021 14:16, Thierry Reding пишет:
>> +seq_puts(s, "}\n");
>> +seq_printf(s, "Total PDE count: %u\n", pde_count);
>> +seq_printf(s, "Total PTE count: %llu\n", pte_count);
> Some of the above looks like it wouldn't be very easily consumed by
> scripts. Is that something we want to
15.03.2021 23:36, Nicolin Chen пишет:
> +static int tegra_smmu_mappings_show(struct seq_file *s, void *data)
> +{
> + struct tegra_smmu_group_debug *group_debug = s->private;
> + const struct tegra_smmu_swgroup *group;
> + struct tegra_smmu_as *as;
> + struct tegra_smmu *smmu;
> +
15.03.2021 23:36, Nicolin Chen пишет:
> +static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int
> pt_index)
> +{
> + return ((dma_addr_t)pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT |
> +((dma_addr_t)pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT;
> +}
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(): parse the VIOT table, build a list of endpoints
and vIOMMUs.
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
themselves.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
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.
The Virtual I/O Translation table (VIOT) describes the topology of
Just here for reference, don't merge!
The actual commits will be pulled from the next ACPICA release.
I squashed the three relevant commits:
ACPICA commit fc4e33319c1ee08f20f5c44853dd8426643f6dfd
ACPICA commit 2197e354fb5dcafaddd2016ffeb0620e5bc3d5e2
ACPICA commit
> Hi Krishna,
> On 3/15/21 7:04 PM, Krishna Reddy wrote:
> > Tested-by: Krishna Reddy
> >
> >> 1) pass the guest stage 1 configuration
> >
> > Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM
> along with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and
> QEMU
On Tue, Mar 16, 2021 at 10:04 AM Rob Clark wrote:
>
> On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote:
> >
> > On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote:
> > >
> > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > > > On 2021-02-01 23:50, Jordan Crouse wrote:
> > >
On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote:
>
> On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote:
> >
> > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > > On 2021-02-01 23:50, Jordan Crouse wrote:
> > > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> >
Remove the now unused iommu attr infrastructure.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/iommu.c | 26 --
include/linux/iommu.h | 36
2 files changed, 62 deletions(-)
diff --git a/drivers/iommu/iommu.c
Use an explicit set_pgtable_quirks method instead that just passes
the actual quirk bitmask instead.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 +-
drivers/iommu/arm/arm-smmu/arm-smmu.c | 64 +
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure that the iommu.strict parameter also works for the AMD and
Intel IOMMU drivers on x86. As those default to lazy
Don't obsfucate the trivial bit flag check.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/iommu.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 58d1d11a8d5c10..052cef11ae30df 100644
---
Use an explicit enable_nesting method instead.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 43 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 30 +++---
drivers/iommu/intel/iommu.c | 31
The geometry information can be trivially queried from the iommu_domain
struture.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/iommu.c | 20 +++-
drivers/vfio/vfio_iommu_type1.c | 26 --
drivers/vhost/vdpa.c|
DOMAIN_ATTR_PAGING is never used.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/iommu.c | 5 -
include/linux/iommu.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b212bf0261820b..9a4cda390993e6 100644
---
The snoop_id is always set to ~(u32)0.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 5 ++---
drivers/iommu/fsl_pamu_domain.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c
Instead of a separate call to enable all devices from the list, just
enablde the liodn one the device is attached to the iommu domain.
This also remove the DOMAIN_ATTR_FSL_PAMU_ENABLE iommu_attr.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 47
No good reason to split this functionality over two functions.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 59 +++--
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c
On 2021-03-16 2:00 a.m., Christoph Hellwig wrote:
> On Thu, Mar 11, 2021 at 04:31:39PM -0700, Logan Gunthorpe wrote:
>> Create a specific error code for when P2PDMA pages are passed to a block
>> devices that cannot map them (due to no IOMMU support or ACS protections).
>>
>> This makes request
Merge the two fuctions that configure the ppaace into a single coherent
function. I somehow doubt we need the two pamu_config_ppaace calls,
but keep the existing behavior just to be on the safe side.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 65
Add a fsl_pamu_configure_l1_stash API that qman_portal can call directly
instead of indirecting through the iommu attr API.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
arch/powerpc/include/asm/fsl_pamu_stash.h | 12 +++-
drivers/iommu/fsl_pamu_domain.c | 16
The only thing that fsl_pamu_window_enable does for the current caller
is to fill in the prot value in the only dma_window structure, and to
propagate a few values from the iommu_domain_geometry struture into the
dma_window. Remove the dma_window entirely, hardcode the prot value and
otherwise
On 2021-03-16 1:58 a.m., Christoph Hellwig wrote:
> On Fri, Mar 12, 2021 at 11:27:46AM -0700, Logan Gunthorpe wrote:
>> So then we reject the patches that make that change. Seems like an odd
>> argument to say that we can't do something that won't cause problems
>> because someone might use it
The only domains allocated forces use of a single window. Remove all
the code related to multiple window support, as well as the need for
qman_portal to force a single window.
Remove the now unused DOMAIN_ATTR_WINDOWS iommu_attr.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
Keep the functionality to allocate the domain together.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 34 ++---
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c
The default geometry is the same as the one set by qman_port given
that FSL_PAMU depends on having 64-bit physical and thus DMA addresses.
Remove the support to update the geometry and remove the now pointless
geom_size field.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
None of the values returned by this function are ever queried. Also
remove the DOMAIN_ATTR_FSL_PAMUV1 enum value that is not otherwise used.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 30 --
include/linux/iommu.h
domain_window_disable is wired up by fsl_pamu, but never actually called.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 48 -
include/linux/iommu.h | 2 --
2 files changed, 50 deletions(-)
diff --git
Hi all,
there are a bunch of IOMMU APIs that are entirely unused, or only used as
a private communication channel between the FSL PAMU driver and it's only
consumer, the qbman portal driver.
So this series drops a huge chunk of entirely unused FSL PAMU
functionality, then drops all kinds of
On Tue, Mar 16, 2021 at 09:36:02PM +0800, Huang Rui wrote:
> Thanks for the comments. Could you please elaborate this?
>
> Do you mean while amd_iommu=off, we won't prepare the IVRS, and even
> needn't get all ACPI talbes. Because they are never be used and the next
> state will always goes into
On Tue, Mar 16, 2021 at 09:16:34PM +0800, Joerg Roedel wrote:
> Hi Huang,
>
> On Thu, Mar 11, 2021 at 10:28:07PM +0800, Huang Rui wrote:
> > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> > index f0adbc48fd17..a08e885403b7 100644
> > --- a/drivers/iommu/amd/iommu.c
> > +++
Hi Huang,
On Thu, Mar 11, 2021 at 10:28:07PM +0800, Huang Rui wrote:
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index f0adbc48fd17..a08e885403b7 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3862,7 +3862,7 @@ static int
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the author if
Hi Yi,
On 2021/3/16 17:17, Yi Sun wrote:
> On 21-03-10 17:06:07, Keqian Zhu wrote:
>> From: jiangkunkun
>>
>> Block descriptor is not a proper granule for dirty log tracking.
>> Take an extreme example, if DMA writes one byte, under 1G mapping,
>> the dirty amount reported to userspace is 1G,
On Mon, Mar 15, 2021 at 01:36:31PM -0700, Nicolin Chen wrote:
> This patch dumps all active mapping entries from pagetable
> to a debugfs directory named "mappings".
>
> Attaching an example:
>
> SWGROUP: hc
> ASID: 0
> reg: 0x250
> PTB_ASID: 0xe0080004
> as->pd_dma: 0x80004000
> {
>
On 21-03-10 17:06:07, Keqian Zhu wrote:
> From: jiangkunkun
>
> Block descriptor is not a proper granule for dirty log tracking.
> Take an extreme example, if DMA writes one byte, under 1G mapping,
> the dirty amount reported to userspace is 1G, but under 4K mapping,
> the dirty amount is just
Hi Krishna,
On 3/15/21 7:04 PM, Krishna Reddy wrote:
> Tested-by: Krishna Reddy
>
>> 1) pass the guest stage 1 configuration
>
> Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
> with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch
>
On Thu, Mar 11, 2021 at 04:31:37PM -0700, Logan Gunthorpe wrote:
> +int dma_pci_p2pdma_supported(struct device *dev)
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> +
> + return !ops || ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED;
> +}
> +EXPORT_SYMBOL(dma_pci_p2pdma_supported);
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
> DMA map functions to determine how to map a given p2pdma page.
>
> pci_p2pdma_bus_offset() is also added to allow callers to get the bus
> offset if they need
On Thu, Mar 11, 2021 at 04:31:36PM -0700, Logan Gunthorpe wrote:
> for_each_sg(sgl, sg, nents, i) {
> + if (is_pci_p2pdma_page(sg_page(sg))) {
> + if (sg_page(sg)->pgmap != pgmap) {
> + pgmap = sg_page(sg)->pgmap;
> +
On Thu, Mar 11, 2021 at 04:31:39PM -0700, Logan Gunthorpe wrote:
> Create a specific error code for when P2PDMA pages are passed to a block
> devices that cannot map them (due to no IOMMU support or ACS protections).
>
> This makes request errors in these cases more informative of as to what
>
On Mon, Mar 15, 2021 at 10:33:13AM -0600, Logan Gunthorpe wrote:
> >> + return !ops || ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED;
> >
> > Is this logic correct? I would have expected.
> >
> > return (ops && ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED);
>
>
> If ops is NULL then the operations
On Fri, Mar 12, 2021 at 11:27:46AM -0700, Logan Gunthorpe wrote:
> So then we reject the patches that make that change. Seems like an odd
> argument to say that we can't do something that won't cause problems
> because someone might use it as an example and do something that will
> cause problems.
On Fri, Mar 12, 2021 at 06:11:17PM +, Robin Murphy wrote:
> Sure, that's how things stand immediately after this patch. But then
> someone comes along with the perfectly reasonable argument for returning
> more expressive error information for regular mapping failures as well
> (because
53 matches
Mail list logo
