> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: 11 March 2026 18:25
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>; qemu-
> arm@nongnu.org; qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; clg@redhat.com; alex@shazbot.org; Nicolin
> Chen <nicolinc@nvidia.com>; Nathan Chen <nathanc@nvidia.com>; Matt
> Ochs <mochs@nvidia.com>; Jiandi An <jan@nvidia.com>; Jason Gunthorpe
> <jgg@nvidia.com>; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; Krishnakant Jaju
> <kjaju@nvidia.com>; phrdina@redhat.com
> Subject: Re: [PATCH v3 00/32] hw/arm/virt: Introduce Tegra241 CMDQV
> support for accelerated SMMUv3
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Shameer,
> 
> On 2/26/26 11:50 AM, Shameer Kolothum wrote:
> > Hi,
> >
> > Changes from v2:
> >
> > https://lore.kernel.org/qemu-devel/20260206144823.80655-1-
> skolothumtho
> > @nvidia.com/
> >
> >   - Addressed feedback on v2 and picked up R-by tags. Thanks!
> >   - Renamed the property from "tegra241-cmdqv" to a generic OnOffAuto
> >     "cmdqv".
> >   - Introduced a probe() callback to detect and initialize CMDQV
> >     support during device attach (patch #7).
> >   - Since CMDQV initialization is now deferred to device attach time,
> >     added a helper to link any unmapped MMIO/IRQ resources (patch #12).
> >   - Moved VINTF enable handling to the CONFIG ENABLE bit write path
> >     instead of any read/write access path (patch #17). Hopefully this
> >     won't break any corner cases.
> >   - Added checks for VINTF and CMDQV ENABLE bits before allocating
> >     vCMDQ HW queues, and free any allocated resources if disabled
> >     (patch #19).
> >   - Introduced a common helper for vEVENTQ read and validation
> >     (patch #23).
> >   - Updated bios-tables test IORT blobs for SMMUv3 device identifier
> >     changes (patch #29).
> >   - Rebasing on top of Philippe's CONFIG_DEVICES cleanup series [0],
> >     using tegra241-cmdqv-stubs.c (patch #6).
> >
> > Please find the complete branch here:
> > https://github.com/shamiali2008/qemu-master/tree/master-veventq-v8-
> vcm
> > dq-v3
> 
> with this version I still get those traces:
> 
> iommufd_backend_map_dma  iommufd=28 ioas=2 iova=0xc0b0000
> size=0x10000
> addr=0xffff0bd30000 readonly=0 (-1)
> qemu-system-aarch64: warning: IOMMU_IOAS_MAP failed: Bad address, PCI
> BAR?
> qemu-system-aarch64: warning: vfio_container_dma_map(0xaaaea11e2870,
> 0xc0b0000, 0x10000, 0xffff0bd30000) = -14 (Bad address)

Yes. Please see my reply to Nicolin on v2:
https://lore.kernel.org/qemu-devel/CH3PR12MB7548C2DCA4D321D7FDE23754AB6CA@CH3PR12MB7548.namprd12.prod.outlook.com/

I do not have a way to suppress that warning currently. It should be
safe to ignore, similar to the behaviour before the dma-buf support
series for vfio-pci PCI BAR mappings.

Thanks,
Shameer

On Wed, Mar 11, 2026 at 06:34:38PM +0000, Shameer Kolothum Thodi wrote:
> I do not have a way to suppress that warning currently. It should be
> safe to ignore, similar to the behaviour before the dma-buf support
> series for vfio-pci PCI BAR mappings.

qemu should have the concept of memory regions that are not available
for DMA peer to peer operation - ie are not mapped to the iommu.

Now that the kernel strictly enforces this it is essential qemu itself
keep track if it thinks p2p should work or not.

Jason

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: 11 March 2026 20:00
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Cc: eric.auger@redhat.com; qemu-arm@nongnu.org; qemu-
> devel@nongnu.org; peter.maydell@linaro.org; clg@redhat.com;
> alex@shazbot.org; Nicolin Chen <nicolinc@nvidia.com>; Nathan Chen
> <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Jiandi An
> <jan@nvidia.com>; jonathan.cameron@huawei.com;
> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; Krishnakant Jaju
> <kjaju@nvidia.com>; phrdina@redhat.com
> Subject: Re: [PATCH v3 00/32] hw/arm/virt: Introduce Tegra241 CMDQV
> support for accelerated SMMUv3
> 
> On Wed, Mar 11, 2026 at 06:34:38PM +0000, Shameer Kolothum Thodi wrote:
> > I do not have a way to suppress that warning currently. It should be
> > safe to ignore, similar to the behaviour before the dma-buf support
> > series for vfio-pci PCI BAR mappings.
> 
> qemu should have the concept of memory regions that are not available
> for DMA peer to peer operation - ie are not mapped to the iommu.
> 
> Now that the kernel strictly enforces this it is essential qemu itself
> keep track if it thinks p2p should work or not.

We could introduce something like the below to address this. I will
include it in the next respin.

Thanks,
Shameer

---
 include/system/memory.h | 2 ++
 hw/arm/tegra241-cmdqv.c | 1 +
 hw/vfio/listener.c      | 5 +++++
 3 files changed, 8 insertions(+)

diff --git a/include/system/memory.h b/include/system/memory.h
index 02b2e83fd7..fb37616503 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -874,6 +874,8 @@ struct MemoryRegion {

     /* For devices designed to perform re-entrant IO into their own IO MRs */
     bool disable_reentrancy_guard;
+    /* RAM device region that does not require IOMMU mapping for P2P */
+    bool ram_device_skip_iommu_map;
 };

 struct IOMMUMemoryRegion {
diff --git a/hw/arm/tegra241-cmdqv.c b/hw/arm/tegra241-cmdqv.c
index 42d7dbfde7..4647b4db54 100644
--- a/hw/arm/tegra241-cmdqv.c
+++ b/hw/arm/tegra241-cmdqv.c
@@ -212,6 +212,7 @@ static void tegra241_cmdqv_guest_map_vintf_page0(Tegra241CMDQV *cmdqv)
                                       memory_region_owner(&cmdqv->mmio_cmdqv),
                                       name, VINTF_PAGE_SIZE,
                                       cmdqv->vintf_page0);
+    cmdqv->mr_vintf_page0->ram_device_skip_iommu_map = true;
     memory_region_add_subregion_overlap(&cmdqv->mmio_cmdqv, 0x30000,
                                         cmdqv->mr_vintf_page0, 1);
     g_free(name);
diff --git a/hw/vfio/listener.c b/hw/vfio/listener.c
index 1087fdc142..d47439befb 100644
--- a/hw/vfio/listener.c
+++ b/hw/vfio/listener.c
@@ -614,6 +614,11 @@ void vfio_container_region_add(VFIOContainer *bcontainer,
         }
     }

+    if (memory_region_is_ram_device(section->mr) &&
+        section->mr->ram_device_skip_iommu_map) {
+        return;
+    }
+
     ret = vfio_container_dma_map(bcontainer, iova, int128_get64(llsize),
                                  vaddr, section->readonly, section->mr);
     if (ret) {
--
2.43.0