On Mon, Jun 14, 2021 at 2:16 PM Christoph Hellwig wrote:
>
> On Fri, Jun 11, 2021 at 11:26:46PM +0800, Claire Chang wrote:
> > + spin_lock_init(&mem->lock);
> > + for (i = 0; i < mem->nslabs; i++) {
> > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > +
> From: Alex Williamson
> Sent: Tuesday, June 15, 2021 12:28 AM
>
[...]
> > IOASID. Today the group fd requires an IOASID before it hands out a
> > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it
> > has a blocked DMA IOASID and is successefully joined to an iommu_fd.
>
> W
> From: Jason Gunthorpe
> Sent: Monday, June 14, 2021 9:38 PM
>
> On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
>
> > If a device can be always blocked from accessing memory in the IOMMU
> > before it's bound to a driver or more specifically before the driver
> > moves it to a new
> From: Alex Williamson
> Sent: Monday, June 14, 2021 11:23 AM
>
[...]
> > In the meantime, I'm thinking about another way whether group
> > security can be enforced in the iommu layer to relax the uAPI design.
> > If a device can be always blocked from accessing memory in the
> > IOMMU before it
On Mon, Jun 14, 2021 at 10:28:14AM -0600, Alex Williamson wrote:
> > To my mind it is these three things:
> >
> > 1. The device can only do DMA to memory put into its security context
>
> System memory or device memory, yes.
>
> Corollary: The IOMMU group defines the minimum set of devices wher
On Thu 10 Jun 16:44 CDT 2021, Rob Clark wrote:
> From: Rob Clark
>
> Add, via the adreno-smmu-priv interface, a way for the GPU to request
> the SMMU to stall translation on faults, and then later resume the
> translation, either retrying or terminating the current translation.
>
> This will be
> Right but we won't know until we profile the specific usecases or try them in
> generic workload to see if they affect the performance. Sure, over
> invalidation is
> a concern where multiple buffers can be mapped to same context and the cache
> is not usable at the time for lookup and such but
On Thu 10 Jun 16:44 CDT 2021, Rob Clark wrote:
> From: Jordan Crouse
>
> Use the new adreno-smmu-priv fault info function to get more SMMU
> debug registers and print the current TTBR0 to debug per-instance
> pagetables and figure out which GPU block generated the request.
>
Acked-by: Bjorn An
On 14/06/2021 18:19, Robin Murphy wrote:
We shouldn't need to keep IOMMU_CMD_LINE_STRICT at all now, since it
was only to prevent a driver's "default lazy" setting passed in here
from downgrading an explicitly-set strict mode.
With that cleaned up too,
Patch 1/5 mentions whether the invalid
On Thu 10 Jun 16:44 CDT 2021, Rob Clark wrote:
> From: Jordan Crouse
>
> Add a callback in adreno-smmu-priv to read interesting SMMU
> registers to provide an opportunity for a richer debug experience
> in the GPU driver.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
I presume
On Thu 10 Jun 16:44 CDT 2021, Rob Clark wrote:
> From: Jordan Crouse
>
> Call report_iommu_fault() to allow upper-level drivers to register their
> own fault handlers.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> Acked-by: Will Deacon
Reviewed-by: Bjorn Andersson
Regards,
On 2021-06-14 18:03, John Garry wrote:
On 14/06/2021 17:25, Robin Murphy wrote:
On 2021-06-11 13:20, John Garry wrote:
We only ever now set strict mode enabled in iommu_set_dma_strict(), so
just remove the argument.
Signed-off-by: John Garry
---
drivers/iommu/amd/init.c | 2 +-
drivers/
On 14/06/2021 17:25, Robin Murphy wrote:
On 2021-06-11 13:20, John Garry wrote:
We only ever now set strict mode enabled in iommu_set_dma_strict(), so
just remove the argument.
Signed-off-by: John Garry
---
drivers/iommu/amd/init.c | 2 +-
drivers/iommu/intel/iommu.c | 6 +++---
drivers
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 14 June 2021 11:06
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: j...@solid-run.com; Linuxarm ;
> steven.pr...@a
On 14/06/2021 15:57, Robin Murphy wrote:
Consolidating the flush queue logic also meant that the "iommu.strict"
option started taking effect on x86 as well. Make sure we document that.
Fixes: a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE")
Signed-off-by: Robin Murphy
I assumed
On Mon, 14 Jun 2021 11:07:11 -0300
Jason Gunthorpe wrote:
> On Sat, Jun 12, 2021 at 10:57:11AM -0600, Alex Williamson wrote:
> > On Fri, 11 Jun 2021 22:28:46 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote:
> > >
> > > > That's fin
On 2021-06-11 13:20, John Garry wrote:
We only ever now set strict mode enabled in iommu_set_dma_strict(), so
just remove the argument.
Signed-off-by: John Garry
---
drivers/iommu/amd/init.c| 2 +-
drivers/iommu/intel/iommu.c | 6 +++---
drivers/iommu/iommu.c | 5 ++---
include/l
On 2021-06-11 13:20, John Garry wrote:
From: Zhen Lei
First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the two config options in an choice, as they are mutually exclusive.
[jpg: Make choice betwee
On 2021-06-11 13:20, John Garry wrote:
As well as the default domain type, it's useful to know whether strict
or lazy for DMA domains, so add this info in a separate print.
The (stict/lazy) mode may be also set via iommu.strict earlyparm, but
this will be processed prior to iommu_subsys_init(),
On 6/14/21 8:47 AM, Roman Skakun wrote:
> Hey, Boris!
> Thanks for the review.
>
> I have an additional question about current implementation that disturbed me.
> I think, that we can have cases when mapped memory can not be
> physically contiguous.
> In order to proceed this correctly need to ap
On Mon, Jun 14, 2021 at 04:34:05PM +0100, Robin Murphy wrote:
>> Looking at the rmem_dma_device_init() -> dma_init_coherent_memory(), it
>> ends up calling memremap(MEMREMAP_WC) which would warn if it intersects
>> with system RAM regardless of the architecture. If the memory region is
>> nomap, it
On 2021-06-14 15:51, Catalin Marinas wrote:
On Mon, Jun 14, 2021 at 06:07:04PM +0800, Dong Aisheng wrote:
On Mon, Jun 14, 2021 at 4:36 PM Will Deacon wrote:
On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote:
Coherent dma on ARM64 also can't work with mapped system ram,
that means '
On Mon, Jun 14, 2021 at 10:04:06PM +0800, Tianyu Lan wrote:
> The pages in the hv_page_buffer array here are in the kernel linear
> mapping. The packet sent to host will contain an array which contains
> transaction data. In the isolation VM, data in the these pages needs to be
> copied to bounc
On Mon, Jun 14, 2021 at 02:49:51PM +0100, Robin Murphy wrote:
> FWIW, I think a better generalisation for this would be allowing
> set_memory_decrypted() to return an address rather than implicitly
> operating in-place, and hide all the various hypervisor hooks behind that.
Yes, something like t
On 2021-06-14 15:19, John Garry wrote:
On 14/06/2021 15:11, Robin Murphy wrote:
On 2021-06-14 08:53, John Garry wrote:
On 12/06/2021 03:22, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
@@ -453,8 +452,7 @@ static int __init intel_iommu_setup(char *str)
pr_warn("intel_io
Consolidating the flush queue logic also meant that the "iommu.strict"
option started taking effect on x86 as well. Make sure we document that.
Fixes: a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE")
Signed-off-by: Robin Murphy
---
Documentation/admin-guide/kernel-parameters.txt |
On Mon, Jun 14, 2021 at 06:07:04PM +0800, Dong Aisheng wrote:
> On Mon, Jun 14, 2021 at 4:36 PM Will Deacon wrote:
> > On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote:
> > > Coherent dma on ARM64 also can't work with mapped system ram,
> > > that means 'no-map' property must be specif
On 14/06/2021 15:11, Robin Murphy wrote:
On 2021-06-14 08:53, John Garry wrote:
On 12/06/2021 03:22, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
@@ -453,8 +452,7 @@ static int __init intel_iommu_setup(char *str)
pr_warn("intel_iommu=forcedac deprecated; use
iommu.force
On 2021-06-14 08:53, John Garry wrote:
On 12/06/2021 03:22, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
@@ -453,8 +452,7 @@ static int __init intel_iommu_setup(char *str)
pr_warn("intel_iommu=forcedac deprecated; use
iommu.forcedac instead\n");
iommu_dma_
On Sat, Jun 12, 2021 at 10:57:11AM -0600, Alex Williamson wrote:
> On Fri, 11 Jun 2021 22:28:46 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote:
> >
> > > That's fine for a serial port, but not a device that can do DMA.
> > > The entire point
On 6/14/2021 3:09 PM, Christoph Hellwig wrote:
On Mon, Jun 07, 2021 at 11:21:20PM +0800, Tianyu Lan wrote:
dma_map_single can only be used on page baked memory, and if this is
using page backed memory you wouldn't need to do thee phys_to_virt
tricks. Can someone explain the mess here in more
On 2021-06-07 07:43, Christoph Hellwig wrote:
On Sun, May 30, 2021 at 11:06:25AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
For Hyper-V isolation VM with AMD SEV SNP, the bounce buffer(shared memory)
needs to be accessed via extra address space(e.g address above bit39).
Hyper-V code may remap e
On 6/14/2021 9:37 PM, Tianyu Lan wrote:
On 6/14/2021 3:12 PM, Christoph Hellwig wrote:
On Mon, Jun 07, 2021 at 10:56:47PM +0800, Tianyu Lan wrote:
These addresses in extra address space works as system memory mirror.
The
shared memory with host in Isolation VM needs to be accessed via extra
On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
> If a device can be always blocked from accessing memory in the IOMMU
> before it's bound to a driver or more specifically before the driver
> moves it to a new security context, then there is no need for VFIO
> to track whether IOASIDf
On 6/14/2021 3:12 PM, Christoph Hellwig wrote:
On Mon, Jun 07, 2021 at 10:56:47PM +0800, Tianyu Lan wrote:
These addresses in extra address space works as system memory mirror. The
shared memory with host in Isolation VM needs to be accessed via extra
address space which is above shared gpa b
On 6/14/21 2:12 AM, Christoph Hellwig wrote:
> On Mon, Jun 07, 2021 at 10:56:47PM +0800, Tianyu Lan wrote:
>> These addresses in extra address space works as system memory mirror. The
>> shared memory with host in Isolation VM needs to be accessed via extra
>> address space which is above shared
On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
A user in Debian reported the above issue, which was reproducible with
5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
introduced the issue.
Sounds like it'
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 14 June 2021 11:23
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
> j...@8b
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 14 June 2021 12:23
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: j...@solid-run.com; Linuxarm ;
> steven.pr...@
Hey, Boris!
Thanks for the review.
I have an additional question about current implementation that disturbed me.
I think, that we can have cases when mapped memory can not be
physically contiguous.
In order to proceed this correctly need to apply some additional steps
to current implementation as
Hi Robin,
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 14 June 2021 12:15
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
On 2021-05-24 12:02, Shameer Kolothum wrote:
Add a helper function that retrieves RMR memory descriptors
associated with a given IOMMU. This will be used by IOMMU
drivers to setup necessary mappings.
Now that we have this, invoke it from the generic helper
interface.
Signed-off-by: Shameer Kolo
On 2021-05-24 12:02, Shameer Kolothum wrote:
Add support for parsing RMR node information from ACPI.
Find associated stream id and smmu node info from the
RMR node and populate a linked list with RMR memory
descriptors.
Signed-off-by: Shameer Kolothum
---
drivers/acpi/arm64/iort.c | 104 +
On 2021-05-26 17:36, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com]
Sent: 26 May 2021 08:53
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux-foundation.org
Cc:
On 2021-05-24 12:02, Shameer Kolothum wrote:
By default, disable_bypass is set and any dev without an iommu domain
installs STE with CFG_ABORT during arm_smmu_init_bypass_stes(). Introduce
a "bypass" flag to arm_smmu_write_strtab_ent() so that we can force it to
install CFG_BYPASS STE for specifi
On 2021-05-24 12:02, Shameer Kolothum wrote:
Check if there is any RMR info associated with the devices behind
the SMMUv3 and if any, install bypass STEs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMUv3 during probe().
Signed-off-by: S
Hi Will,
On Mon, Jun 14, 2021 at 4:36 PM Will Deacon wrote:
>
> [+Catalin]
>
> On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote:
> > Coherent dma on ARM64 also can't work with mapped system ram,
> > that means 'no-map' property must be specified in dts.
> > Add the missing check for A
On 2021-05-24 12:02, Shameer Kolothum wrote:
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMU during probe().
On 2021-06-13 08:40, Jon Nettleton wrote:
On Thu, Jun 3, 2021 at 1:51 PM Jon Nettleton wrote:
On Thu, Jun 3, 2021 at 1:27 PM Steven Price wrote:
On 03/06/2021 09:52, Jon Nettleton wrote:
On Mon, May 24, 2021 at 1:04 PM Shameer Kolothum
wrote:
From: Jon Nettleton
Check if there is any
[+Catalin]
On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote:
> Coherent dma on ARM64 also can't work with mapped system ram,
> that means 'no-map' property must be specified in dts.
> Add the missing check for ARM64 platforms as well.
> Besides 'no-map' checking, 'linux,dma-default' fe
On 12/06/2021 02:21, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
+config IOMMU_DEFAULT_LAZY
+ bool "lazy"
+ help
+ Support lazy mode, where for every IOMMU DMA unmap operation, the
+ flush operation of IOTLB and the free operation of IOVA are
deferred.
+ They are
On 12/06/2021 03:14, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2a71347611d4..4467353f981b 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -94,6 +94,7 @@ choice
prompt "IOMMU default DMA mode"
On 12/06/2021 03:22, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
@@ -453,8 +452,7 @@ static int __init intel_iommu_setup(char *str)
pr_warn("intel_iommu=forcedac deprecated; use
iommu.forcedac instead\n");
iommu_dma_forcedac = true;
} else if (!s
On 12/06/2021 03:23, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ccbd5d4c1a50..146cb71c7441 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -350,10 +350,9 @@ static int __init iommu_dma_setup(char *str)
On Mon, Jun 07, 2021 at 10:56:47PM +0800, Tianyu Lan wrote:
> These addresses in extra address space works as system memory mirror. The
> shared memory with host in Isolation VM needs to be accessed via extra
> address space which is above shared gpa boundary.
Why?
__
On Mon, Jun 07, 2021 at 11:21:20PM +0800, Tianyu Lan wrote:
>> dma_map_single can only be used on page baked memory, and if this is
>> using page backed memory you wouldn't need to do thee phys_to_virt
>> tricks. Can someone explain the mess here in more detail?
>
> Sorry. Could you elaborate the
56 matches
Mail list logo
