On Wed, 2018-07-04 at 13:57 +0100, Robin Murphy wrote:
>
> > Could it ? I wouldn't think dma_map_page is allows to cross page
> > boundaries ... what about single() ? The main worry is people using
> > these things on kmalloc'ed memory
>
> Oh, absolutely - the underlying operation is just
On Mon, Jul 09, 2018 at 01:22:50PM +0800, Lu Baolu wrote:
[...]
> +#ifndef __INTEL_PASID_H
> +#define __INTEL_PASID_H
> +
> +#define PASID_MIN0x1
> +#define PASID_MAX0x2
Could I ask whether there's a reason to explicitly use 0x2 for the
max value?
On Mon, Jul 09, 2018 at 01:22:58PM +0800, Lu Baolu wrote:
> The obsolete per iommu pasid tables are no longer used. Hence,
> clean up them.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Cc: Liu Yi L
> Signed-off-by: Lu Baolu
> Reviewed-by: Liu Yi L
> ---
>
On Mon, Jul 09, 2018 at 01:22:55PM +0800, Lu Baolu wrote:
> This patch adds the interfaces for per PCI device pasid
> table management. Currently we allocate one pasid table
> for all PCI devices under the scope of an IOMMU. It's
> insecure in some cases where multiple devices under one
> single
This removes needless use of '%p', and refactors the printk calls to
use pr_*() helpers instead.
Signed-off-by: Kees Cook
---
kernel/dma/swiotlb.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
On 7/10/18 11:01 AM, Christoph Hellwig wrote:
These patches attempt to deal with this in the simplest way possible by
generalising the specific quirk for 32-bit bridges into an arbitrary
mask which can then also be plumbed into the firmware code. In the
interest of being minimally invasive, I've
On 10/07/18 19:02, Christoph Hellwig wrote:
These patches attempt to deal with this in the simplest way possible by
generalising the specific quirk for 32-bit bridges into an arbitrary
mask which can then also be plumbed into the firmware code. In the
interest of being minimally invasive, I've
On Tue, Jul 10, 2018 at 06:17:17PM +0100, Robin Murphy wrote:
> When an explicit DMA limit is described by firmware, we need to remember
> it regardless of how drivers might subsequently update their devices'
> masks. The new bus_dma_mask field does that.
Shouldn't we also stop presetting the dma
On Tue, Jul 10, 2018 at 06:17:16PM +0100, Robin Murphy wrote:
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 8be8106270c2..95e185347e34 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -183,7 +183,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
>
Hi Christoph,
On Tue, Jul 10, 2018 at 02:35:18PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 20, 2018 at 09:23:28AM +0200, Christoph Hellwig wrote:
> > No, this is a mixup. I hadn't noticed one case was 0x0fff and
> > the other 0x7fff.
> >
> > Below is the minimal fixup that keeps
Take the new bus limit into account (when present) for IOVA allocations,
to accommodate those SoCs which integrate off-the-shelf IP blocks with
narrower interconnects such that the link between a device output and an
IOMMU input can truncate DMA addresses to even fewer bits than the
native size of
When an explicit DMA limit is described by firmware, we need to remember
it regardless of how drivers might subsequently update their devices'
masks. The new bus_dma_mask field does that.
Signed-off-by: Robin Murphy
---
drivers/of/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git
When an explicit DMA limit is described by firmware, we need to remember
it regardless of how drivers might subsequently update their devices'
masks. The new bus_dma_mask field does that.
Signed-off-by: Robin Murphy
---
drivers/acpi/arm64/iort.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Whilst the notion of an upstream DMA restriction is most commonly seen
via PCI host bridges saddled with a 32-bit native interface, a more
general version of the same issue can exist on complex SoCs where a bus
or point-to-point interconnect link carries fewer address bits between a
device and a
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
the dma_set_mask() API leads to that information getting lost when
well-behaved
On Tue, Jul 10, 2018 at 01:29:20PM +0100, Robin Murphy wrote:
>> What I've done is to:
>>
>> 1) provide the get_required_mask unconditionally in struct dma_map_ops
>> 2) default to what is the current dma_get_required_mask implementation
>> if nothing else is specified.
>
> Yeah, there's
On Wed, Jun 20, 2018 at 09:23:28AM +0200, Christoph Hellwig wrote:
> No, this is a mixup. I hadn't noticed one case was 0x0fff and
> the other 0x7fff.
>
> Below is the minimal fixup that keeps things as much as it was before.
IS the rest of the series now ok with you? Anything else I
On 10/07/18 12:39, Christoph Hellwig wrote:
On Wed, Jul 04, 2018 at 06:50:12PM +0100, Robin Murphy wrote:
As for the other mask-related hooks, standardise the arch override into
a Kconfig option, and also pull the generic implementation into the DMA
mapping code rather than having it hide away
On Mon, Jul 09, 2018 at 03:53:50PM +0100, Robin Murphy wrote:
> Oh, for sure, the generic fix would be the longer-term goal, this was just
> an expedient compromise because I want to get *something* landed for 4.19.
> Since in practice this is predominantly affecting arm64, doing the
>
On Wed, Jul 04, 2018 at 06:50:12PM +0100, Robin Murphy wrote:
> As for the other mask-related hooks, standardise the arch override into
> a Kconfig option, and also pull the generic implementation into the DMA
> mapping code rather than having it hide away in the platform bus code.
I compared
On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
> Hello, Marek.
>
> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
> > cma_alloc() function doesn't really support gfp flags other than
> > __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>
> Although gfp_mask isn't used in
Hello, Marek.
2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
> cma_alloc() function doesn't really support gfp flags other than
> __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
Although gfp_mask isn't used in cma_alloc() except no_warn, it can be used
in
22 matches
Mail list logo
