On Wed, Jun 21, 2023 at 06:02:21AM +0000, Tian, Kevin wrote:
On Tue, Jun 20, 2023 at 01:43:42AM +0000, Tian, Kevin wrote:
I wonder whether we have argued passed each other.
This series adds reserved regions to S2. I challenged the necessity as S2 is not directly accessed by the device.
Then you replied that doing so still made sense to support identity S1.
I think I said/ment if we attach the "s2" iommu domain as a direct attach for identity - eg at boot time, then the IOAS must gain the reserved regions. This is our normal protocol.
But when we use the "s2" iommu domain as an actual nested S2 then we don't gain reserved regions.
Then we're aligned.
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?
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?
Thanks Nic