Current VT-d implementation supports nested translation only if all
underlying IOMMUs support the nested capability. This is unnecessary
as the upper layer is allowed to create different containers and set
them with different type of iommu backend. The IOMMU driver needs to
guarantee that devices
> From: Lu Baolu
> Sent: Wednesday, May 12, 2021 3:04 PM
>
> Current VT-d implementation supports nested translation only if all
> underlying IOMMUs support the nested capability. This is unnecessary
> as the upper layer is allowed to create different containers and set
> them with different
When first-level page tables are used for IOVA translation, we use user
privilege by setting U/S bit in the page table entry. This is to make it
consistent with the second level translation, where the U/S enforcement
is not available. Clear the SRE (Supervisor Request Enable) field in the
pasid
> From: Jason Gunthorpe
> Sent: Wednesday, May 12, 2021 1:37 AM
>
> On Tue, May 11, 2021 at 02:56:05PM +0800, Lu Baolu wrote:
>
> > > After my next series the mdev drivers will have direct access to
> > > the vfio_device. So an alternative to using the struct device, or
> > > adding
On Tue, May 11, 2021 at 04:47:26PM -0300, Jason Gunthorpe wrote:
> > Let me try to break down your concerns:
> > 1. portability - driver uses DMA APIs can function w/ and w/o IOMMU. is
> > that your concern? But PASID is intrinsically tied with IOMMU and if
> > the drivers are using a generic
The Intel VT-d implementation supports device TLB management. Select
PCI_ATS explicitly so that the pci_ats helpers are always available.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/intel/Kconfig
The Intel IOMMU driver reports the DMA fault reason in a decimal number
while the VT-d specification uses a hexadecimal one. It's inconvenient
that users need to covert them everytime before consulting the spec.
Let's use hexadecimal number for a DMA fault reason.
The fault message uses
On 2021/5/12 11:20, Lu Baolu wrote:
> On 5/11/21 3:40 PM, Keqian Zhu wrote:
>>> For upper layers, before starting page tracking, they check the
>>> dirty_page_trackable attribution of the domain and start it only it's
>>> capable. Once the page tracking is switched on the vendor iommu driver
On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
>
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Tiffany Lin
> CC: Irui
Hi keqian,
On 5/12/21 4:44 PM, Keqian Zhu wrote:
On 2021/5/12 11:20, Lu Baolu wrote:
On 5/11/21 3:40 PM, Keqian Zhu wrote:
For upper layers, before starting page tracking, they check the
dirty_page_trackable attribution of the domain and start it only it's
capable. Once the page tracking is
On Mon, May 10, 2021 at 06:25:08AM -0700, Jacob Pan wrote:
> The mm parameter in iommu_sva_bind_device() is intended for privileged
> process perform bind() on behalf of other processes. This use case has
> yet to be materialized, let alone potential security implications of
> adding kernel hooks
Hi Kevin,
On 5/12/21 4:30 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, May 12, 2021 3:04 PM
Current VT-d implementation supports nested translation only if all
underlying IOMMUs support the nested capability. This is unnecessary
as the upper layer is allowed to create different
On Wed, 2021-05-12 at 17:20 +0800, Hsin-Yi Wang wrote:
> On Sat, Apr 10, 2021 at 5:14 PM Yong Wu wrote:
> >
> > MediaTek IOMMU has already added the device_link between the consumer
> > and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
> > the smi-larb's pm_runtime_get_sync
In current kernels small allocations never fail, but checking for
allocation failure is the correct thing to do.
Fixes: 18abda7a2d55 ("iommu/vt-d: Fix general protection fault in
aux_detach_device()")
Signed-off-by: Dan Carpenter
---
drivers/iommu/intel/iommu.c | 2 ++
1 file changed, 2
On 2021-05-12 17:01, Tianyu Lan wrote:
Hi Christoph and Konrad:
Current Swiotlb bounce buffer uses a pool for all devices. There
is a high overhead to get or free bounce buffer during performance test.
Swiotlb code now use a global spin lock to protect bounce buffer data.
Several device
On Wed, May 12, 2021 at 02:44:26PM +0800, Lu Baolu wrote:
> When first-level page tables are used for IOVA translation, we use user
> privilege by setting U/S bit in the page table entry. This is to make it
> consistent with the second level translation, where the U/S enforcement
> is not
On Sat, May 08, 2021 at 11:14:51AM +0800, Bixuan Cui wrote:
> This patch adds missing MODULE_DEVICE_TABLE definition which generates
> correct modalias for automatic loading of this driver when it is built
> as an external module.
>
> Reported-by: Hulk Robot
> Signed-off-by: Bixuan Cui
Fixes:
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
On Wed, May 12, 2021 at 02:50:12PM +0800, Lu Baolu wrote:
> The Intel IOMMU driver reports the DMA fault reason in a decimal number
> while the VT-d specification uses a hexadecimal one. It's inconvenient
> that users need to covert them everytime before consulting the spec.
> Let's use
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
Hi Christoph and Konrad:
Current Swiotlb bounce buffer uses a pool for all devices. There
is a high overhead to get or free bounce buffer during performance test.
Swiotlb code now use a global spin lock to protect bounce buffer data.
Several device queues try to acquire the spin lock and
On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote:
> The void* drvdata parameter isn't really used in iommu_sva_bind_device()
> API, the current IDXD code "borrows" the drvdata for a VT-d private flag
> for supervisor SVA usage.
>
> Supervisor/Privileged mode request is a generic feature.
On 5/12/21 6:05 PM, Dan Carpenter wrote:
In current kernels small allocations never fail, but checking for
allocation failure is the correct thing to do.
Fixes: 18abda7a2d55 ("iommu/vt-d: Fix general protection fault in
aux_detach_device()")
Signed-off-by: Dan Carpenter
---
On 5/13/21 10:26 AM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, May 12, 2021 7:31 PM
Hi Kevin,
On 5/12/21 4:30 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, May 12, 2021 3:04 PM
Current VT-d implementation supports nested translation only if all
underlying IOMMUs support the
> From: Lu Baolu
> Sent: Wednesday, May 12, 2021 7:31 PM
>
> Hi Kevin,
>
> On 5/12/21 4:30 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Wednesday, May 12, 2021 3:04 PM
> >>
> >> Current VT-d implementation supports nested translation only if all
> >> underlying IOMMUs support the
> From: Jason Gunthorpe
> Sent: Monday, May 10, 2021 11:55 PM
>
> On Mon, May 10, 2021 at 08:54:02AM +0200, Christoph Hellwig wrote:
> > The iommu_device field in struct mdev_device has never been used
> > since it was added more than 2 years ago.
> >
> > Signed-off-by: Christoph Hellwig
> >
Hi Ashok,
On 5/13/21 1:03 AM, Raj, Ashok wrote:
On Wed, May 12, 2021 at 02:44:26PM +0800, Lu Baolu wrote:
When first-level page tables are used for IOVA translation, we use user
privilege by setting U/S bit in the page table entry. This is to make it
consistent with the second level
On 5/13/21 12:56 AM, Raj, Ashok wrote:
On Wed, May 12, 2021 at 02:50:12PM +0800, Lu Baolu wrote:
The Intel IOMMU driver reports the DMA fault reason in a decimal number
while the VT-d specification uses a hexadecimal one. It's inconvenient
that users need to covert them everytime before
On 5/13/21 12:01 AM, Tianyu Lan wrote:
Hi Christoph and Konrad:
Current Swiotlb bounce buffer uses a pool for all devices. There
is a high overhead to get or free bounce buffer during performance test.
Swiotlb code now use a global spin lock to protect bounce buffer data.
Several device
Am 04.05.21 um 12:22 schrieb Alexander Monakov:
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The second line is emitted via 'pr_cont',
31 matches
Mail list logo
