On Fri, Apr 29, 2022 at 09:48:38AM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 29, 2022 at 04:20:36PM +1000, David Gibson wrote:
>
> > > I think PPC and S390 are solving the same problem here. I think S390
> > > is going to go to a SW nested model where it has an iommu_domain
> > > controlled by
On Fri, Apr 29, 2022 at 09:50:30AM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 29, 2022 at 04:22:56PM +1000, David Gibson wrote:
> > On Fri, Apr 29, 2022 at 01:21:30AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 28, 2022 11:11 PM
> > > >
> > > >
> > > >
On Tue, 5 Apr 2022 15:32:50 +0100, Robin Murphy wrote:
> Defer the IOMMU domain setup until after successfully binding
> components, so we can figure out IOMMU support directly from the VOP
> devices themselves, rather than manually inferring it from the DT (which
> also fails to account for
Hi BaoLu,
On Sun, 1 May 2022 19:24:33 +0800, Lu Baolu
wrote:
> The IOMMU force snooping capability is not required to be consistent
> among all the IOMMUs anymore. Remove force snooping capability check
> in the IOMMU hot-add path and domain_update_iommu_snooping() becomes
> a dead code now.
>
Hi BaoLu,
On Sun, 1 May 2022 19:24:32 +0800, Lu Baolu
wrote:
> As domain->force_snooping only impacts the devices attached with the
> domain, there's no need to check against all IOMMU units. At the same
> time, for a brand new domain (hasn't been attached to any device), the
> force_snooping
On Mon, May 2, 2022 at 6:43 PM Christoph Hellwig wrote:
>
> virt_to_dma was only used by the now removed dmabounce code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
On Mon, May 02, 2022 at 12:11:07PM -0600, Alex Williamson wrote:
> On Fri, 29 Apr 2022 05:45:20 +
> "Tian, Kevin" wrote:
> > > From: Joao Martins
> > > 3) Unmapping an IOVA range while returning its dirty bit prior to
> > > unmap. This case is specific for non-nested vIOMMU case where an
>
On Fri, 29 Apr 2022 05:45:20 +
"Tian, Kevin" wrote:
> > From: Joao Martins
> > 3) Unmapping an IOVA range while returning its dirty bit prior to
> > unmap. This case is specific for non-nested vIOMMU case where an
> > erronous guest (or device) DMAing to an address being unmapped at the
> >
On Mon, 02 May 2022 14:07:42 +0530, Rohit Agarwal wrote:
> The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
> document the compatible with "qcom,sdhci-msm-v5" as the fallback.
>
> Signed-off-by: Rohit Agarwal
> ---
> Documentation/devicetree/bindings/mmc/sdhci-msm.yaml | 1 +
>
From: Arnd Bergmann
The sa platform is one of the two remaining users of the old Arm
specific "dmabounce" code, which is an earlier implementation of the
generic swiotlb.
Linus Walleij submitted a patch that removes dmabounce support from
the ixp4xx, and I had a look at the other user,
Use dma-direct unconditionally on arm. It has already been used for
some time for LPAE and nommu configurations.
This mostly changes the streaming mapping implementation and the (simple)
coherent allocator for device that are DMA coherent. The existing
complex allocator for uncached mappings
With the dmabounce removal these aren't used outside of dma-mapping.c,
so mark them static. Move the dma_map_ops declarations down a bit
to avoid lots of forward declarations.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
---
arch/arm/include/asm/dma-mapping.h | 75
Only the footbridge platforms provide their own DMA address translation
helpers, so switch to the generic version for all other platforms, and
consolidate the footbridge implementation to remove two levels of
indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
---
Use the helpers as expected by the dma-direct code in the old arm
dma-mapping code to ease a gradual switch to the common DMA code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
---
arch/arm/mm/dma-mapping.c | 24
1 file changed, 12 insertions(+), 12
From: Robin Murphy
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 238
Remove the now unused dmabounce code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
---
arch/arm/common/Kconfig| 4 -
arch/arm/common/Makefile | 1 -
arch/arm/common/dmabounce.c| 582 -
arch/arm/include/asm/device.h
virt_to_dma was only used by the now removed dmabounce code.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/dma-direct.h
b/arch/arm/include/asm/dma-direct.h
index
Hi all,
arm is the last platform not using the dma-direct code for directly
mapped DMA. With the dmaboune removal from Arnd we can easily switch
arm to always use dma-direct now (it already does for LPAE configs
and nommu). I'd love to merge this series through the dma-mapping tree
as it gives
From: Robin Murphy
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
From: Robin Murphy
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
order to avoid spam.
> >
> > Please consider it for your iommu tree.
>
> Reverting this series fixed an user-after-free while doing SR-IOV.
>
> BUG: KASAN: use-after-free in __lock_acquire
> Read of size 8 at addr 080279825d78 by task qemu-system-aar/22429
>
BUG: KASAN: use-after-free in __lock_acquire
Read of size 8 at addr 080279825d78 by task qemu-system-aar/22429
CPU: 24 PID: 22429 Comm: qemu-system-aar Not tainted 5.18.0-rc5-next-20220502
#69
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
print_address_description.constprop.
On Mon, May 2, 2022, at 11:22, Hector Martin wrote:
> This is required to make loading this as a module work.
>
> Signed-off-by: Hector Martin
this could probably use a
Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver")
but otherwise
Reviewed-by: Sven Peter
Thanks,
Sven
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
.../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/serial/renesas,scif.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/serial/renesas,hscif.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi all,
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family[1].
Hence this patch series updates various DT binding documents to move
compatible values for R-Car V3U devices to R-Car Gen4 sections, in
bindings where the latter already exist. Other DT binding
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. Hence move its compatible value to the R-Car Gen4 section.
Signed-off-by: Geert Uytterhoeven
---
.../devicetree/bindings/dma/renesas,rcar-dmac.yaml | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
Despite the name, R-Car V3U is the first member of the R-Car Gen4
family. I2C on R-Car V3U also supports some extra features (e.g. Slave
Clock Stretch Select), which are supported by other R-Car Gen4 SoCs, but
not by any other R-Car Gen3 SoC.
Hence move its compatible value to the R-Car Gen4
On Sun, May 01, 2022 at 07:24:34PM +0800, Lu Baolu wrote:
> As enforce_cache_coherency has been introduced into the iommu_domain_ops,
> the kernel component which owns the iommu domain is able to opt-in its
> requirement for force snooping support. The iommu driver has no need to
> hard code the
On Sun, May 01, 2022 at 07:24:33PM +0800, Lu Baolu wrote:
> The IOMMU force snooping capability is not required to be consistent
> among all the IOMMUs anymore. Remove force snooping capability check
> in the IOMMU hot-add path and domain_update_iommu_snooping() becomes
> a dead code now.
>
>
On Sun, May 01, 2022 at 07:24:32PM +0800, Lu Baolu wrote:
> +static bool domain_support_force_snooping(struct dmar_domain *domain)
> +{
> + struct device_domain_info *info;
> + unsigned long flags;
> + bool support = true;
> +
> + spin_lock_irqsave(_domain_lock, flags);
> + if
On Sun, May 01, 2022 at 07:24:31PM +0800, Lu Baolu wrote:
> The SNP bit is only valid for second-level PTEs. Setting this bit in the
> first-level PTEs has no functional impact because the Intel IOMMU always
> ignores the same bit in first-level PTEs. Anyway, let's check the page
> table type
On Sun, May 01, 2022 at 07:24:30PM +0800, Lu Baolu wrote:
> In the attach_dev callback of the default domain ops, if the domain has
> been set force_snooping, but the iommu hardware of the device does not
> support SC(Snoop Control) capability, the callback should block it and
> return a
From: Tianyu Lan
Traditionally swiotlb was not performance critical because it was only
used for slow devices. But in some setups, like TDX/SEV confidential
guests, all IO has to go through swiotlb. Currently swiotlb only has a
single lock. Under high IO load with multiple CPUs this can lead to
From: Tianyu Lan
Traditionally swiotlb was not performance critical because it was only
used for slow devices. But in some setups, like TDX/SEV confidential
guests, all IO has to go through swiotlb. Currently swiotlb only has a
single lock. Under high IO load with multiple CPUs this can lead to
From: Tianyu Lan
In SEV/TDX Confidential VM, device DMA transaction needs use swiotlb
bounce buffer to share data with host/hypervisor. The swiotlb spinlock
introduces overhead among devices if they share io tlb mem. Avoid such
issue, introduce swiotlb_device_allocate() to allocate device bounce
On 4/30/22 07:12, Baolu Lu wrote:
> On 2022/4/29 05:09, Joao Martins wrote:
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -5089,6 +5089,113 @@ static void intel_iommu_iotlb_sync_map(struct
>> iommu_domain *domain,
>> }
>> }
>>
>> +static int
On 4/30/22 06:12, Baolu Lu wrote:
> On 2022/4/29 05:09, Joao Martins wrote:
>> Today, the dirty state is lost and the page wouldn't be migrated to
>> destination potentially leading the guest into error.
>>
>> Add an unmap API that reads the dirty bit and sets it in the
>> user passed bitmap. This
On 4/30/22 05:11, Baolu Lu wrote:
> On 2022/4/29 05:09, Joao Martins wrote:
>> Add an IO pagetable API iopt_read_and_clear_dirty_data() that
>> performs the reading of dirty IOPTEs for a given IOVA range and
>> then copying back to userspace from each area-internal bitmap.
>>
>> Underneath it uses
On 4/30/22 00:51, Baolu Lu wrote:
> On 2022/4/29 05:09, Joao Martins wrote:
>> +int iopt_set_dirty_tracking(struct io_pagetable *iopt,
>> +struct iommu_domain *domain, bool enable)
>> +{
>> +struct iommu_domain *dom;
>> +unsigned long index;
>> +int ret =
[my mua made the message a tad crooked with the quotations]
On 5/2/22 12:52, Joao Martins wrote:
> On 4/29/22 20:20, Robin Murphy wrote:
>> On 2022-04-29 17:40, Joao Martins wrote:
>>> On 4/29/22 17:11, Jason Gunthorpe wrote:
On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote:
On 4/29/22 20:20, Robin Murphy wrote:
> On 2022-04-29 17:40, Joao Martins wrote:
>> On 4/29/22 17:11, Jason Gunthorpe wrote:
>>> On Fri, Apr 29, 2022 at 03:45:23PM +0100, Joao Martins wrote:
On 4/29/22 13:23, Jason Gunthorpe wrote:
> On Fri, Apr 29, 2022 at 01:06:06PM +0100, Joao Martins
Hi Vasant,
On Fri, Apr 29, 2022 at 08:15:49PM +0530, Vasant Hegde wrote:
> We still need to parse IVHD to find max devices supported by each PCI segment
> (same as the way its doing it today). Hence we need all these variables.
>From what I have seen since a few years the IVRS tables enumerate
This is required to make loading this as a module work.
Signed-off-by: Hector Martin
---
drivers/iommu/apple-dart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index decafb07ad08..a10a73282014 100644
---
://download.01.org/0day-ci/archive/20220502/202205021754.gethfnns-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin
Add devicetree binding for Qualcomm SDX65 SMMU.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
Add sdx65 SoC specific compatible string check inside qcom
'sdhci-msm' controller driver.
Signed-off-by: Rohit Agarwal
---
drivers/mmc/host/sdhci-msm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index fd8b4a9..65661ad 100644
The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
document the compatible with "qcom,sdhci-msm-v5" as the fallback.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/mmc/sdhci-msm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Add smem node to support shared memory manager on SDX65 platform.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index
Hello,
This series adds some patches addressing comments from Bjorn and Ulf.
The patches are from the original series "SDX65 devicetree updates" that
were needed some changes.
Thanks,
Rohit.
Rohit Agarwal (4):
dt-bindings: mmc: sdhci-msm: Document the SDX65 compatible
mmc: host/sdhci-msm:
53 matches
Mail list logo
