On Tue, Sep 14, 2021 at 03:45:06PM +, Ioana Ciornei wrote:
> [ 245.927020] fsl_dpaa2_eth dpni.3: scather-gather idx 0 P=20a732
> N=20a7320 D=20a732 L=30 DMA_BIDIRECTIONAL dma map error check not
> applicable·
> [ 245.927048] fsl_dpaa2_eth dpni.3: scather-gather idx 1 P=20a7320030
On Thu, Sep 30, 2021 at 07:28:18PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 30, 2021 at 01:09:22PM +1000, David Gibson wrote:
>
> > > The *admin* the one responsible to understand the groups, not the
> > > applications. The admin has no idea what a group FD is - they should
> > > be looking at
On Thu, Sep 30, 2021 at 07:23:55PM -0300, Jason Gunthorpe wrote:
> > > The Intel functional issue is that Intel blocks the cache maintaince
> > > ops from the VM and the VM has no way to self-discover that the cache
> > > maintaince ops don't work.
> >
> > the VM doesn't need to know whether the
On Thu, Sep 30, 2021 at 09:43:58PM +0800, Lu Baolu wrote:
> Here, we are discussing arch_sync_dma_for_cpu() and
> arch_sync_dma_for_device(). The x86 arch has clflush to sync dma buffer
> for device, but I can't see any instruction to sync dma buffer for cpu
> if the device is not cache coherent.
On Thu, Sep 30, 2021 at 01:09:22PM +1000, David Gibson wrote:
> > The *admin* the one responsible to understand the groups, not the
> > applications. The admin has no idea what a group FD is - they should
> > be looking at the sysfs and seeing the iommu_group directories.
>
> Not just the admin.
On Thu, Sep 30, 2021 at 09:35:45AM +, Tian, Kevin wrote:
> > The Intel functional issue is that Intel blocks the cache maintaince
> > ops from the VM and the VM has no way to self-discover that the cache
> > maintaince ops don't work.
>
> the VM doesn't need to know whether the maintenance
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a fix for Xen memory freeing on
On Thu, Sep 30, 2021 at 08:49:03AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 23, 2021 8:22 PM
> >
> > > > These are different things and need different bits. Since the ARM path
> > > > has a lot more code supporting it, I'd suggest Intel should change
> >
On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
>
> The first patch is a cleanup of numa_distance allocation in arch_numa I've
> spotted during the conversion.
> The second patch is a fix for Xen memory freeing on some of the error
> paths.
Well, at least patch 2 looks like something that
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
Since memblock_free() operates on a physical range, make its name reflect
it and rename it to memblock_phys_free(), so it will be a logical
counterpart to memblock_phys_alloc().
The callers are updated with the below semantic patch:
@@
expression addr;
expression size;
@@
-
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
memblock_free_early_nid() is unused and memblock_free_early() is an alias
for memblock_free().
Replace calls to memblock_free_early() with calls to memblock_free() and
remove memblock_free_early() and memblock_free_early_nid().
Signed-off-by: Mike Rapoport
---
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range() with
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
>>
>> Is this new ops only needed for the PCIe transport ? or do you have
>> following patches to use this op for the other transports ?
>
> No, I don't think this will make sense for transports that are not based
> on PCI devices.
>
>> If it is only needed for the PCIe then we need to find a
On 2021-09-29 11:06 p.m., Chaitanya Kulkarni wrote:
> Logan,
>
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 7efb31b87f37..916750a54f60 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -3771,7 +3771,8 @@ static void
On 2021-09-29 10:47 p.m., Chaitanya Kulkarni wrote:
> Logan,
>
>> +/*
>> + * bit 2 is the third free bit in the page_link on 64bit systems which
>> + * is used by dma_unmap_sg() to determine if the dma_address is a PCI
>> + * bus address when doing P2PDMA.
>> + * Note: CONFIG_PCI_P2PDMA
page->freelist is for the use of slab. We already have the ability
to free a list of pages in the core mm, but it requires the use of a
list_head and for the pages to be chained together through page->lru.
Switch the iommu code over to using free_pages_list().
Signed-off-by: Matthew Wilcox
Hi Mike,
On Thu, 30 Sep 2021 14:22:34 +, "Campin, Mike"
wrote:
> I need support for mixed user PASID, kernel PASID and non-PASID use cases
> in the driver.
>
This specific RFC is for kernel PASID only. User PASID native use is
supported under SVA lib kernel API and /dev/uacce UAPI or
I need support for mixed user PASID, kernel PASID and non-PASID use cases in
the driver.
-Original Message-
From: Jason Gunthorpe
Sent: Wednesday, September 29, 2021 4:43 PM
To: Jacob Pan
Cc: iommu@lists.linux-foundation.org; LKML ;
Joerg Roedel ; Christoph Hellwig ; Tian,
Kevin ;
Hi Longpeng,
On 2021/9/15 23:21, Longpeng(Mike) wrote:
__domain_mapping() always removes the pages in the range from
'iov_pfn' to 'end_pfn', but the 'end_pfn' is always the last pfn
of the range that the caller wants to map.
This would introduce too many duplicated removing and leads the
map
On 14/09/2021 17:45, Ioana Ciornei wrote:
> On Wed, Sep 08, 2021 at 10:33:26PM -0500, Jeremy Linton wrote:
>> +DPAA2, netdev maintainers
>> Hi,
>>
>> On 5/18/21 7:54 AM, Hamza Mahfooz wrote:
>>> Since, overlapping mappings are not supported by the DMA API we should
>>> report an error if
On Tue, Sep 28, 2021 at 10:45:30AM +0200, Joerg Roedel wrote:
> Hi Lennert,
Hi Joerg,
Thanks for your feedback!
> > +/*
> > + * This function restarts event logging in case the IOMMU experienced
> > + * an event log buffer overflow.
> > + */
> > +void amd_iommu_restart_event_logging(struct
On 2021/9/30 16:49, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, September 23, 2021 8:22 PM
These are different things and need different bits. Since the ARM path
has a lot more code supporting it, I'd suggest Intel should change
their code to use IOMMU_BLOCK_NO_SNOOP and abandon
On 13.08.21 08:53, Yong Wu wrote:
Prepare for 2 HWs that sharing pgtable in different power-domains.
The previous SoC don't have PM. Only mt8192 has power-domain,
and it is display's power-domain which nearly always is enabled.
hi, I see that in mt1873.dtsi, many devices that uses the
On 30.09.21 05:28, Yong Wu wrote:
Hi Dafna,
Thanks very much for the review.
On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the
consumer
and smi-larb device. If the vcodec device call
On 9/30/21 2:19 PM, Jean-Philippe Brucker wrote:
On Thu, Sep 30, 2021 at 10:26:35AM +0530, Vivek Kumar Gautam wrote:
I'm not sure why we made it 32-bit in Linux UAPI, it's a little wasteful.
PCIe PRGI is 9-bits and SMMU STAG is 16-bits. Since the scope of the grpid
is the endpoint, 16-bit
Hi Eric,
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 30 September 2021 10:48
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org; Jean-Philippe Brucker
>
> Cc: Linuxarm
Hi Jean,
On 9/21/21 9:37 PM, Jean-Philippe Brucker wrote:
On Fri, Apr 23, 2021 at 03:21:44PM +0530, Vivek Gautam wrote:
Implementing the alloc_shared_cd and free_shared_cd in cd-lib, and
start using them for arm-smmu-v3-sva implementation.
Signed-off-by: Vivek Gautam
---
Hi Shameer,
On 8/5/21 10:07 AM, Shameer Kolothum wrote:
> Hi,
>
> The series adds support to IORT RMR nodes specified in IORT
> Revision E.b -ARM DEN 0049E[0]. RMR nodes are used to describe
> memory ranges that are used by endpoints and require a unity
> mapping in SMMU.
I used your series and
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 7:42 PM
>
> On Thu, Sep 23, 2021 at 03:38:10AM +, Tian, Kevin wrote:
> > > From: Tian, Kevin
> > > Sent: Thursday, September 23, 2021 11:11 AM
> > >
> > > >
> > > > The required behavior for iommufd is to have the IOMMU ignore the
Hi Jean,
On 9/21/21 9:46 PM, Jean-Philippe Brucker wrote:
On Fri, Apr 23, 2021 at 03:21:46PM +0530, Vivek Gautam wrote:
Once the page faults are handled, the response has to be sent to
virtio-iommu backend, from where it can be sent to the host to
prepare the response to a generated io page
On 9/21/21 9:29 PM, Jean-Philippe Brucker wrote:
On Fri, Apr 23, 2021 at 03:21:38PM +0530, Vivek Gautam wrote:
Keeping a record of list of endpoints that are served by the virtio-iommu
device would help in redirecting the requests of page faults to the
correct endpoint device to handle such
Hi Shimoda-san,
On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
wrote:
> This patch series adds support for r8a779a0 (R-Car V3U).
>
> Yoshihiro Shimoda (2):
> dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779a0 support
> iommu/ipmmu-vmsa: Add support for r8a779a0
Thanks to
On Thu, Sep 30, 2021 at 10:26:35AM +0530, Vivek Kumar Gautam wrote:
> > I'm not sure why we made it 32-bit in Linux UAPI, it's a little wasteful.
> > PCIe PRGI is 9-bits and SMMU STAG is 16-bits. Since the scope of the grpid
> > is the endpoint, 16-bit means 64k in-flight faults per endpoint,
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 8:22 PM
>
> > > These are different things and need different bits. Since the ARM path
> > > has a lot more code supporting it, I'd suggest Intel should change
> > > their code to use IOMMU_BLOCK_NO_SNOOP and abandon
> IOMMU_CACHE.
> >
On 30.09.21 03:30, Mike Rapoport wrote:
From: Mike Rapoport
dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
However, pfn_valid() only checks for availability of the memory map for a
PFN but it does not ensure that the PFN is actually backed by RAM.
As dma_map_resource() is
On Wed, 2021-09-29 at 18:33 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > Prepare for adding device_link.
> >
> > The iommu consumer should use device_link to connect with the
> > smi-larb(supplier). then the smi-larb should run before the iommu
> > consumer. Here we
Logan,
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 7efb31b87f37..916750a54f60 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -3771,7 +3771,8 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,
> unsigned nsid,
>
Logan,
> +/*
> + * bit 2 is the third free bit in the page_link on 64bit systems which
> + * is used by dma_unmap_sg() to determine if the dma_address is a PCI
> + * bus address when doing P2PDMA.
> + * Note: CONFIG_PCI_P2PDMA depends on CONFIG_64BIT because of this.
> + */
> +
> +#ifdef
> +/**
> + * sg_unmark_pci_p2pdma - Unmark the scatterlist entry for PCI p2pdma
> + * @sg: SG entryScatterlist
> + *
> + * Description:
> + * Clears the PCI P2PDMA mark
> + **/
nit:- Probably want to add '.' above.
> +static inline void sg_dma_unmark_pci_p2pdma(struct scatterlist
43 matches
Mail list logo
