> 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
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
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
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
> +++
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
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
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
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
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)
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
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
> > >
* 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, 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:
> > >
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
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
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
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
+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
>
> 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
[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;
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
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
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
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
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
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)
[]
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
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 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
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)
[]
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)
[]
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 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
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
> 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
> From: Lu Baolu
> Sent: Wednesday, March 30, 2022 1:00 PM
> >
> > btw I'm not sure whether this is what SVA requires. IIRC the problem with
> > SVA is because PASID TLP prefix is not counted in PCI packet routing thus
> > a DMA target address with PASID might be treated as P2P if the address
> >
> From: Jason Gunthorpe
> Sent: Tuesday, March 29, 2022 7:43 PM
>
> On Tue, Mar 29, 2022 at 08:42:13AM +, Tian, Kevin wrote:
>
> > btw I'm not sure whether this is what SVA requires. IIRC the problem with
> > SVA is because PASID TLP prefix is not counted in PCI packet routing thus
> > a
38 matches
Mail list logo
