From: Pavel Hrdina <phrdina@redhat.com>

The function qemuDomainNeedsVFIO() was originally used by other parts
of qemu code to figure out if the VM needs /dev/vfio/vfio.

Later it was also used by code calculating locked memory limit for all
architectures, and after that change again and used only for PPC64.

Now it needs to be changed again due to IOMMUFD support, the
/dev/vfio/vfio device is used by QEMU only if IOMMUFD is not used
but for accounting we should most likely still consider any PCI host
device.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
---
 src/qemu/qemu_domain.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 90d0f02612..4520c3c28d 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -8259,7 +8259,10 @@ getPPC64MemLockLimitBytes(virDomainDef *def)
         passthroughLimit = maxMemory +
                            128 * (1ULL<<30) / 512 * nPCIHostBridges +
                            8192;
-    } else if (qemuDomainNeedsVFIO(def) || virDomainDefHasVDPANet(def)) {
+    } else if (virDomainDefHasPCIHostdev(def) ||
+               virDomainDefHasMdevHostdev(def) ||
+               virDomainDefHasNVMeDisk(def) ||
+               virDomainDefHasVDPANet(def)) {
         /* For regular (non-NVLink2 present) VFIO passthrough, the value
          * of passthroughLimit is:
          *
-- 
2.53.0

On Thu, Mar 19, 2026 at 17:36:50 +0100, Pavel Hrdina via Devel wrote:
> From: Pavel Hrdina <phrdina@redhat.com>
> 
> The function qemuDomainNeedsVFIO() was originally used by other parts
> of qemu code to figure out if the VM needs /dev/vfio/vfio.
> 
> Later it was also used by code calculating locked memory limit for all
> architectures, and after that change again and used only for PPC64.
> 
> Now it needs to be changed again due to IOMMUFD support, the
> /dev/vfio/vfio device is used by QEMU only if IOMMUFD is not used
> but for accounting we should most likely still consider any PCI host

I guess the reason for uncertainity is the absence of hardware, right?

> device.
> 
> Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
> ---
>  src/qemu/qemu_domain.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 90d0f02612..4520c3c28d 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -8259,7 +8259,10 @@ getPPC64MemLockLimitBytes(virDomainDef *def)
>          passthroughLimit = maxMemory +
>                             128 * (1ULL<<30) / 512 * nPCIHostBridges +
>                             8192;
> -    } else if (qemuDomainNeedsVFIO(def) || virDomainDefHasVDPANet(def)) {
> +    } else if (virDomainDefHasPCIHostdev(def) ||

I'd suggest adding a comment stating that qemuDomainNeedsVFIO is not
used here to preserve old limits in cases when iommufd may be used. Or
something stating why this was done in this place.

> +               virDomainDefHasMdevHostdev(def) ||
> +               virDomainDefHasNVMeDisk(def) ||
> +               virDomainDefHasVDPANet(def)) {
>          /* For regular (non-NVLink2 present) VFIO passthrough, the value
>           * of passthroughLimit is:
>           *
> -- 
> 2.53.0
> 

Reviewed-by: Peter Krempa <pkrempa@redhat.com>

On Fri, Mar 20, 2026 at 09:19:43AM +0100, Peter Krempa wrote:
> On Thu, Mar 19, 2026 at 17:36:50 +0100, Pavel Hrdina via Devel wrote:
> > From: Pavel Hrdina <phrdina@redhat.com>
> > 
> > The function qemuDomainNeedsVFIO() was originally used by other parts
> > of qemu code to figure out if the VM needs /dev/vfio/vfio.
> > 
> > Later it was also used by code calculating locked memory limit for all
> > architectures, and after that change again and used only for PPC64.
> > 
> > Now it needs to be changed again due to IOMMUFD support, the
> > /dev/vfio/vfio device is used by QEMU only if IOMMUFD is not used
> > but for accounting we should most likely still consider any PCI host
> 
> I guess the reason for uncertainity is the absence of hardware, right?

IOMMUFD can by used with existing network devices as well, it's a
replacement for the old VFIO container. It still needs increasing locked
memory limit, the question is if it should be the same as with VFIO
container. So for now we can use the same logic for both.

Pavel