On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
Hi Joerg,
On 11/8/18 12:43 AM, j...@8bytes.org wrote:
Hi,
On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
Hi Joerg,
On 11/7/18 12:25 AM, j...@8bytes.org wrote:
Nowadays, we can find PASID granular DMA translation on both ARM and x86
platforms. With PASID granular DMA translation sup
On Tue, Nov 20, 2018 at 10:20:10AM +0100, Christoph Hellwig wrote:
> On Mon, Nov 05, 2018 at 02:40:51PM -0800, Nicolin Chen wrote:
> > > > In general, this seems to make sense to me. It does represent a
> > > > theoretical
> > > > change in behaviour for devices which have their own CMA area some
On Friday, November 16, 2018 11:57:38 AM CET Lorenzo Pieralisi wrote:
> On Thu, Nov 15, 2018 at 07:33:54PM +, mario.limoncie...@dell.com wrote:
> >
> >
> > > -Original Message-
> > > From: Mika Westerberg
> > > Sent: Thursday, November 15, 2018 1:01 PM
> > > To: Lorenzo Pieralisi
> >
On 11/16/2018 2:27 PM, Christoph Hellwig wrote:
> On Fri, Nov 16, 2018 at 09:20:48AM +0800, Lu Baolu wrote:
>>> Please keep symbols mdev_set/get_iommu_device(dev, iommu_device) non-GPL
>>> same as other exported symbols from mdev_core module.
>>
>> Yes. It will be fixed in the next version.
>
>
On Tue, Nov 20, 2018 at 6:10 AM Robin Murphy wrote:
>
> This is what I have so far, which at least resolves the most ovbious
> problems. I still haven't got very far with the USB corruption issue
> I see on Juno with -rc1, but I'm yet to confirm whether that's actually
> attributable to the SWIOTL
On 16/11/2018 18:46, Jean-Philippe Brucker wrote:
>>> +/*
>>> + * __viommu_sync_req - Complete all in-flight requests
>>> + *
>>> + * Wait for all added requests to complete. When this function returns, all
>>> + * requests that were in-flight at the time of the call have completed.
>>> + */
>>> +s
On Tue, Nov 20, 2018 at 03:01:33PM +, Robin Murphy wrote:
> On 20/11/2018 14:49, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 20, 2018 at 02:09:52PM +, Robin Murphy wrote:
> > > With the overflow buffer removed, we no longer have a unique address
> > > which is guaranteed not to be a valid
On Tue, Nov 20, 2018 at 05:08:18PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 20, 2018 at 02:09:51PM +, Robin Murphy wrote:
> > This is what I have so far, which at least resolves the most ovbious
> > problems. I still haven't got very far with the USB corruption issue
> > I see on Juno with
The subject line should say dma-direct. This isn't really swiotlb
specific.
> +#define DIRECT_MAPPING_ERROR ~(dma_addr_t)0
Please add braces around the value like the other *MAPPING_ERROR
defintions so that it can be safely used in any context.
Otherwise looks good:
Reviewed-by: Christ
On Tue, Nov 20, 2018 at 02:09:51PM +, Robin Murphy wrote:
> This is what I have so far, which at least resolves the most ovbious
> problems. I still haven't got very far with the USB corruption issue
> I see on Juno with -rc1, but I'm yet to confirm whether that's actually
> attributable to the
On Tue, Nov 20, 2018 at 02:09:53PM +, Robin Murphy wrote:
> If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
> lead to such delights as performing cache maintenance on whatever
> address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
> outside the kernel m
On 20/11/2018 14:20, Robin Murphy wrote:
On 20/11/2018 13:42, John Garry wrote:
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Signed-off-by: Ganapatrao Kulkarni
[JPG: Modifed to use kvzalloc() and fixed
On 20/11/2018 14:49, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 20, 2018 at 02:09:52PM +, Robin Murphy wrote:
With the overflow buffer removed, we no longer have a unique address
which is guaranteed not to be a valid DMA target to use as an error
token. The DIRECT_MAPPING_ERROR value of 0 trie
On Tue, Nov 20, 2018 at 02:09:53PM +, Robin Murphy wrote:
> If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
> lead to such delights as performing cache maintenance on whatever
> address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
> outside the kernel m
On Tue, Nov 20, 2018 at 02:09:52PM +, Robin Murphy wrote:
> With the overflow buffer removed, we no longer have a unique address
> which is guaranteed not to be a valid DMA target to use as an error
> token. The DIRECT_MAPPING_ERROR value of 0 tries to at least represent
> an unlikely DMA targe
On 20/11/2018 13:42, John Garry wrote:
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Signed-off-by: Ganapatrao Kulkarni
[JPG: Modifed to use kvzalloc() and fixed indentation]
Signed-off-by: John Garry
-
With the overflow buffer removed, we no longer have a unique address
which is guaranteed not to be a valid DMA target to use as an error
token. The DIRECT_MAPPING_ERROR value of 0 tries to at least represent
an unlikely DMA target, but unfortunately there are already SWIOTLB
users with DMA-able mem
If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
lead to such delights as performing cache maintenance on whatever
address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
outside the kernel memory map and goes about as well as expected.
Don't do that.
Fixes:
This is what I have so far, which at least resolves the most ovbious
problems. I still haven't got very far with the USB corruption issue
I see on Juno with -rc1, but I'm yet to confirm whether that's actually
attributable to the SWIOTLB changes or something else entirely.
Robin.
Robin Murphy (2)
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Signed-off-by: Ganapatrao Kulkarni
[JPG: Modifed to use kvzalloc() and fixed indentation]
Signed-off-by: John Garry
---
Difference v1->v2:
- Add Ganapatrao's
On 20/11/2018 09:16, Jonathan Cameron wrote:
> +CC Jean-Phillipe and iommu list.
Thanks for the Cc, sorry I don't have enough bandwidth to follow this
thread at the moment.
> In WarpDrive/uacce, we make this simple. If you support IOMMU and it
> support
> SVM/SVA. Everything will be
On 20/11/2018 10:09, Ganapatrao Kulkarni wrote:
Hi John,
On Tue, Nov 20, 2018 at 3:35 PM John Garry wrote:
On 08/11/2018 17:55, John Garry wrote:
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Ping a friendly reminder on th
Hi John,
On Tue, Nov 20, 2018 at 3:35 PM John Garry wrote:
>
> On 08/11/2018 17:55, John Garry wrote:
> > Change function __iommu_dma_alloc_pages() to allocate memory/pages
> > for DMA from respective device NUMA node.
> >
>
> Ping a friendly reminder on this patch.
>
> Thanks
>
> > Originall
On 08/11/2018 17:55, John Garry wrote:
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Ping a friendly reminder on this patch.
Thanks
Originally-from: Ganapatrao Kulkarni
Signed-off-by: John Garry
---
This patch was origina
On Mon, Nov 19, 2018 at 03:22:13PM -0800, John Stultz wrote:
> > + sg->dma_address = dma_addr;
> > sg_dma_len(sg) = sg->length;
> > }
>
> I know Robin has already replied with more detailed info, but just to
> close the loop as I'm finally home, applying this
On Mon, Nov 19, 2018 at 07:36:44PM +, Robin Murphy wrote:
> OK, having brought my Hikey to life and reproduced John's stall with rc1,
> what's going on is that at some point dma_map_sg() returns 0, which causes
> the SCSI/UFS layer to go round in circles repeatedly trying to map the same
> l
On Mon, Nov 05, 2018 at 02:40:51PM -0800, Nicolin Chen wrote:
> > > In general, this seems to make sense to me. It does represent a
> > > theoretical
> > > change in behaviour for devices which have their own CMA area somewhere
> > > other than kernel memory, and only ever make non-atomic alloca
+CC Jean-Phillipe and iommu list.
On Mon, 19 Nov 2018 20:29:39 -0700
Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 11:07:02AM +0800, Kenneth Lee wrote:
> > On Mon, Nov 19, 2018 at 11:49:54AM -0700, Jason Gunthorpe wrote:
> > > Date: Mon, 19 Nov 2018 11:49:54 -0700
> > > From: Jason Gunthor
29 matches
Mail list logo
