7c0802a6 6000 7c0802a6 fba1ffe8
fbc1fff0 fbe1fff8 7cbf2b78 38a0 7cdd3378 f8010010 f821ffc1
4bff95d1 6000 7c7e1b79
[ 981.124374] ---[ end trace ]---
Thanks and Regards
On 1/31/24 16:18, Robin Murphy wrote:
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings,
[mainline] [linux-next] [6.8-rc1] [DLPAR] OOps kernel crash after
performing dlpar remove test
--- Traces ---
[58563.146236] BUG: Unable to handle kernel data access at
0x6b6b6b6b6b6b6b83
[58563.146242] Faulting instruction
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c
On 2023-09-26 20:34, Robin Murphy wrote:
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason
On 2023-06-01 20:46, Jason Gunthorpe wrote:
On Thu, Jun 01, 2023 at 08:37:45PM +0100, Robin Murphy wrote:
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY
On 2023-05-16 01:00, Jason Gunthorpe wrote:
These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively
allows them to support that mode.
The prior work to require default_domains makes this safe because every
one of these drivers is either compilation incompatible with
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY mode.
Unfortunately it was the other way around - it's the call to
fsl_setup_liodns() from fsl_pamu_probe()
On 2023-05-16 01:00, Jason Gunthorpe wrote:
This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING
domain, so it saves a few lines in a lot of drivers needlessly checking
the type.
More critically, this allows us to sweep out all the
IOMMU_DOMAIN_UNMANAGED and IOMMU_DOMAIN_DMA
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the
same stuff, the way they relate to the IOMMU core is quiet different.
dma-iommu.c expects the core code to setup an UNMANAGED domain (of type
IOMMU_DOMAIN_DMA) and then
On 2023-05-16 01:00, Jason Gunthorpe wrote:
The PLATFORM domain will be set as the default domain and attached as
normal during probe. The driver will ignore the initial attach from a NULL
domain to the PLATFORM domain.
After this, the PLATFORM domain's attach_dev will be called whenever we
On 31/03/2023 3:00 pm, Arnd Bergmann wrote:
On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote:
On 2023-03-27 13:13, Arnd Bergmann wrote:
[ HELP NEEDED: can anyone confirm that it is a correct assumption
on arm that a cache-coherent device writing to a page always results
in it being
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use
On 2023-02-22 13:37, Jiaxun Yang wrote:
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in
On 2023-02-22 13:04, Jiaxun Yang wrote:
2023年2月22日 12:55，Robin Murphy 写道：
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the main purpose of this patch is to fix MIPS’s broken per-device coherency.
On 2023-02-21 17:58, Christoph Hellwig wrote:
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
dma_default_coherent can be useful for determine default coherency
even on arches without noncoherent support.
How?
Indeed, "default" is conceptually meaningless when there is no
On 2022-07-05 07:22, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of
t.
For now, though, I agree with the simple change that's clear and easy to
reason about:
Reviewed-by: Robin Murphy
Thanks,
Robin.
Cc: Maciej W. Rozycki
Cc: Matt Wang
Cc: Khalid Aziz
Signed-off-by: Arnd Bergmann
---
drivers/scsi/BusLogic.c | 27 ---
drivers/
at
the 7-instruction sequence that Mark and I had come up with and certain
that it could be shortened still. Kinda sad to see it go, but at the
same time, glad that it can.
Acked-by: Robin Murphy
On a defconfig build, this saves over 28KB of .text.
Not to mention saving those "WTF is
On 2021-10-15 07:36, meng...@windriver.com wrote:
From: Meng Li
When enable debug kernel configs,there will be calltrace as below:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id+0x20/0x30
CPU: 6 PID: 1 Comm: swapper/0 Not tainted
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a
On 2021-07-16 07:33, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
@@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
scatterlist *sg,
else
ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
On 2021-07-16 07:32, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
@@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
iommu_full(dev, pages << PAGE_SHIFT, dir);
for_each_sg(sg, s, nents,
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c|
On 2021-03-16 15:38, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f1e38526d5bd40..996dfdf9d375dd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
s/Synopsys/Synopsis/ .two different places.
Erm, that is definitely not a typo... :/
..and for some unknown reason it introduce a empty line deleted and added
back.
Presumably your editor is configured to trim trailing whitespace on save.
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the author
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and
On 2021-01-21 15:48, Rob Herring wrote:
On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy
wrote:
On 2021-01-20 21:31, Rob Herring wrote:
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy
wrote:
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang
wrote
On 2021-01-20 21:31, Rob Herring wrote:
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy wrote:
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the device
On 2021-01-13 12:48, Christoph Hellwig wrote:
+#ifdef CONFIG_SWIOTLB
+ if (unlikely(dev->dma_io_tlb_mem))
+ return swiotlb_alloc(dev, size, dma_handle, attrs);
+#endif
Another place where the dma_io_tlb_mem is useful to avoid the ifdef.
-phys_addr_t
On 2021-01-13 17:43, Florian Fainelli wrote:
On 1/13/21 7:27 AM, Robin Murphy wrote:
On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
Hi All,
On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
On 1/5/21 7:41 PM, Claire Chang wrote:
Add the initialization function to create
On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
Hi All,
On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
On 1/5/21 7:41 PM, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes in the device tree.
Signed-off-by:
On 2021-01-07 17:57, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
Hi Greg and Konrad,
This change is intended to be non-arch specific. Any arch that lacks DMA access
control and has devices not behind an IOMMU can make use of it. Could you share
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$
On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Hmm, this is
[since this is in my inbox...]
On 2020-03-19 10:28 am, Borislav Petkov wrote:
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
So NAK - if you
On 2019-11-26 6:51 pm, Nicolas Saenz Julienne wrote:
On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote:
On 25/11/2019 7:44 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
Just as an FYI, this introduces a warning on arm32 allyesconfig for me
On 25/11/2019 7:44 am, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
and/or we need to use min_t and
er accesible DMA address.
^^ super-nit only because I can't not see my editor currently
highlighting the typo: "accessible"
Regardless of that though,
Reviewed-by: Robin Murphy
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- rework ACPI code to avoid divergence
On 21/11/2019 7:34 am, Christoph Hellwig wrote:
Robin, does this mean you ACK this series for the powerpc use case?
Yeah, I think we've nailed down sufficient justification now for having
a generalised flag, so at that point it makes every bit of sense to
convert PPC's private equivalent.
On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit
On 16/11/2019 6:22 am, Christoph Hellwig wrote:
On Fri, Nov 15, 2019 at 06:12:48PM +, Robin Murphy wrote:
And is that any different from where you would choose to "just" set a
generic bypass flag?
Same spots, as intel-iommu moves from the identify to a dma domain when
settin
On 19/11/2019 5:00 pm, Christoph Hellwig wrote:
On Tue, Nov 19, 2019 at 01:57:43PM +0100, Nicolas Saenz Julienne wrote:
Hi Rob & Christoph,
do you mind if I append v2 of this into my upcoming v3 RPi4 PCIe support
series, I didn't do it initially as I thought this was going to be a
contentious
On 19/11/2019 10:26 am, Marek Szyprowski wrote:
Hi Krzysztof,
On 19.11.2019 10:44, Krzysztof Kozlowski wrote:
On Tue, 19 Nov 2019 at 17:27, Marek Szyprowski wrote:
Hi Christoph,
On 13.11.2019 08:35, Christoph Hellwig wrote:
Currently each architectures that wants to override dma_to_phys
On 14/11/2019 7:41 am, Christoph Hellwig wrote:
On Wed, Nov 13, 2019 at 02:45:15PM +, Robin Murphy wrote:
In all honesty, this seems silly. If we can set a per-device flag to say
"oh, bypass these ops and use some other ops instead", then we can just as
easily simply give
On 2019-11-13 8:41 pm, Florian Fainelli wrote:
On 11/13/19 12:34 PM, Robin Murphy wrote:
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA
On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is
On 13/11/2019 1:37 pm, Christoph Hellwig wrote:
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve
() is introduced.
cc: Benjamin Herrenschmidt
cc: David Gibson
cc: Michael Ellerman
cc: Paul Mackerras
cc: Michael Roth
cc: Alexey Kardashevskiy
cc: Paul Burton
cc: Robin Murphy
cc: Bartlomiej Zolnierkiewicz
cc: Marek Szyprowski
cc: Christoph Hellwig
Suggested-by: Michael S. Tsirkin
Signed-off-by: Ram
On 2019-10-08 9:38 am, Yunsheng Lin wrote:
On 2019/9/25 18:41, Peter Zijlstra wrote:
On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
From the discussion above, It seems making the node_to_cpumask_map()
NUMA_NO_NODE aware is the most feasible way to move forwad.
That's still
improvement in API terms.
For arm64,
Acked-by: Robin Murphy
Cheers,
Robin.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc
On 11/08/2019 09:05, Christoph Hellwig wrote:
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct
in follow up
patches.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Andrew Morton
Cc: Ard Biesheuvel
Cc: Chintan Pandya
Cc: Mike Rapoport
Cc: Jun Yao
Cc: Yu Zhao
Cc: Robin Murphy
Cc: Anshuman Khandual
Signed-off-by: David Hildenbrand
---
arch/arm64/mm/mmu.c | 19
On 31/05/2019 18:08, Christoph Hellwig wrote:
On Fri, May 31, 2019 at 06:03:30PM +0100, Robin Murphy wrote:
The thing needs to be completely redone as it abuses parts of the
iommu API in a completely unacceptable way.
`git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
:(
I guess one
On 31/05/2019 17:33, Christoph Hellwig wrote:
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
From: laurentiu.tu...@nxp.com
Date: Thu, 30 May 2019 17:19:45 +0300
Depends on this pull request:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
I'm not
ed-by: Dan Williams
Reviewed-by: Ira Weiny
Acked-by: Oliver O'Halloran
Reviewed-by: Anshuman Khandual
Signed-off-by: Robin Murphy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
arch/x86/Kconfig | 2 +-
ed-by: Dan Williams
Reviewed-by: Ira Weiny
Acked-by: Oliver O'Halloran
Reviewed-by: Anshuman Khandual
Signed-off-by: Robin Murphy
---
v2: Add review tags.
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
arch/x
ONE_DEVICE users have little chance of
functioning correctly without __HAVE_ARCH_PTE_DEVMAP, so let's clean
that up the same way as ARCH_HAS_PTE_SPECIAL and make it the proper
dependency so the real situation is clearer.
Signed-off-by: Robin Murphy
---
arch/powerpc/Kconfig
cleanup.
Suggested-by: Jerome Glisse
Signed-off-by: Robin Murphy
---
include/linux/mm.h | 43 +--
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 76769749b5a5..d76dfb7ac617 100644
--- a/include
ge]
Acked-by: Michal Hocko
Reviewed-by: David Hildenbrand
Signed-off-by: Robin Murphy
Signed-off-by: Anshuman Khandual
---
include/linux/mmzone.h | 1 +
kernel/memremap.c | 10 --
mm/hmm.c | 2 --
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/inc
arm64
pagetable code, I'm wary of conflicts and cross-tree dependencies for
our actual ARCH_HAS_PTE_DEVMAP implementation. Thus it would be nice if
these could be picked up for 5.2 via mm or nvdimm as appropriate, such
that we can then handle the devmap patch itself via arm64 next cycle.
Robin.
Robin
On 12/04/2019 11:26, John Garry wrote:
On 09/04/2019 13:53, Zhen Lei wrote:
Currently the IOMMU dma contains 3 modes: passthrough, lazy, strict. The
passthrough mode bypass the IOMMU, the lazy mode defer the invalidation
of hardware TLBs, and the strict mode invalidate IOMMU hardware TLBs
On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11
m/device memory" to better explain the WARN...
Either way, though,
Reviewed-by: Robin Murphy
- BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
+ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
+ return DMA_MAPPING_ERROR;
if (dma_is_direct(ops))
addr = dma
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation
On 10/12/2018 14:21, Rafael David Tinoco wrote:
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at
Hi Andrew,
On 26/11/2018 11:12, Andrew Murray wrote:
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute
On 19/11/2018 14:18, Ramon Fried wrote:
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
-* Because 32-bit DMA masks are so common we expect every architecture
-* to be able to satisfy them - either by not
On 08/11/2018 15:59, Thomas Petazzoni wrote:
Hello,
I'm jumping into the discussion, but I clearly don't have all the
context of the discussion.
On Thu, 8 Nov 2018 15:54:31 +, Robin Murphy wrote:
This seems like a semantic different between the two representations, or am
I missing
On 01/11/2018 19:32, Rob Herring wrote:
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon wrote:
Hi Rob,
On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote:
Convert ARM PMU binding to DT schema format using json-schema.
Cc: Will Deacon
Cc: Mark Rutland
Cc:
On 04/10/18 00:48, Alexander Duyck wrote:
It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
<= physiscal memory size") the logic of the test was changed from a "<" to
a ">=" however I don't see any reason for that change. I am assuming that
there was some additional
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
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
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
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) -
quot;theory" it's also ok to have a mask < ZONE_DMA_BITS as long as it's
big enough to fit all memory :-)
Yeah, we could do that.
FWIW I like it even if just for looking slightly more readable. With
that fixup,
Reviewed-by: Robin Murphy
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 ++-
Ah right, in that situation we should probably end up here anyway, so
that's good enough - definitely not worth any more #ifdeffery above.
Nits aside,
Reviewed-by: Robin Murphy
}
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
- dev->coherent_dma_mask < DMA_
max_dma > 0. Otherwise,
Reviewed-by: Robin Murphy
+}
+
static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
{
- dma_addr_t addr = force_dma_unencrypted() ?
- __phys_to_dma(dev, phys) : phys_to_dma(dev, phys);
- return addr +
On 25/09/18 21:16, Christoph Hellwig wrote:
Looking at the code I think this commit is simply broken for
architectures not using arch_setup_dma_ops, but instead setting up
the dma ops through arch specific magic.
I'll revert the patch.
Ugh, sorry about missing that too. Ack to a revert -
1 - 100 of 159 matches
Mail list logo
