On 7/1/26 12:26, Peter Maydell wrote:
On Wed, 1 Jul 2026 at 09:09, Cédric Le Goater <[email protected]> wrote:

On aarch64 hosts with 64K pages, the platform bus MMIO allocator can
allocate the 1KB "tpm-ppi" region at offsets not aligned to the host
page size, triggering a noisy VFIO IOMMU warning at VM startup:

   vfio_listener_valid_section received unaligned region tpm-ppi
     iova=0xc005000 offset_within_region=0x0
     qemu_real_host_page_size=0x10000

Commit 851d6d1a0ff2 ("vfio/common: remove spurious tpm-crb-cmd
misalignment warning") suppressed this for TPM CRB devices via a
TPM_IS_CRB(owner) check. However, this misses "tpm-ppi" regions owned
by other TPM types like SysBus/ISA tpm-tis devices.

Avoid enumerating every TPM device type by matching the "tpm-ppi"
memory region name directly in vfio_known_safe_misalignment().

Signed-off-by: Cedric Le Goater <[email protected]>
---
  hw/vfio/listener.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/listener.c b/hw/vfio/listener.c
index 
c19600e980a8d02217b5d9df4aca8f879ab2c5d5..c76ba285ddb7ef4f93bb081e67de47b3aecbe212
 100644
--- a/hw/vfio/listener.c
+++ b/hw/vfio/listener.c
@@ -355,8 +355,10 @@ static void 
vfio_ram_discard_unregister_listener(VFIOContainer *bcontainer,
  static bool vfio_known_safe_misalignment(MemoryRegionSection *section)
  {
      MemoryRegion *mr = section->mr;
+    const char *name = memory_region_name(mr);

-    if (!TPM_IS_CRB(mr->owner)) {
+    if (!TPM_IS_CRB(mr->owner) &&
+        !(name && strcmp(name, "tpm-ppi") == 0)) {
          return false;
      }

I think this is the wrong approach, see my comments on the
other email thread. vfio should not be building up some kind
of whitelist of "this specific not-page-aligned RAM is OK",
because a not-page-aligned RAM backed MMIO region is in general
a normal thing to have.

We should warn for only VFIO-owned regions. I agree.

Forget this patch. It's minor anyway. I will see how the listener
can be improved to remove vfio_known_safe_misalignment()

Thanks,

C.


Reply via email to