> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, September 27, 2018 11:06 PM
>
> On 26/09/2018 19:01, Jacob Pan wrote:
> > On Mon, 24 Sep 2018 13:07:47 +0100
> > Jean-Philippe Brucker wrote:
> >
> >> On 23/09/2018 04:05, Lu Baolu wrote:
> >> > Hi,
> >> >
> >>
On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > I'm not sure this is entirely right.
> >
> > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > fail if you allocate something above 1G (w
We seem to need to set either this or CFCFG (stall), otherwise gpu
faults trigger problems with other in-flight transactions from the
GPU causing CP errors, etc.
In the ARM SMMU spec, the 'Hit under previous context fault' bit is
described as:
'0' - Stall or terminate subsequent transactions in
This way an architecture with less than 4G of RAM can support dma_mask
smaller than 32-bit without a ZONE_DMA. Apparently that is a common
case on powerpc.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
kernel/dma/direct.c | 28
1 file changed, 16 i
This is somewhat modelled after the powerpc version, and differs from
the legacy fallback in use fls64 instead of pointlessly splitting up the
address into low and high dwords and in that it takes (__)phys_to_dma
into account.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
Rev
We need to take the DMA offset and encryption bit into account when
selecting a zone. User the opportunity to factor out the zone
selection into a helper for reuse.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
kernel/dma/direct.c | 31 +--
1 file c
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
kernel/dma/direct.c| 21 +++--
2 file
Hi all,
the dma_get_required_mask dma API implementation has always been a little
odd, in that we by default don't wire it up struct dma_map_ops, but
instead hard code a default implementation. powerpc and ia64 override
this default and either call a method or otherwise duplicate the default.
Th
This save some duplication for ia64, and makes the interface more
general. In the long run we want each dma_map_ops instance to fill this
out, but this will take a little more prep work.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt [powerpc bits]
---
arch/ia64/include/asm/
On Thu, 20 Sep 2018 18:00:43 +0100
Jean-Philippe Brucker wrote:
> + /*
> + * When removing a PASID, the device driver tells the device
> to stop
> + * using it, and flush any pending fault to the IOMMU. In
> this flush
> + * callback, the IOMMU driver makes sure that there are
On Mon, 24 Sep 2018 03:41:39 +0300, Dmitry Osipenko wrote:
> Splitting GART and Memory Controller wasn't a good decision that was made
> back in the day. Given that the GART driver wasn't ever been used by
> anything in the kernel, we decided that it will be better to correct the
> mistakes of the
On Mon, Sep 24, 2018 at 11:55:30AM +0200, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 03:41:39AM +0300, Dmitry Osipenko wrote:
> > Splitting GART and Memory Controller wasn't a good decision that was made
> > back in the day. Given that the GART driver wasn't ever been used by
> > anything in t
On 27/09/18 17:27, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 05:14:56PM +0100, Robin Murphy wrote:
This just seemed more readable to me than min_not_zero, but if others
prefer min_not_zero I can switch.
Nah, just checking whether there were any intentionally different
assumptions compar
On Thu, Sep 27, 2018 at 05:14:56PM +0100, Robin Murphy wrote:
>> This just seemed more readable to me than min_not_zero, but if others
>> prefer min_not_zero I can switch.
>
> Nah, just checking whether there were any intentionally different
> assumptions compared to the couple of other places in
On 27/09/18 16:32, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:58:04PM +0100, Robin Murphy wrote:
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3c404e33d946..64466b7ef67b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma
On Thu, Sep 27, 2018 at 04:38:31PM +0100, Robin Murphy wrote:
> On 27/09/18 16:30, Christoph Hellwig wrote:
>> On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
+static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
dma_mask,
+ u64 *phys_mask)
>>>
On 27/09/18 16:30, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
+static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
dma_mask,
+ u64 *phys_mask)
+{
+ if (force_dma_unencrypted())
+ *phys_mask = __dma_to
On 27/09/18 16:28, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:12:25PM +0100, Robin Murphy wrote:
+u64 dma_direct_get_required_mask(struct device *dev)
+{
+ u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
+
+ return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
On Thu, Sep 27, 2018 at 03:58:04PM +0100, Robin Murphy wrote:
>> }
>> #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> index 3c404e33d946..64466b7ef67b 100644
>> --- a/kernel/dma/direct.c
>> +++ b/kernel/dma/direct.c
>> @@ -43,10 +43,11 @@
On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
>> +static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
>> dma_mask,
>> +u64 *phys_mask)
>> +{
>> +if (force_dma_unencrypted())
>> +*phys_mask = __dma_to_phys(dev, dma_mask);
>> +else
>>
On Thu, Sep 27, 2018 at 03:12:25PM +0100, Robin Murphy wrote:
>> +u64 dma_direct_get_required_mask(struct device *dev)
>> +{
>> +u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
>> +
>> +return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
>
> I think that may as well just use
[ oops, I should have looked at the replies first, now I see Ben already
had the same thing to say about #3... ]
On 27/09/18 14:49, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
-* to be able to satisfy them - either by not supporting
On 26/09/2018 19:01, Jacob Pan wrote:
> On Mon, 24 Sep 2018 13:07:47 +0100
> Jean-Philippe Brucker wrote:
>
>> On 23/09/2018 04:05, Lu Baolu wrote:
>> > Hi,
>> >
>> > On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:
>> >> Add bind() and unbind() operations to the IOMMU API. Bind()
>> >> re
On 20/09/18 19:52, Christoph Hellwig wrote:
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
kernel/dma/di
On 20/09/18 19:52, Christoph Hellwig wrote:
We need to take the DMA offset and encryption bit into account when
selecting a zone. User the opportunity to factor out the zone
selection into a helper for reuse.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 31 +
On 20/09/18 19:52, Christoph Hellwig wrote:
This is somewhat modelled after the powerpc version, and differs from
the legacy fallback in use fls64 instead of pointlessly splitting up the
address into low and high dwords and in that it takes (__)phys_to_dma
into account.
Signed-off-by: Christoph
unicore32 is a bog standard 32-bit port without larger physical address
space, highmem or any other obvious addressing limitation. There should
be no need to bounce buffer using swiotlb.
Signed-off-by: Christoph Hellwig
---
Guan, can you double check my assumptions? I really can't find a
reaso
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
> > -* to be able to satisfy them - either by not supporting more physical
> > -* memory, or by providing a ZONE_DMA32. If neither is the case, the
> > -* architecture needs to use an IOMMU instead of the direct ma
On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> I'm not sure this is entirely right.
>
> Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> fail if you allocate something above 1G (which is legit for
> ZONE_DMA32).
And then we will try GFP_DMA further
On 27/09/2018 04:22, Liu, Yi L wrote:
>> For the "classic" vfio-pci case, "SVA in guest" still means giving the
>> guest control over the whole PASID table.
>
> No, if giving guest control over the whole PASID table, it means guest may
> have
> its own PASID namespace. right? And for vfio-mdev ca
On Wed, Sep 26, 2018 at 8:52 AM, Sedat Dilek wrote:
> On Tue, Sep 25, 2018 at 7:01 PM, Jordan Glover
> wrote:
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, September 25, 2018 1:57 PM, Joerg Roedel wrote:
>>
>>> Lu,
>>>
>>> can you please have a look at this problem?
>>>
>>> On Wed, Sep 05,
On Wed, Sep 26, 2018 at 8:57 PM Robin Murphy wrote:
>
> On 30/08/18 15:45, Vivek Gautam wrote:
> > From: Sricharan R
> >
> > The smmu needs to be functional only when the respective
> > master's using it are active. The device_link feature
> > helps to track such functional dependencies, so that
On 26/09/18 18:31, Ezequiel Garcia wrote:
On Tue, 2018-09-25 at 13:29 +0200, Joerg Roedel wrote:
On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote:
Printing verbosely via WARN macros and friends in interrupt handlers
is strongly discouraged. Drop them and use proper ratelimited
pr
On Wed, Sep 26, 2018 at 09:59:17PM +0200, Greg Kroah-Hartman wrote:
> Is this all now merged properly?
Yes, the fix for that was in the pull-request I sent recently.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https:/
34 matches
Mail list logo
