On Mon, Jun 26, 2023 at 06:42:58AM +0000, Tian, Kevin wrote:
Yi/Nicolin, please update this series to not automatically add reserved regions to S2 in the nesting configuration.
I'm a bit late for the conversation here. Yet, how about the IOMMU_RESV_SW_MSI on ARM in the nesting configuration? We'd still call iommufd_group_setup_msi() on the S2 HWPT, despite attaching the device to a nested S1 HWPT right?
Yes, based on current design of ARM nesting.
But please special case it instead of pretending that all reserved regions are added to IOAS which is wrong in concept based on the discussion.
Ack. Yi made a version of change dropping it completely along with the iommufd_group_setup_msi() call for a nested S1 HWPT. So I thought there was a misalignment. I made another version preserving the pathway for MSI on ARM, and perhaps we should go with this one: https://github.com/nicolinc/iommufd/commit/c63829a12d35f2d7a390f42821a079f8a...
It also implies that the user cannot rely on IOAS_IOVA_RANGES to learn reserved regions for arranging addresses in S1.
Then we also need a new ioctl to report reserved regions per dev_id.
So, in a nesting configuration, QEMU would poll a device's S2 MSI region (i.e. IOMMU_RESV_SW_MSI) to prevent conflict?
Qemu needs to know all the reserved regions of the device and skip them when arranging S1 layout.
OK.
I'm not sure whether the MSI region needs a special MSI type or just a general RESV_DIRECT type for 1:1 mapping, though.
I don't quite get this part. Isn't MSI having IOMMU_RESV_MSI and IOMMU_RESV_SW_MSI? Or does it juset mean we should report the iommu_resv_type along with reserved regions in new ioctl?
Thanks Nic