> From: Jason Gunthorpe
> Sent: Wednesday, September 16, 2020 10:45 PM
>
> On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, September 15, 2020 10:29 PM
> > >
> > > > Do they need a device at all? It's not clear to me why RID based
>
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 need for software to translate virtual
> +addresses to physical addresses. SVA is what
On Thu, Sep 17, 2020 at 07:32:28PM +0200, Christoph Hellwig wrote:
> The DMA API removed support for not passing in a device a long time
> ago, so remove the NULL checks.
What happens with ISA devices?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps
On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const
The DMA API removed support for not passing in a device a long time
ago, so remove the NULL checks.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/dma-direct.h
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote:
> > > Instead of blindly moving the code around to a spot that would just work,
> > > I am trying to understand what might be required here. In this case,
> > > the init_device_table_dma()should not be needed. I suspect it's the IOMMU
> > >
Hi Jason,
On Thu, 17 Sep 2020 11:53:49 +0800, Jason Wang
wrote:
> On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
> > Hi Jason,
> > On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
> > wrote:
> >
> >> On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
> >>> Hi Jason,
> >>> On
Switch the footbridge PCI devices to use dma_direct_set_offset to set the
DMA offset instead of using direct hooks into the DMA mapping code and
remove the now unused hooks.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 4 +-
arch/arm/include/asm/memory.h
Switch the omap1510 platform ohci device to use dma_direct_set_offset
to set the DMA offset instead of using direct hooks into the DMA
mapping code and remove the now unused hooks.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 18 -
Now that the two remaining architectures that hooked into the DMA
translation directly use the range map instead, there is no need to
override phys_to_dma and dma_to_phys. Remove asm/dma-direct.h after
switching the remaining callsites to the phys addr based generic
helpers instead of the PFN or
On Thu, Sep 17, 2020 at 07:32:27PM +0200, Christoph Hellwig wrote:
> static int __init cats_pci_init(void)
> {
> - if (machine_is_cats())
> - pci_common_init(_pci);
> + if (!machine_is_cats())
> + return 0;
> + bus_register_notifier(_bus_type, _pci_dma_nb);
>
Hi, Joerg,
On Wed, Sep 16, 2020 at 10:06:02AM +0200, Joerg Roedel wrote:
> On Tue, Sep 15, 2020 at 09:30:04AM -0700, Fenghua Yu wrote:
> > Ashok Raj (1):
> > Documentation/x86: Add documentation for SVA (Shared Virtual
> > Addressing)
> >
> > Fenghua Yu (7):
> > drm, iommu: Change type
On Tue, Sep 15, 2020 at 05:23:59PM -0700, Nicolin Chen wrote:
> The "num_tlb_lines" might not be a power-of-2 value, being 48 on
> Tegra210 for example. So the current way of calculating tlb_mask
> using the num_tlb_lines is not correct: tlb_mask=0x5f in case of
> num_tlb_lines=48, which will trim
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
That's bizarre -- this should really be the
> The DDK blob has the ability to mark only certain areas of memory as
> coherent for performance reasons. For simple things like kmscube I would
> expect that it's basically write-only from the CPU and almost all memory the
> GPU touches isn't touched by the CPU. I.e. coherency isn't helping and
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free.
The "num_tlb_lines" might not be a power-of-2 value, being 48 on
Tegra210 for example. So the current way of calculating tlb_mask
using the num_tlb_lines is not correct: tlb_mask=0x5f in case of
num_tlb_lines=48, which will trim a setting of 0x30 (48) to 0x10.
Signed-off-by: Nicolin Chen
These two patches fix ACTIVE_TLB_LINES field setting in tegra-smmu
driver for Tegra210 platforms.
This resend in series groups two previous seperate changes that're
corelated, being pointed out by Thierry. Also adding his Acked-by.
Nicolin Chen (2):
iommu/tegra-smmu: Fix tlb_mask
memory:
On Tue, 18 Aug 2020 19:11:26 -0300, Thiago Jung Bauermann wrote:
> POWER secure guests (i.e., guests which use the Protection Execution
> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
> they don't need the SWIOTLB memory to be in low addresses since the
> hypervisor
According to Tegra210 TRM, the default value of TLB_ACTIVE_LINES
field of register MC_SMMU_TLB_CONFIG_0 is 0x30. So num_tlb_lines
should be 48 (0x30) rather than 32 (0x20).
Signed-off-by: Nicolin Chen
Acked-by: Thierry Reding
---
drivers/memory/tegra/tegra210.c | 2 +-
1 file changed, 1
On 17/09/2020 11:51, Tomeu Vizoso wrote:
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
That's
if of_find_device_by_node() succeed, exynos_iommu_of_xlate() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes: aa759fd376fb ("iommu/exynos: Add callback for initializing devices from
device tree")
if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Fixes: e86d1aa8b60f ("iommu/arm-smmu: Move Arm SMMU drivers into their own
subdirectory")
Signed-off-by: Yu
On 2020/9/18 上午2:17, Jacob Pan (Jun) wrote:
Hi Jason,
On Thu, 17 Sep 2020 11:53:49 +0800, Jason Wang
wrote:
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
On Thu, Sep 17, 2020 at 07:50:10PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Sep 17, 2020 at 07:32:28PM +0200, Christoph Hellwig wrote:
> > The DMA API removed support for not passing in a device a long time
> > ago, so remove the NULL checks.
>
> What happens with ISA devices?
For
* Christoph Hellwig [200917 17:37]:
> Switch the omap1510 platform ohci device to use dma_direct_set_offset
> to set the DMA offset instead of using direct hooks into the DMA
> mapping code and remove the now unused hooks.
Looks nice to me :) I still can't test this probably for few more weeks
On 2020-09-16 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free.
On Wed, Sep 16, 2020 at 02:51:06PM -0600, Thomas Tai wrote:
> When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
> printing a warning message in swiotlb_map(). The dev->dma_mask must not
> be a NULL pointer when calling the dma mapping layer. A NULL pointer check
> can
On 16/09/2020 00:51, Robin Murphy wrote:
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to
On Tue, Sep 08, 2020 at 09:45:02AM +0200, Auger Eric wrote:
> > +int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max)
> > +{
> > + int ret = 0;
> > + ioasid_t pasid;
> > +
> > + if (min == INVALID_IOASID || max == INVALID_IOASID ||
> > + min == 0 || max < min)
>
On Tue, Sep 08, 2020 at 11:38:31AM +0200, Auger Eric wrote:
> Hi Jean,
> On 8/17/20 7:15 PM, Jean-Philippe Brucker wrote:
> > Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> > under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> > check FEAT_ATS and
On Mon, Sep 07, 2020 at 06:41:11PM +0200, Auger Eric wrote:
> > +/*
> > + * Try to reserve this ASID in the SMMU. If it is in use, try to steal it
> > from
> > + * the private entry. Careful here, we may be modifying the context tables
> > of
> > + * another SMMU!
> Not sure I got what you meant
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
On Tue, Sep 08, 2020 at 09:41:20AM +0200, Auger Eric wrote:
> > +static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct
> > *mm)
> > +{
> > + u16 asid;
> > + int err = 0;
> > + u64 tcr, par, reg;
> > + struct arm_smmu_ctx_desc *cd;
> > + struct arm_smmu_ctx_desc *ret
On Fri, Sep 04, 2020 at 11:08:34AM +0200, Joerg Roedel wrote:
> On Mon, Aug 17, 2020 at 07:15:46PM +0200, Jean-Philippe Brucker wrote:
> > Jean-Philippe Brucker (12):
> > iommu/ioasid: Add ioasid references
> > iommu/sva: Add PASID helpers
> > arm64: mm: Pin down ASIDs for sharing mm with
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block
On Tue, Sep 08, 2020 at 11:46:05AM +0200, Auger Eric wrote:
> Hi Jean,
>
> On 8/17/20 7:15 PM, Jean-Philippe Brucker wrote:
> > Implement the IOMMU device feature callbacks to support the SVA feature.
> > At the moment dev_has_feat() returns false since I/O Page Faults isn't
> > yet implemented.
I've pulled this into the dma-mapping for-next tree. Thanks Jim and
everyone helping out!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Thanks,
applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2020-09-17 12:44 p.m., Christoph Hellwig wrote:
Thanks,
applied to the dma-mapping for-next tree.
Thank you, Christoph for suggesting and applying the fix.
Thomas
___
iommu mailing list
iommu@lists.linux-foundation.org
On 2020-09-17 12:05 p.m., Konrad Rzeszutek Wilk wrote:
On Wed, Sep 16, 2020 at 02:51:06PM -0600, Thomas Tai wrote:
When booting the kernel v5.9-rc4 on a VM, the kernel would panic when
printing a warning message in swiotlb_map(). The dev->dma_mask must not
be a NULL pointer when calling the
On Thu, Sep 17, 2020 at 07:56:09AM -0700, Raj, Ashok wrote:
> Just tweaked it a bit:
>
> "When ATS lookup fails for a virtual address, device should use PRI in
> order to request the virtual address to be paged into the CPU page tables.
> The device must use ATS again in order the fetch the
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 virtual address, device should use PRI in
> >
On Thu, Sep 17, 2020 at 11:53:49AM +0800, Jason Wang wrote:
> > > When VDPA is used by qemu it makes sense that the PASID will be an
> > > arbitary IOVA map constructed to be 1:1 with the guest vCPU physical
> > > map. /dev/sva allows a single uAPI to do this kind of setup, and qemu
> > > can
On Thu, Sep 17, 2020 at 10:22:39AM -0700, Raj, Ashok wrote:
> s/translation again/translation
Ok, last one. Now stop looking at that text because you'll find more.
:-)))
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Russell,
as Robin pointed out there is not much need for the ARM specific
routines to translated to and from a dma_addr_t given that we have
the dma offset (and now offset range) functionality. This series
converts ARM over to the generic helpers. This has only been tested
on qemu, and
46 matches
Mail list logo