Re: [PATCH v2 0/5] iommu: Support identity mappings of reserved-memory regions
23.04.2021 19:32, Thierry Reding пишет: > I've made corresponding changes in the proprietary bootloader, added a > compatibility shim in U-Boot (which forwards information created by the > proprietary bootloader to the kernel) and the attached patches to test > this on Jetson TX1, Jetson TX2 and Jetson AGX Xavier. Could you please tell what downstream kernel does for coping with the identity mappings in conjunction with the original proprietary bootloader? If there is some other method of passing mappings to kernel, could it be supported by upstream? Putting burden on users to upgrade bootloader feels a bit inconvenient. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.
Thanks Lu for the reply. > > Isn't the domain should be switched from a default domain to an > unmanaged domain when the device is assigned to the guest? > > Even you want to r-setup the same mappings, you need to un-map all > existing mappings, right? > Hmm, I guess that's a (design) decision the KVM/QEMU/VFIO communities need to take. May be the patch could suppress the flooding till then? Thanks and Regards, Ajay ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.
On 2021/10/2 20:40, Ajay Garg wrote:
Taking a SD-MMC controller (over PCI) as an example, following is an
example sequencing, where the log-flooding happened :
0.
We have a host and a guest, both running latest x86_64 kernels.
1.
Host-machine is booted up (with intel_iommu=on), and the DMA-PTEs
are setup for the controller (on the host), for the first time.
2.
The SD-controller device is added to a (L1) guest on a KVM-VM
(via virt-manager).
Isn't the domain should be switched from a default domain to an
unmanaged domain when the device is assigned to the guest?
Even you want to r-setup the same mappings, you need to un-map all
existing mappings, right?
Best regards,
baolu
3.
The KVM-VM is booted up.
4.
Above triggers a re-setup of DMA-PTEs on the host, for a
second time.
It is observed that the new PTEs formed (on the host) are same
as the original PTEs, and thus following logs, accompanied by
stacktraces, overwhelm the logs :
..
DMAR: ERROR: DMA PTE for vPFN 0x428ec already set (to 3f6ec003 not 3f6ec003)
DMAR: ERROR: DMA PTE for vPFN 0x428ed already set (to 3f6ed003 not 3f6ed003)
DMAR: ERROR: DMA PTE for vPFN 0x428ee already set (to 3f6ee003 not 3f6ee003)
DMAR: ERROR: DMA PTE for vPFN 0x428ef already set (to 3f6ef003 not 3f6ef003)
DMAR: ERROR: DMA PTE for vPFN 0x428f0 already set (to 3f6f0003 not 3f6f0003)
..
As the PTEs are same, so there is no cause of concern, and we can easily
avoid the logs-flood for this non-error case.
Signed-off-by: Ajay Garg
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d75f59ae28e6..8bea8b4e3ff9 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2370,7 +2370,7 @@ __domain_mapping(struct dmar_domain *domain, unsigned
long iov_pfn,
* touches the iova range
*/
tmp = cmpxchg64_local(>val, 0ULL, pteval);
- if (tmp) {
+ if (tmp && (tmp != pteval)) {
static int dumps = 5;
pr_crit("ERROR: DMA PTE for vPFN 0x%lx already set (to %llx
not %llx)\n",
iov_pfn, tmp, (unsigned long long)pteval);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.
Taking a SD-MMC controller (over PCI) as an example, following is an
example sequencing, where the log-flooding happened :
0.
We have a host and a guest, both running latest x86_64 kernels.
1.
Host-machine is booted up (with intel_iommu=on), and the DMA-PTEs
are setup for the controller (on the host), for the first time.
2.
The SD-controller device is added to a (L1) guest on a KVM-VM
(via virt-manager).
3.
The KVM-VM is booted up.
4.
Above triggers a re-setup of DMA-PTEs on the host, for a
second time.
It is observed that the new PTEs formed (on the host) are same
as the original PTEs, and thus following logs, accompanied by
stacktraces, overwhelm the logs :
..
DMAR: ERROR: DMA PTE for vPFN 0x428ec already set (to 3f6ec003 not 3f6ec003)
DMAR: ERROR: DMA PTE for vPFN 0x428ed already set (to 3f6ed003 not 3f6ed003)
DMAR: ERROR: DMA PTE for vPFN 0x428ee already set (to 3f6ee003 not 3f6ee003)
DMAR: ERROR: DMA PTE for vPFN 0x428ef already set (to 3f6ef003 not 3f6ef003)
DMAR: ERROR: DMA PTE for vPFN 0x428f0 already set (to 3f6f0003 not 3f6f0003)
..
As the PTEs are same, so there is no cause of concern, and we can easily
avoid the logs-flood for this non-error case.
Signed-off-by: Ajay Garg
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index d75f59ae28e6..8bea8b4e3ff9 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2370,7 +2370,7 @@ __domain_mapping(struct dmar_domain *domain, unsigned
long iov_pfn,
* touches the iova range
*/
tmp = cmpxchg64_local(>val, 0ULL, pteval);
- if (tmp) {
+ if (tmp && (tmp != pteval)) {
static int dumps = 5;
pr_crit("ERROR: DMA PTE for vPFN 0x%lx already set (to
%llx not %llx)\n",
iov_pfn, tmp, (unsigned long long)pteval);
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
On Sat, Oct 02, 2021 at 02:21:38PM +1000, da...@gibson.dropbear.id.au wrote: > > > No. qemu needs to supply *both* the 32-bit and 64-bit range to its > > > guest, and therefore needs to request both from the host. > > > > As I understood your remarks each IOAS can only be one of the formats > > as they have a different PTE layout. So here I ment that qmeu needs to > > be able to pick *for each IOAS* which of the two formats it is. > > No. Both windows are in the same IOAS. A device could do DMA > simultaneously to both windows. Sure, but that doesn't force us to model it as one IOAS in the iommufd. A while back you were talking about using nesting and 3 IOAS's, right? 1, 2 or 3 IOAS's seems like a decision we can make. PASID support will already require that a device can be multi-bound to many IOAS's, couldn't PPC do the same with the windows? Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
On Fri, Oct 01, 2021 at 09:25:05AM -0300, Jason Gunthorpe wrote: > On Fri, Oct 01, 2021 at 04:19:22PM +1000, da...@gibson.dropbear.id.au wrote: > > On Wed, Sep 22, 2021 at 11:09:11AM -0300, Jason Gunthorpe wrote: > > > On Wed, Sep 22, 2021 at 03:40:25AM +, Tian, Kevin wrote: > > > > > From: Jason Gunthorpe > > > > > Sent: Wednesday, September 22, 2021 1:45 AM > > > > > > > > > > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote: > > > > > > This patch adds IOASID allocation/free interface per iommufd. When > > > > > > allocating an IOASID, userspace is expected to specify the type and > > > > > > format information for the target I/O page table. > > > > > > > > > > > > This RFC supports only one type (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2), > > > > > > implying a kernel-managed I/O page table with vfio type1v2 mapping > > > > > > semantics. For this type the user should specify the addr_width of > > > > > > the I/O address space and whether the I/O page table is created in > > > > > > an iommu enfore_snoop format. enforce_snoop must be true at this > > > > > > point, > > > > > > as the false setting requires additional contract with KVM on > > > > > > handling > > > > > > WBINVD emulation, which can be added later. > > > > > > > > > > > > Userspace is expected to call IOMMU_CHECK_EXTENSION (see next patch) > > > > > > for what formats can be specified when allocating an IOASID. > > > > > > > > > > > > Open: > > > > > > - Devices on PPC platform currently use a different iommu driver in > > > > > > vfio. > > > > > > Per previous discussion they can also use vfio type1v2 as long as > > > > > > there > > > > > > is a way to claim a specific iova range from a system-wide > > > > > > address space. > > > > > > This requirement doesn't sound PPC specific, as addr_width for pci > > > > > devices > > > > > > can be also represented by a range [0, 2^addr_width-1]. This RFC > > > > > > hasn't > > > > > > adopted this design yet. We hope to have formal alignment in v1 > > > > > discussion > > > > > > and then decide how to incorporate it in v2. > > > > > > > > > > I think the request was to include a start/end IO address hint when > > > > > creating the ios. When the kernel creates it then it can return the > > > > > > > > is the hint single-range or could be multiple-ranges? > > > > > > David explained it here: > > > > > > https://lore.kernel.org/kvm/YMrKksUeNW%2FPEGPM@yekko/ > > > > Apparently not well enough. I've attempted again in this thread. > > > > > qeumu needs to be able to chooose if it gets the 32 bit range or 64 > > > bit range. > > > > No. qemu needs to supply *both* the 32-bit and 64-bit range to its > > guest, and therefore needs to request both from the host. > > As I understood your remarks each IOAS can only be one of the formats > as they have a different PTE layout. So here I ment that qmeu needs to > be able to pick *for each IOAS* which of the two formats it is. No. Both windows are in the same IOAS. A device could do DMA simultaneously to both windows. More realstically a 64-bit DMA capable and a non-64-bit DMA capable device could be in the same group and be doing DMAs to different windows simultaneously. > > Or rather, it *might* need to supply both. It will supply just the > > 32-bit range by default, but the guest can request the 64-bit range > > and/or remove and resize the 32-bit range via hypercall interfaces. > > Vaguely recent Linux guests certainly will request the 64-bit range in > > addition to the default 32-bit range. > > And this would result in two different IOAS objects There might be two different IOAS objects for setup, but at some point they need to be combined into one IOAS to which the device is actually attached. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
