> From: Koenig, Christian
> Sent: Thursday, November 22, 2018 3:10 AM
>
> Am 21.11.18 um 12:16 schrieb Jean-Philippe Brucker:
> > On 12/11/2018 14:40, Joerg Roedel wrote:
> >> Hi Jean-Philippe,
> >>
> >> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote:
> >>> The allocator
On Thu, Nov 22, 2018 at 10:36 AM Matthew Wilcox wrote:
>
> On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> > These are IOMMU page tables, rather than CPU ones, so we're already well
> > outside arch code - indeed the original motivation of io-pgtable was to be
> > entirely
On (11/21/18 11:49), Waiman Long wrote:
[..]
> > case ODEBUG_STATE_ACTIVE:
> > - debug_print_object(obj, "init");
> > state = obj->state;
> > raw_spin_unlock_irqrestore(>lock, flags);
> > + debug_print_object(obj, "init");
> >
On Wed, Nov 21, 2018 at 10:26:26PM +, Robin Murphy wrote:
> These are IOMMU page tables, rather than CPU ones, so we're already well
> outside arch code - indeed the original motivation of io-pgtable was to be
> entirely independent of the p*d types and arch-specific MM code (this Armv7
>
On Thu, Nov 22, 2018 at 2:02 AM Michal Hocko wrote:
>
> On Wed 21-11-18 16:46:38, Will Deacon wrote:
> > On Sun, Nov 11, 2018 at 05:03:41PM +0800, Nicolas Boichat wrote:
> > > For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> > > is defined (e.g. on arm64 platforms).
> > >
> >
On Thu, Nov 22, 2018 at 6:27 AM Robin Murphy wrote:
>
> On 2018-11-21 9:38 pm, Matthew Wilcox wrote:
> > On Wed, Nov 21, 2018 at 06:20:02PM +, Christopher Lameter wrote:
> >> On Sun, 11 Nov 2018, Nicolas Boichat wrote:
> >>
> >>> This is a follow-up to the discussion in [1], to make sure that
On Thu, Nov 22, 2018 at 2:32 AM Christopher Lameter wrote:
>
> On Sun, 11 Nov 2018, Nicolas Boichat wrote:
>
> > SLAB_CACHE_DMA32 is only available after explicit kmem_cache_create calls,
> > no default cache is created for kmalloc. Add a test in check_slab_flags
> > for this.
>
> This does not
The Intel IOMMU driver opportunistically skips a few top level page
tables from the domain paging directory while programming the IOMMU
context entry. However there is an implicit assumption in the code that
domain's adjusted guest address width (agaw) would always be greater
than IOMMU's agaw.
On 2018-11-21 9:38 pm, Matthew Wilcox wrote:
On Wed, Nov 21, 2018 at 06:20:02PM +, Christopher Lameter wrote:
On Sun, 11 Nov 2018, Nicolas Boichat wrote:
This is a follow-up to the discussion in [1], to make sure that the page
tables allocated by iommu/io-pgtable-arm-v7s are contained
On Wed, Nov 21, 2018 at 06:20:02PM +, Christopher Lameter wrote:
> On Sun, 11 Nov 2018, Nicolas Boichat wrote:
>
> > This is a follow-up to the discussion in [1], to make sure that the page
> > tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
> > physical address
On Sun, 11 Nov 2018, Nicolas Boichat wrote:
> SLAB_CACHE_DMA32 is only available after explicit kmem_cache_create calls,
> no default cache is created for kmalloc. Add a test in check_slab_flags
> for this.
This does not define the dma32 kmalloc array. Is that intentional? In that
case you need
On Wed, 21 Nov 2018, Will Deacon wrote:
> > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
SLAB_CACHE_DMA32??? WTH is going on here? We are trying to get rid of
the dma slab array.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Sun, 11 Nov 2018, Nicolas Boichat wrote:
> This is a follow-up to the discussion in [1], to make sure that the page
> tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
> physical address space.
Page tables? This means you need a page frame? Why go through the slab
On 11/21/18 2:56 PM, Souptick Joarder wrote:
> On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
> wrote:
>> On 11/21/18 1:24 AM, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
>>> wrote:
Previouly drivers have their own way of mapping range of
kernel
On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
wrote:
>
> On 11/21/18 1:24 AM, Souptick Joarder wrote:
> > 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
> >>
On 11/21/18 1:24 AM, Souptick Joarder wrote:
> 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
Am 21.11.18 um 12:16 schrieb Jean-Philippe Brucker:
> On 12/11/2018 14:40, Joerg Roedel wrote:
>> Hi Jean-Philippe,
>>
>> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote:
>>> The allocator doesn't really belong in drivers/iommu because some
>>> drivers would like to allocate
On 12/11/2018 14:55, j...@8bytes.org wrote:
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
>> (1) My initial approach would have been to use the same page tables for
>> the default_domain and this new domain, but it might be precisely what
>> you
On Wed 21-11-18 16:46:38, Will Deacon wrote:
> On Sun, Nov 11, 2018 at 05:03:41PM +0800, Nicolas Boichat wrote:
> > For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> > is defined (e.g. on arm64 platforms).
> >
> > For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.
>
Thanks,
aplied to the dma-mapping for-linus tree.
I'll wait a little longer for a review from Stefano, but I really want
it in linux-next asap and hopefully off to Linus for the weekend.
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Thor,
On Fri, Oct 05, 2018 at 03:57:00PM -0500, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> Currently the clocks are specified in a structure as well as
> in the device tree. Since all the information about clocks can be
> pulled from the device tree, parse the device tree for
On 21/11/2018 17:38, Christopher Lameter wrote:
On Wed, 21 Nov 2018, Will Deacon wrote:
+#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
SLAB_CACHE_DMA32??? WTH is going on here? We are trying to get rid of
the dma slab array.
See the previous two patches in this series. If there's
[+Thor]
On Fri, Nov 16, 2018 at 04:54:30PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements.
> On msm8996, multiple cores, viz. mdss, video, etc. use this
> smmu. On sdm845, this smmu is used with gpu.
> Add bindings for the
On Fri, Nov 16, 2018 at 04:54:27PM +0530, Vivek Gautam wrote:
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context of the master device. So calling runtime apis in those
On Wed, Nov 21, 2018 at 04:47:48PM +, John Garry wrote:
> On 21/11/2018 16:07, Will Deacon wrote:
> >On Wed, Nov 21, 2018 at 10:54:10PM +0800, John Garry wrote:
> >>From: Ganapatrao Kulkarni
> >>
> >>Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
> >>respective
On 11/19/2018 01:55 PM, Waiman Long wrote:
> The db->lock is a raw spinlock and so the lock hold time is supposed
> to be short. This will not be the case when printk() is being involved
> in some of the critical sections. In order to avoid the long hold time,
> in case some messages need to be
On 21/11/2018 16:07, Will Deacon wrote:
On Wed, Nov 21, 2018 at 10:54:10PM +0800, John Garry wrote:
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
respective device NUMA node. The ternary operator which would be for
alloc_pages_node() is
On Sun, Nov 11, 2018 at 05:03:41PM +0800, Nicolas Boichat wrote:
> For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is defined (e.g. on arm64 platforms).
>
> For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.
>
> Also, print an error when the physical address does
Hi Will,
On 11/21/2018 9:22 PM, Will Deacon wrote:
Hi Vivek,
On Thu, Oct 11, 2018 at 03:19:28PM +0530, Vivek Gautam wrote:
This series enables apps-smmu, the "arm,mmu-500" instance
on sdm845.
Series tested on SDM845 MTP device with related smmu patch series [1],
and necessary config change,
On Wed, Nov 21, 2018 at 10:54:10PM +0800, John Garry wrote:
> From: Ganapatrao Kulkarni
>
> Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
> respective device NUMA node. The ternary operator which would be for
> alloc_pages_node() is tidied along with this.
>
> We also
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
Here's a quick v2 addressing Christoph's nits and collecting the tags
given so far. I've reproduced my USB problem with a commit prior to the
dma-mapping pull, so it looks like the cache maintenance changes are off
the hook for that one (and I'll have to venture into USB/UAS territory).
No
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:
Hi Vivek,
On Thu, Oct 11, 2018 at 03:19:28PM +0530, Vivek Gautam wrote:
> This series enables apps-smmu, the "arm,mmu-500" instance
> on sdm845.
> Series tested on SDM845 MTP device with related smmu patch series [1],
> and necessary config change, besides one hack to keep LDO14 in LPM mode
> to
On Wed, Nov 21, 2018 at 02:03:31PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 20, 2018 at 11:34:41AM -0500, Konrad Rzeszutek Wilk wrote:
> > > Konrad, are you ok with me picking up both through the dma-mapping
> > > tree?
> >
> > Yes, albeit I would want Stefano to take a peek at patch #2 just
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
respective device NUMA node. The ternary operator which would be for
alloc_pages_node() is tidied along with this.
We also include a change to use kvzalloc() for kzalloc()/vzalloc()
combination.
> On Nov 21, 2018, at 5:35 AM, Matthew Wilcox wrote:
>
> It's probably better to be more explicit and answer Randy's question:
>
> * If we fail to insert any page into the vma, the function will return
> * immediately leaving any previously-inserted pages present. Callers
> * from the mmap
On Tue, Nov 20, 2018 at 11:34:41AM -0500, Konrad Rzeszutek Wilk wrote:
> > Konrad, are you ok with me picking up both through the dma-mapping
> > tree?
>
> Yes, albeit I would want Stefano to take a peek at patch #2 just in case.
Stefano, can you take a look asap? This is a pretty trivial fix
Could you add a line to the description explicitly stating that a failure
to insert any page in the range will fail the entire routine, something
like:
> * This allows drivers to insert range of kernel pages they've allocated
> * into a user vma. This is a generic function which drivers can use
>
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0("iommu/vt-d: Switch from ioremap_cache to memremap")
Signed-off-by: Pan Bian
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Nov 20, 2018 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> 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
On Wed, Nov 21, 2018 at 04:19:11AM -0700, William Kucharski wrote:
> Could you add a line to the description explicitly stating that a failure
> to insert any page in the range will fail the entire routine, something
> like:
>
> > * This allows drivers to insert range of kernel pages they've
Hi jean,
On 11/20/18 6:30 PM, Jean-Philippe Brucker wrote:
> 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
On 12/11/2018 14:40, Joerg Roedel wrote:
> Hi Jean-Philippe,
>
> On Fri, Oct 19, 2018 at 07:11:54PM +0100, Jean-Philippe Brucker wrote:
>> The allocator doesn't really belong in drivers/iommu because some
>> drivers would like to allocate PASIDs for devices that aren't managed by
>> an IOMMU,
On Wed, Nov 21, 2018 at 02:22:08AM +0530, Kirti Wankhede wrote:
> It is about how mdev framework can be used by existing drivers. These
> symbols doesn't use any other exported symbols.
That is an unfortunate accident of history, but doesn't extent to new
ones. It also is another inidicator
45 matches
Mail list logo
