> From: Lu Baolu
> Sent: Tuesday, March 29, 2022 1:38 PM
>
> Use this field to save the pasid/ssid bits that a device is able to
> support with its IOMMU hardware. It is a generic attribute of a device
> and lifting it into the per-device dev_iommu struct makes it possible
> to allocate a PASID f
On Tue, Mar 29, 2022 at 10:14:36AM +0530, Ashish Mhetre wrote:
> Tegra234 has 2 pairs of ARM MMU-500 instances. Each pair is used
> together and should be programmed identically.
> Add compatible string of Tegra234 iommu nodes in arm_smmu_impl_init()
> so that arm-smmu-nvidia implementation will be
From: Yong Wu
[ Upstream commit 2fb0feed51085db77606de9b9477c96894328809 ]
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already crea
From: Yong Wu
[ Upstream commit 822a2ed8c606caf6a11b1a180b8e46292bd77d71 ]
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_ini
From: Yong Wu
[ Upstream commit 635319a4a7444ca97124d781cd96deb277ff4d40 ]
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1
From: Yong Wu
[ Upstream commit 822a2ed8c606caf6a11b1a180b8e46292bd77d71 ]
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_ini
From: Yong Wu
[ Upstream commit 2fb0feed51085db77606de9b9477c96894328809 ]
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already crea
From: Yong Wu
[ Upstream commit 635319a4a7444ca97124d781cd96deb277ff4d40 ]
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1
From: Yong Wu
[ Upstream commit 822a2ed8c606caf6a11b1a180b8e46292bd77d71 ]
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_ini
From: Yong Wu
[ Upstream commit 2fb0feed51085db77606de9b9477c96894328809 ]
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already crea
From: Yong Wu
[ Upstream commit 635319a4a7444ca97124d781cd96deb277ff4d40 ]
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1
Hi Kevin,
On 2022/3/30 14:50, Tian, Kevin wrote:
ie if we have a singleton group that doesn't have ACS and someone
hotplugs in another device on a bridge, then our SVA is completely
broken and we get data corruption.
Can we capture that in iommu_probe_device() when identifying
the group which t
On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
> One thing that I'm not very sure is about DMA alias. Even when physically
> there is only a single device within the group the aliasing could lead
> to multiple RIDs in the group making it non-singleton. But probably we
> don't need su
On 2022/3/30 15:05, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, March 29, 2022 1:38 PM
Use this field to save the pasid/ssid bits that a device is able to
support with its IOMMU hardware. It is a generic attribute of a device
and lifting it into the per-device dev_iommu struct makes it poss
On Mon, 28 Mar 2022 08:37:23 +0200
Christoph Hellwig wrote:
> On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> > I think my list of three different sync cases (not just two! It's not
> > just about whether to sync for the CPU or the device, it's also about
> > what direction the
Hi Jason,
On 2022/3/19 01:27, Jason Gunthorpe wrote:
Connect the IOAS to its IOCTL interface. This exposes most of the
functionality in the io_pagetable to userspace.
This is intended to be the core of the generic interface that IOMMUFD will
provide. Every IOMMU driver should be able to impleme
[Public]
> -Original Message-
> From: Dave Hansen
> Sent: Tuesday, March 29, 2022 11:25 AM
> To: Deucher, Alexander ; linux-
> d...@vger.kernel.org; linux-ker...@vger.kernel.org; cor...@lwn.net;
> h...@zytor.com; x...@kernel.org; dave.han...@linux.intel.com;
> b...@alien8.de; mi...@redhat
> From: Jason Gunthorpe
> Sent: Wednesday, March 30, 2022 7:58 PM
>
> On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
>
> > One thing that I'm not very sure is about DMA alias. Even when physically
> > there is only a single device within the group the aliasing could lead
> > to mult
+Alex
> From: Tian, Kevin
> Sent: Wednesday, March 30, 2022 10:13 PM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 30, 2022 7:58 PM
> >
> > On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
> >
> > > One thing that I'm not very sure is about DMA alias. Even when physically
> >
Hi,
* Lu Baolu [700101 02:00]:
> The is_attach_deferred iommu_ops callback is a device op. The domain
> argument is unnecessary and never used. Remove it to make code clean.
Looks like this causes a regression for at least drivers/iommu/omap-iommu.c.
To me it seems the issue is there is no is_a
On 3/30/22 07:01, Deucher, Alexander wrote:
>> Just scanning this, it looks *awfully* generic. Is anything in
>> here AMD- specific? Should this be in an AMD-specific file?
> There is some information about the ACPI tables used to enumerate the
> IOMMUs and a link to the AMD IOMMU programming doc
On Wed, Mar 30, 2022 at 05:00:39PM +0300, Tony Lindgren wrote:
> Hi,
>
> * Lu Baolu [700101 02:00]:
> > The is_attach_deferred iommu_ops callback is a device op. The domain
> > argument is unnecessary and never used. Remove it to make code clean.
>
> Looks like this causes a regression for at le
On Wed, Mar 30, 2022 at 02:12:57PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 30, 2022 7:58 PM
> >
> > On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
> >
> > > One thing that I'm not very sure is about DMA alias. Even when physically
> > > there i
On Wed, 30 Mar 2022 14:18:47 +
"Tian, Kevin" wrote:
> +Alex
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 30, 2022 10:13 PM
> >
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, March 30, 2022 7:58 PM
> > >
> > > On Wed, Mar 30, 2022 at 06:50:11AM +, Tian, Kevin wrote:
> > >
>
* Jason Gunthorpe [220330 14:21]:
> On Wed, Mar 30, 2022 at 05:00:39PM +0300, Tony Lindgren wrote:
> > Hi,
> >
> > * Lu Baolu [700101 02:00]:
> > > The is_attach_deferred iommu_ops callback is a device op. The domain
> > > argument is unnecessary and never used. Remove it to make code clean.
> >
On Wed, Mar 30, 2022 at 08:19:37PM +0300, Tony Lindgren wrote:
> > > __iommu_probe_device from probe_iommu_group+0x2c/0x38
> > > probe_iommu_group from bus_for_each_dev+0x74/0xbc
> > > bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
> > > bus_iommu_probe from bus_set_iommu+0x80/0xc8
> > > bus_set
On Wed, Mar 30, 2022 at 01:51:07PM -0400, Alex Xu (Hello71) wrote:
> Hi,
>
> After a recent kernel update, booting one of my machines causes it to
> hang on a black screen. Pressing Lock keys on the USB keyboard does not
> turn on the indicators, and the machine does not appear on the Ethernet
Can you try this patch, which is a bit of a hack?
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 50d209939c66c..61997c2ee0a17 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -28,7 +28,8 @@ bool force_dma_unencrypted(struct device *dev)
*
Hi,
After a recent kernel update, booting one of my machines causes it to
hang on a black screen. Pressing Lock keys on the USB keyboard does not
turn on the indicators, and the machine does not appear on the Ethernet
network. I don't have a serial port on this machine. I didn't try
netconsole
On Tue, Mar 29, 2022 at 01:37:52PM +0800, Lu Baolu wrote:
> @@ -95,6 +101,7 @@ struct iommu_domain {
> void *handler_token;
> struct iommu_domain_geometry geometry;
> struct iommu_dma_cookie *iova_cookie;
> + struct iommu_sva_cookie *sva_cookie;
Cookie is still the wrong word
On Tue, Mar 29, 2022 at 01:37:53PM +0800, Lu Baolu wrote:
> Attaching an IOMMU domain to a PASID of a device is a generic operation
> for modern IOMMU drivers which support PASID-granular DMA address
> translation. Currently visible usage scenarios include (but not limited):
>
> - SVA (Shared Vir
On Tue, Mar 29, 2022 at 01:37:55PM +0800, Lu Baolu wrote:
> Add support for SVA domain allocation and provide an SVA-specific
> iommu_domain_ops.
>
> Signed-off-by: Lu Baolu
> include/linux/intel-iommu.h | 1 +
> drivers/iommu/intel/iommu.c | 10 ++
> drivers/iommu/intel/svm.c | 37 ++
Excerpts from Christoph Hellwig's message of March 30, 2022 2:01 pm:
> Can you try this patch, which is a bit of a hack?
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 50d209939c66c..61997c2ee0a17 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encr
On Wed, Mar 30, 2022 at 03:17:20PM -0400, Alex Xu (Hello71) wrote:
> Excerpts from Christoph Hellwig's message of March 30, 2022 2:01 pm:
> > Can you try this patch, which is a bit of a hack?
> >
> > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> > index 50d209939c66c..61997c
On Fri, Mar 18, 2022 at 02:27:33PM -0300, Jason Gunthorpe wrote:
> Connect the IOAS to its IOCTL interface. This exposes most of the
> functionality in the io_pagetable to userspace.
>
> This is intended to be the core of the generic interface that IOMMUFD will
> provide. Every IOMMU driver should
> From: David Gibson
> Sent: Thursday, March 31, 2022 12:36 PM
> > +
> > +/**
> > + * struct iommu_ioas_iova_ranges - ioctl(IOMMU_IOAS_IOVA_RANGES)
> > + * @size: sizeof(struct iommu_ioas_iova_ranges)
> > + * @ioas_id: IOAS ID to read ranges from
> > + * @out_num_iovas: Output total number of rang
pgprot_decrypted is used by AMD SME systems to allow access to memory
that was set to not encrypted using set_memory_decrypted. That only
happens for dma-direct memory as the IOMMU solves the addressing
challenges for the encryption bit using its own remapping.
Move the pgprot_decrypted call out
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started
triggering a NULL pointer dereference for some omap variants:
__iommu_probe_device from probe_iommu_group+0x2c/0x38
probe_iommu_group from bus_for_each_dev+0x74/0xbc
bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
bus_iomm
Hi,
* Jason Gunthorpe [220330 17:31]:
> On Wed, Mar 30, 2022 at 08:19:37PM +0300, Tony Lindgren wrote:
>
> > > > __iommu_probe_device from probe_iommu_group+0x2c/0x38
> > > > probe_iommu_group from bus_for_each_dev+0x74/0xbc
> > > > bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
> > > > bus_io
39 matches
Mail list logo
