On 2020/10/21 20:34, Nicolas Saenz Julienne wrote:
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that
On Sat, Aug 3, 2019 at 9:26 AM Christoph Hellwig wrote:
>
> See the discussion at:
>
> https://lists.linuxfoundation.org/pipermail/iommu/2019-August/037716.html
>
> Just curious, what driver do you use that uses dma_mmap_coherent on
> x86?
> ___
> iommu
On 24.02.20 18:16, Christoph Hellwig wrote:
On Sat, Feb 22, 2020 at 02:07:58PM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
AFAIU you have a positive attitude towards the idea, that
!F_VIRTIO_PLATFORM implies 'no DMA API is used by virtio'
On Tue, Oct 27, 2020 at 10:53:47PM -0700, John Stultz wrote:
> On Mon, Jul 13, 2020 at 1:41 PM Will Deacon wrote:
> > On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
> > > On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
> > > > On Thu, Jul 09, 2020 at 08:28:45PM -0700, John
On 2020-10-28 13:51, Will Deacon wrote:
On Tue, Oct 27, 2020 at 10:53:47PM -0700, John Stultz wrote:
On Mon, Jul 13, 2020 at 1:41 PM Will Deacon wrote:
On Fri, Jul 10, 2020 at 03:21:53PM -0700, John Stultz wrote:
On Fri, Jul 10, 2020 at 12:54 AM Will Deacon wrote:
On Thu, Jul 09, 2020 at
On 20-10-28 13:05:05, Lu Baolu wrote:
> Hi Yi,
>
> On 10/28/20 9:36 AM, Yi Sun wrote:
> >From: "Liu, Yi L"
>
> Can you please add some description here? How far should this patch back
> ported? A Fixes tag?
>
Sure. Will add description and Fixes tag.
> Best regards,
> baolu
>
> >
>
Thanks! Will do the modifications according to your comments in next
version.
On 20-10-28 12:50:37, Lu Baolu wrote:
> Hi Yi,
>
> On 10/28/20 9:36 AM, Yi Sun wrote:
> >From: Liu Yi L
> >
> >Should get correct sid and set it into sdev. Because we execute
> >'sdev->sid != req->rid' in the loop of
If calling find_domain() for a device which hasn't been probed by the
iommu core, below kernel NULL pointer dereference issue happens.
[ 362.736947] BUG: kernel NULL pointer dereference, address: 0038
[ 362.743953] #PF: supervisor read access in kernel mode
[ 362.749115] #PF:
Hi Parav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on rdma/for-next]
[also build test ERROR on v5.10-rc1 next-20201028]
[cannot apply to hch-configfs/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
So far we have been using huge DMA windows to map all the RAM available.
The RAM is normally mapped to the VM address space contiguously, and
there is always a reasonable upper limit for possible future hot plugged
RAM which makes it easy to map all RAM via IOMMU.
Now there is persistent memory
This allows mixing direct DMA (to/from RAM) and
IOMMU (to/from apersistent memory) on the PPC64/pseries
platform.
This replaces https://lkml.org/lkml/2020/10/27/418
which replaces https://lkml.org/lkml/2020/10/20/1085
This is based on sha1
4525c8781ec0 Linus Torvalds "scsi: qla2xxx: remove
At the moment we allow bypassing DMA ops only when we can do this for
the entire RAM. However there are configs with mixed type memory
where we could still allow bypassing IOMMU in most cases;
POWERPC with persistent memory is one example.
This adds an arch hook to determine where bypass can
On 28/10/2020 03:48, Christoph Hellwig wrote:
+static inline bool dma_handle_direct(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle >= dev->archdata.dma_offset;
+}
This won't compile except for powerpc, and directly accesing arch members
in common code is a bad idea.
Hi,
On Wed, Oct 28, 2020 at 09:36:57AM +0800, Yi Sun wrote:
> From: Jacob Pan
>
> original code fails when LAST_PAGE is set in flags.
LAST_PAGE is not documented to be a valid flags for page_response.
So isn't failing the right thing to do?
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu
On Wed, Oct 28, 2020 at 06:00:29PM +1100, Alexey Kardashevskiy wrote:
> At the moment we allow bypassing DMA ops only when we can do this for
> the entire RAM. However there are configs with mixed type memory
> where we could still allow bypassing IOMMU in most cases;
> POWERPC with persistent
On Wed, Oct 28, 2020 at 05:55:23PM +1100, Alexey Kardashevskiy wrote:
>
> It is passing an address of the end of the mapped area so passing a page
> struct means passing page and offset which is an extra parameter and we do
> not want to do anything with the page in those hooks anyway so I'd
On 27/10/2020 11:26, Shameer Kolothum wrote:
The series adds support to IORT RMR nodes specified in IORT
Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
ranges that are used by endpoints and require a unity mapping
in SMMU.
Hi Shameer,
I've also been taking a look at RMR,
On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
> From: Thomas Gleixner
>
> Use the x86 shadow structs in msi_msg instead of the macros.
>
> Signed-off-by: Thomas Gleixner
> Signed-off-by: David Woodhouse
> ---
> drivers/pci/controller/vmd.c | 9 -
> 1 file changed,
On 29/10/2020 04:22, Christoph Hellwig wrote:
On Wed, Oct 28, 2020 at 06:00:29PM +1100, Alexey Kardashevskiy wrote:
At the moment we allow bypassing DMA ops only when we can do this for
the entire RAM. However there are configs with mixed type memory
where we could still allow bypassing
On 29/10/2020 11:40, Michael Ellerman wrote:
Alexey Kardashevskiy writes:
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index e4198700ed1a..91112e748491 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++
Alexey Kardashevskiy writes:
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index e4198700ed1a..91112e748491 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -,11 +1112,13 @@ static
On Wed, Oct 28, 2020 at 10:13:52PM +0100, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 13:49, Kees Cook wrote:
> > On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
> >> + memset(, 0, sizeof(*msg);
> >
> > This should be:
> >
> > + memset(msg, 0, sizeof(*msg);
>
>
At the moment we allow bypassing DMA ops only when we can do this for
the entire RAM. However there are configs with mixed type memory
where we could still allow bypassing IOMMU in most cases;
POWERPC with persistent memory is one example.
This adds an arch hook to determine where bypass can
So far we have been using huge DMA windows to map all the RAM available.
The RAM is normally mapped to the VM address space contiguously, and
there is always a reasonable upper limit for possible future hot plugged
RAM which makes it easy to map all RAM via IOMMU.
Now there is persistent memory
This allows mixing direct DMA (to/from RAM) and
IOMMU (to/from apersistent memory) on the PPC64/pseries
platform.
This replaces https://lkml.org/lkml/2020/10/28/929
which replaces https://lkml.org/lkml/2020/10/27/418
which replaces https://lkml.org/lkml/2020/10/20/1085
This is based on sha1
On 29/10/2020 04:21, Christoph Hellwig wrote:
On Wed, Oct 28, 2020 at 05:55:23PM +1100, Alexey Kardashevskiy wrote:
It is passing an address of the end of the mapped area so passing a page
struct means passing page and offset which is an extra parameter and we do
not want to do anything
AMD IOMMU requires 4k-aligned pages for the event log, the PPR log,
and the completion wait write-back regions. However, when allocating
the pages, they could be part of large mapping (e.g. 2M) page.
This causes #PF due to the SNP RMP hardware enforces the check based
on the page level for these
On Wed, Oct 28 2020 at 13:49, Kees Cook wrote:
> On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
>> +memset(, 0, sizeof(*msg);
>
> This should be:
>
> + memset(msg, 0, sizeof(*msg);
memset(msg, 0, sizeof(*msg));
Then it compiles _and_ is correct :)
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'apic' variable to the more
On Wed, Oct 28, 2020 at 01:39:17PM +0200, Oded Gabbay wrote:
> On Sat, Aug 3, 2019 at 9:26 AM Christoph Hellwig wrote:
> >
> > See the discussion at:
> >
> > https://lists.linuxfoundation.org/pipermail/iommu/2019-August/037716.html
> >
> > Just curious, what driver do you use that uses
On Tue, Oct 27, 2020 at 12:52:30PM +, Parav Pandit wrote:
>
> > From: h...@lst.de
> > Sent: Tuesday, October 27, 2020 1:41 PM
> >
> > On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote:
> > > Hi Christoph,
> > >
> > > > From: Jakub Kicinski
> > > > Sent: Saturday, October 24,
On Wed, Oct 28, 2020 at 07:38:04PM +0200, Oded Gabbay wrote:
> > > https://lkml.org/lkml/2020/8/29/252)
> > > Since then, we are plagued by the kernel log message that gavin has
> > > mentioned, as we are mostly running in our C/I environment with 5.4.
> > > I wondered if you know if there was any
On Wed, Oct 28, 2020 at 03:24:03PM +0100, Alexander Graf wrote:
> On 24.02.20 18:16, Christoph Hellwig wrote:
> > On Sat, Feb 22, 2020 at 02:07:58PM -0500, Michael S. Tsirkin wrote:
> > > On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
> > > > AFAIU you have a positive attitude
Hi Steve,
> -Original Message-
> From: Steven Price [mailto:steven.pr...@arm.com]
> Sent: 28 October 2020 16:44
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org; de...@acpica.org
> Cc:
Hi,
On Tue, 2020-10-27 at 11:26 +, Shameer Kolothum wrote:
...
> @@ -1647,6 +1667,100 @@ static void __init iort_enable_acs(struct
> acpi_iort_node *iort_node)
> #else
> static inline void iort_enable_acs(struct acpi_iort_node *iort_node)
> { }
> #endif
> +static int
On Wed, Oct 28, 2020 at 7:39 PM Christoph Hellwig wrote:
>
> On Wed, Oct 28, 2020 at 07:38:04PM +0200, Oded Gabbay wrote:
> > > > https://lkml.org/lkml/2020/8/29/252)
> > > > Since then, we are plagued by the kernel log message that gavin has
> > > > mentioned, as we are mostly running in our C/I
On Wed, Oct 28, 2020 at 7:31 PM Christoph Hellwig wrote:
>
> On Wed, Oct 28, 2020 at 01:39:17PM +0200, Oded Gabbay wrote:
> > On Sat, Aug 3, 2019 at 9:26 AM Christoph Hellwig wrote:
> > >
> > > See the discussion at:
> > >
> > >
Hi Erik,
[Adding back the original MLs + CC list]
> -Original Message-
> From: Kaneda, Erik [mailto:erik.kan...@intel.com]
> Sent: 28 October 2020 18:20
> To: Shameerali Kolothum Thodi ;
> Moore, Robert ; Wysocki, Rafael J
>
> Subject: RE: [Devel] [RFC PATCH 1/4] ACPICA: IORT: Update
38 matches
Mail list logo
