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/c63829a12d35f2d7a390f42821a079f8a294cff8 > > > 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
