On 2025/8/23 07:55, Nicolin Chen wrote:
On Fri, Aug 22, 2025 at 02:40:58AM -0400, Zhenzhong Duan wrote:
diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
index e503c232e1..59735e878c 100644
--- a/hw/vfio/iommufd.c
+++ b/hw/vfio/iommufd.c
@@ -324,6 +324,7 @@ static bool iommufd_cdev_autodomains_get(VFIODevice
*vbasedev,
{
ERRP_GUARD();
IOMMUFDBackend *iommufd = vbasedev->iommufd;
+ struct iommu_hw_info_vtd vtd;
VendorCaps vendor_caps;
uint32_t type, flags = 0;
uint64_t hw_caps;
VFIOIOASHwpt *hwpt;
@@ -371,10 +372,15 @@ static bool iommufd_cdev_autodomains_get(VFIODevice
*vbasedev,
* instead.
*/
if (!iommufd_backend_get_device_info(vbasedev->iommufd, vbasedev->devid,
- &type, NULL, 0, &hw_caps, errp)) {
+ &type, &vtd, sizeof(vtd), &hw_caps,
s/vtd/vendor_caps/g
+ errp)) {
return false;
}
+ if (vtd.flags & IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17) {
+ container->bcontainer.bypass_ro = true;
This circled back to checking a vendor specific flag in the core..
Perhaps we could upgrade the get_viommu_cap op and its API:
enum viommu_flags {
VIOMMU_FLAG_HW_NESTED = BIT_ULL(0),
VIOMMU_FLAG_BYPASS_RO = BIT_ULL(1),
hmmm. I'm not quite on this idea as the two flags have different sources.
One determined by vIOMMU config, one by the hardware limit. Reporting
them in one API is strange. I think the bypass RO can be determined in
VFIO just like the patch has done. But it should check if vIOMMU has
requested nested hwpt and also the reported hw_info::type is
IOMMU_HW_INFO_TYPE_INTEL_VTD.
if ((flags & IOMMU_HWPT_ALLOC_NEST_PARENT) &&
type == IOMMU_HW_INFO_TYPE_INTEL_VTD &&
vtd.flags & IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17) {
container->bcontainer.bypass_ro = true;
}
Regards,
Yi Liu
