)]}'
{
  "commit": "c7ecb4cf2e9458678d649ffd3b8aa61a7976552e",
  "tree": "0356be135ff78f84c4d97f45d5d543865bbcdf46",
  "parents": [
    "d1c585db8bb0a65107f1e5903133bc56b29c46f2"
  ],
  "author": {
    "name": "Shameer Kolothum",
    "email": "skolothumtho@nvidia.com",
    "time": "Thu Jan 29 13:32:04 2026 +0000"
  },
  "committer": {
    "name": "Peter Maydell",
    "email": "peter.maydell@linaro.org",
    "time": "Thu Jan 29 13:32:04 2026 +0000"
  },
  "message": "hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd\n\nAccelerated SMMUv3 is only meaningful when a device can leverage the host\nSMMUv3 in nested mode (S1+S2 translation). To keep the model consistent\nand correct, this mode is restricted to vfio-pci endpoint devices using\nthe iommufd backend.\n\nNon-endpoint emulated devices such as PCIe root ports and bridges are also\npermitted so that vfio-pci devices can be attached downstream. All other\ndevice types are unsupported in accelerated mode.\n\nImplement supports_address_space() callback to reject all such unsupported\ndevices.\n\nThis restriction also avoids complications with IOTLB invalidations. Some\nTLBI commands (e.g. CMD_TLBI_NH_ASID) lack an associated SID, making it\ndifficult to trace the originating device. Allowing emulated endpoints\nwould require invalidating both QEMU’s software IOTLB and the host’s\nhardware IOTLB, which can significantly degrade performance.\n\nA key design choice is the address space returned for accelerated vfio-pci\nendpoints. VFIO core has a container that manages an HWPT. By default, it\nallocates a stage-1 normal HWPT, unless vIOMMU requests for a nesting\nparent HWPT for accelerated cases.\n\nVFIO core adds a listener for that HWPT and sets up a handler\nvfio_container_region_add() where it checks the memory region.\n\n -If the region is a non-IOMMU translated one (system address space), VFIO\n  treats it as RAM and handles all stage-2 mappings for the core allocated\n  nesting parent HWPT.\n\n -If the region is an IOMMU address space, VFIO instead enables IOTLB\n  notifier handling and translation replay, skipping the RAM listener and\n  therefore not installing stage-2 mappings.\n\nFor accelerated SMMUv3, correct operation requires the S1+S2 nesting\nmodel, and therefore VFIO must take the \"system address space\" path so\nthat stage-2 mappings are properly built. Returning an alias of the\nsystem address space ensures this happens. Returning the IOMMU address\nspace would omit stage-2 mapping and break nested translation.\n\nAnother option considered was forcing a pre-registration path using\nvfio_prereg_listener() to set up stage-2 mappings, but this requires\nchanges in VFIO core and was not adopted. Returning an alias of the\nsystem address space keeps the design aligned with existing VFIO/iommufd\nnesting flows and avoids the need for cross-subsystem changes.\n\nIn summary:\n - vfio-pci devices(with iommufd as backend) return an address space\n   aliased to system address space.\n - bridges and root ports return the IOMMU address space.\n\nReviewed-by: Jonathan Cameron \u003cjonathan.cameron@huawei.com\u003e\nReviewed-by: Nicolin Chen \u003cnicolinc@nvidia.com\u003e\nReviewed-by: Eric Auger \u003ceric.auger@redhat.com\u003e\nTested-by: Eric Auger \u003ceric.auger@redhat.com\u003e\nTested-by: Zhangfei Gao \u003czhangfei.gao@linaro.org\u003e\nSigned-off-by: Shameer Kolothum \u003cskolothumtho@nvidia.com\u003e\nMessage-id: 20260126104342.253965-11-skolothumtho@nvidia.com\nSigned-off-by: Peter Maydell \u003cpeter.maydell@linaro.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b2eded743e44f27cdf8e800e1b42f3c13c2973f7",
      "old_mode": 33188,
      "old_path": "hw/arm/smmuv3-accel.c",
      "new_id": "2fcd301322cf73658556fb5994f199db2af5d02a",
      "new_mode": 33188,
      "new_path": "hw/arm/smmuv3-accel.c"
    }
  ]
}