On 1/10/19 5:27 PM, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
>
> Signed-off-by: Andy Shevchenko
> Reviewed-by: Mika Westerberg
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-acpi.c | 49 ---
>
On 01/10/2019 23:02, khol...@gmail.com wrote:
From: AngeloGioacchino Del Regno
To avoid context faults reset the context entirely on detach and
to ensure a fresh clean start also do a complete reset before
programming the context for domain initialization.
Signed-off-by: AngeloGioacchino Del
Hi Joerg,
Please can you pull these three arm-smmu fixes for -rc2? They fix a
missing resource free on an error path and some page-table issues with
MALI GPUs including broken cacheability attributes and malformed tree
structure with smaller virtual address ranges.
Thanks,
Will
--->8
The
On 02/10/2019 06:18, Tomasz Figa wrote:
Hi Yong,
On Mon, Sep 30, 2019 at 2:42 PM Yong Wu wrote:
The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API
TLB sync") help move the tlb_sync of unmap from v7s into the iommu
framework. It helps add a new function
Hi Christoph,
On Fri, Aug 30, 2019 at 8:30 AM Christoph Hellwig wrote:
> A helper to find the backing page array based on a virtual address.
> This also ensures we do the same vm_flags check everywhere instead
> of slightly different or missing ones in a few places.
>
> Signed-off-by: Christoph
Hi Jacob,
There seem to be a mix-up here, the changes from your v2 are lost and
patches 1 and 3 are back to v1. Assuming this isn't intended, I'll
review v2 of this patch since it looked good to me overall.
Thanks,
Jean
___
iommu mailing list
Hi Jean,
Just wondering if you have more comments on ioasid custom allocator, v3
is largely the same as v2 other than shuffling header within the set.
Thanks,
Jacob
On Tue, 1 Oct 2019 16:33:21 -0700
Jacob Pan wrote:
> This set consists of IOMMU APIs to support SVA in the guest, a.k.a
>
On Tue, 24 Sep 2019 08:40:54 +0100, Biju Das wrote:
> Document RZ/G2N (R8A774B1) SoC bindings.
>
> Signed-off-by: Biju Das
> ---
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Wed, 2 Oct 2019 16:18:10 +0200
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> There seem to be a mix-up here, the changes from your v2 are lost and
> patches 1 and 3 are back to v1. Assuming this isn't intended, I'll
> review v2 of this patch since it looked good to me overall.
>
oops, you
On 02/10/2019 13:05, Geert Uytterhoeven wrote:
Hi Christoph,
On Fri, Aug 30, 2019 at 8:30 AM Christoph Hellwig wrote:
A helper to find the backing page array based on a virtual address.
This also ensures we do the same vm_flags check everywhere instead
of slightly different or missing ones in
Hi Jacob,
I have four tiny comments below but the patch looks great otherwise, no
major concern from me.
On Sat, Sep 21, 2019 at 05:07:49PM -0700, Jacob Pan wrote:
> +/*
> + * struct ioasid_allocator_data - Internal data structure to hold information
> + * about an allocator. There are two types
On Wed, 2 Oct 2019 18:18:25 +0200
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> I have four tiny comments below but the patch looks great otherwise,
> no major concern from me.
>
> On Sat, Sep 21, 2019 at 05:07:49PM -0700, Jacob Pan wrote:
> > +/*
> > + * struct ioasid_allocator_data - Internal
IOMMU domain resource life is well-defined, managed
by .domain_alloc and .domain_free.
Therefore, domain-specific resources shouldn't be tied to
the device life, but instead to its domain.
Signed-off-by: Ezequiel Garcia
---
drivers/iommu/rockchip-iommu.c | 7 +--
1 file changed, 5
IOASID allocation may rely on platform specific methods. One use case is
that when running in the guest, in order to obtain system wide global
IOASIDs, emulated allocation interface is needed to communicate with the
host. Here we call these platform specific allocators custom allocators.
Custom
From: Yi L Liu
In any virtualization use case, when the first translation stage
is "owned" by the guest OS, the host IOMMU driver has no knowledge
of caching structure updates unless the guest invalidation activities
are trapped by the virtualizer and passed down to the host.
Since the
From: Jean-Philippe Brucker
Some devices might support multiple DMA address spaces, in particular
those that have the PCI PASID feature. PASID (Process Address Space ID)
allows to share process address spaces with devices (SVA), partition a
device into VM-assignable entities (VFIO mdev) or
Guest shared virtual address (SVA) may require host to shadow guest
PASID tables. Guest PASID can also be allocated from the host via
enlightened interfaces. In this case, guest needs to bind the guest
mm, i.e. cr3 in guest physical address to the actual PASID table in
the host IOMMU. Nesting will
This set consists of IOMMU APIs to support SVA in the guest, a.k.a nested
SVA. As the complete SVA support is complex, we break down the enabling
effort into three stages:
1. PCI device direct assignment
2. Fault handling, especially page request service support
3. Mediated device assignment
Each
As we've seen from USB and other areas, we need to always do runtime
checks for DMA operating on memory regions that might be remapped. This
consolidates the (existing!) checks and makes them on by default. A
warning will be triggered for any drivers still using DMA on the stack
(as has been seen
Hi Kees,
On 2019-10-02 9:46 pm, Kees Cook wrote:
As we've seen from USB and other areas, we need to always do runtime
checks for DMA operating on memory regions that might be remapped. This
consolidates the (existing!) checks and makes them on by default. A
warning will be triggered for any
Hi Kees,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc1 next-20191002]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
On Wed, Oct 02, 2019 at 10:15:43PM +0100, Robin Murphy wrote:
> Hi Kees,
>
> On 2019-10-02 9:46 pm, Kees Cook wrote:
> > As we've seen from USB and other areas, we need to always do runtime
> > checks for DMA operating on memory regions that might be remapped. This
> > consolidates the
On Wed, Oct 02, 2019 at 04:58:39PM -0700, Kees Cook wrote:
> In the USB case, it'll actually refuse to do the operation. Should
> dma_map_single() similarly fail? I could push these checks down into
> dma_map_single(), which would be a no-change on behavior for USB and
> gain the checks on all
Hi Kees,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc1 next-20191002]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
24 matches
Mail list logo
