On Thu, Feb 14, 2019 at 7:40 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Feb 14, 2019 at 1:32 PM Robin Murphy wrote:
> >
> > Hi Doug,
> >
> > On 2019-02-14 8:44 pm, Douglas Anderson wrote:
> > > Right now the only way to disable the iommu bypass for the ARM SMMU is
> > > with the kernel command l
On 14/02/2019 20:14, Alex Williamson wrote:
>> This patch series extends both IOMMU and vfio components to support
>> mdev device passing through when it could be isolated and protected
>> by the IOMMU units. The first part of this series (PATCH 1/09~6/09)
>> adds the interfaces and implementation
The addresses within a single page are always contiguous, so it's
not so necessary to always allocate one single page from CMA area.
Since the CMA area has a limited predefined size of space, it may
run out of space in heavy use cases, where there might be quite a
lot CMA pages being allocated for
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:58 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:57 +0100
> We've been moving to a model where the device just sets the DMA mask
> supported by it, instead of having to fallback to something it thinks
> the platform might support. Sparc64 is the remaining holdout forcing
> drivers to supply
From: Christoph Hellwig
Date: Fri, 15 Feb 2019 15:45:56 +0100
> Do the quirk first in the dma_supported routines, as we don't need
> any of the other checks for it, and remove the duplicate mask checking
> that is already done by the callers.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Davi
Hi Jacob, Lu,
On 30/01/2019 19:05, Jacob Pan wrote:
> On Mon, 12 Nov 2018 14:44:57 +0800
> Lu Baolu wrote:
>
>> This adds APIs for IOMMU drivers and device drivers to manage
>> the PASIDs used for DMA transfer and translation. It bases on
>> I/O ASID allocator for PASID namespace management and
On 2019-02-14 12:58 p.m., Robin Murphy wrote:
> Hmm, having felt brave enough to take a closer look, it might actually be as
> simple as this - Dave, are you able to give the diff below a spin?
>
> Robin.
>
> ->8-
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 7f59535
On 2019-02-15 10:22 a.m., John David Anglin wrote:
> On 2019-02-14 12:58 p.m., Robin Murphy wrote:
>> Hmm, having felt brave enough to take a closer look, it might actually be as
>> simple as this - Dave, are you able to give the diff below a spin?
> Still crashes but in slightly different spot:
>
On 2019-02-14 12:58 p.m., Robin Murphy wrote:
> Hmm, having felt brave enough to take a closer look, it might actually be as
> simple as this - Dave, are you able to give the diff below a spin?
Still crashes but in slightly different spot:
[ 0.00] Booting Linux on physical CPU 0x00
We don't require drivers to guess a DMA mask that might actually
match the system capabilities any more, so fix up the documentation
to clear this up.
Signed-off-by: Christoph Hellwig
---
Documentation/DMA-API-HOWTO.txt | 121 +++-
1 file changed, 41 insertions(+), 80
Do the quirk first in the dma_supported routines, as we don't need
any of the other checks for it, and remove the duplicate mask checking
that is already done by the callers.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/iommu.c | 7 +++---
arch/sparc/kernel/kernel.h| 6 -
Hi all,
this series finishes off converting our dma mask model to split between
device capabilities (dev->dma_mask and dev->coherent_dma_mask) and system
limitations (dev->bus_dma_mask). We already accept larger than required
masks in most dma_map_ops implementation, in case of x86 and
implementa
We've been moving to a model where the device just sets the DMA mask
supported by it, instead of having to fallback to something it thinks
the platform might support. Sparc64 is the remaining holdout forcing
drivers to supply a matching mask. Change dma_4v_supported to just
check if the supplied
There is no harm in setting a 64-bit mask even if we don't need it,
and the current ccio code is one of the few place in the kernel
still rejecting larger than required DMA masks.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/ccio-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
We've been moving to a model where the device just sets the DMA mask
supported by it, instead of having to fallback to something it thinks
the platform might support. Sparc64 is the remaining holdout forcing
drivers to supply a matching mask. Change dma_4u_supported to just
check if the supplied
Hi
> > > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> > > index 7a4529c..cebf56d 100644
> > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > @@ -756,6 +756,9 @@ static int ipmmu_init_platform_device(struct device
> > > *dev,
> > >
> > >
17 matches
Mail list logo
