| Message ID | 5149b7e711a46e81aea8515676cf0e45608b3afd.1678348754.git.nicolinc@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add Nested Translation Support for SMMUv3 | expand |
Hi Nicolin, On 3/9/23 11:53, Nicolin Chen wrote: > The IOMMU_RESV_SW_MSI is a kernel-managed domain thing. So, it should be > only setup on a kernel-managed domain only. If the attaching domain is a > user-managed domain, redirect the hwpt to hwpt->parent to do it correctly. > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > --- > drivers/iommu/iommufd/device.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c > index f95b558f5e95..a3e7d2889164 100644 > --- a/drivers/iommu/iommufd/device.c > +++ b/drivers/iommu/iommufd/device.c > @@ -350,7 +350,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, > * call iommu_get_msi_cookie() on its behalf. This is necessary to setup > * the MSI window so iommu_dma_prepare_msi() can install pages into our > * domain after request_irq(). If it is not done interrupts will not > - * work on this domain. > + * work on this domain. And the msi_cookie should be always set into the s/And the/The/ > + * kernel-managed (parent) domain. > * > * FIXME: This is conceptually broken for iommufd since we want to allow > * userspace to change the domains, eg switch from an identity IOAS to a > @@ -358,6 +359,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, > * matches what the IRQ layer actually expects in a newly created > * domain. > */ > + if (hwpt->parent) > + hwpt = hwpt->parent; I guess there is a garantee the parent hwpt is necessarily a kernel-managed domain? Is it that part of the spec that enforces it? IOMMU_HWPT_ALLOC doc says: " * A user-managed HWPT will be created from a given parent HWPT via @pt_id, in * which the parent HWPT must be allocated previously via the same ioctl from a * given IOAS. " Maybe precise that in the commit msg? Thanks Eric > if (sw_msi_start != PHYS_ADDR_MAX && !hwpt->msi_cookie) { > rc = iommu_get_msi_cookie(hwpt->domain, sw_msi_start); > if (rc)
On Fri, Mar 10, 2023 at 05:45:20PM +0100, Eric Auger wrote: > External email: Use caution opening links or attachments > > > Hi Nicolin, > > On 3/9/23 11:53, Nicolin Chen wrote: > > The IOMMU_RESV_SW_MSI is a kernel-managed domain thing. So, it should be > > only setup on a kernel-managed domain only. If the attaching domain is a > > user-managed domain, redirect the hwpt to hwpt->parent to do it correctly. > > > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > > --- > > drivers/iommu/iommufd/device.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c > > index f95b558f5e95..a3e7d2889164 100644 > > --- a/drivers/iommu/iommufd/device.c > > +++ b/drivers/iommu/iommufd/device.c > > @@ -350,7 +350,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, > > * call iommu_get_msi_cookie() on its behalf. This is necessary to setup > > * the MSI window so iommu_dma_prepare_msi() can install pages into our > > * domain after request_irq(). If it is not done interrupts will not > > - * work on this domain. > > + * work on this domain. And the msi_cookie should be always set into the > s/And the/The/ OK. > > + * kernel-managed (parent) domain. > > * > > * FIXME: This is conceptually broken for iommufd since we want to allow > > * userspace to change the domains, eg switch from an identity IOAS to a > > @@ -358,6 +359,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, > > * matches what the IRQ layer actually expects in a newly created > > * domain. > > */ > > + if (hwpt->parent) > > + hwpt = hwpt->parent; > I guess there is a garantee the parent hwpt is necessarily a > kernel-managed domain? Yes. It must be. > Is it that part of the spec that enforces it? The hwpt_alloc() function has a sanity to enforce that. > IOMMU_HWPT_ALLOC doc says: > " * A user-managed HWPT will be created from a given parent HWPT via > @pt_id, in > * which the parent HWPT must be allocated previously via the same ioctl > from a > * given IOAS. > " > Maybe precise that in the commit msg? There is a paragraph just above that, for kernel-managed HWPT: 455 * A normal HWPT will be created with the mappings from the given IOAS. 456 * The @data_type for its allocation can be set to IOMMU_HWPT_TYPE_DEFAULT, or 457 * another type (being listed below) to specialize a kernel-managed HWPT. Perhaps we could rephrase "normal HWPT" with "kernel-managed HWPT", to make it more clear. Thanks Nic
diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c index f95b558f5e95..a3e7d2889164 100644 --- a/drivers/iommu/iommufd/device.c +++ b/drivers/iommu/iommufd/device.c @@ -350,7 +350,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, * call iommu_get_msi_cookie() on its behalf. This is necessary to setup * the MSI window so iommu_dma_prepare_msi() can install pages into our * domain after request_irq(). If it is not done interrupts will not - * work on this domain. + * work on this domain. And the msi_cookie should be always set into the + * kernel-managed (parent) domain. * * FIXME: This is conceptually broken for iommufd since we want to allow * userspace to change the domains, eg switch from an identity IOAS to a @@ -358,6 +359,8 @@ static int iommufd_group_setup_msi(struct iommufd_group *igroup, * matches what the IRQ layer actually expects in a newly created * domain. */ + if (hwpt->parent) + hwpt = hwpt->parent; if (sw_msi_start != PHYS_ADDR_MAX && !hwpt->msi_cookie) { rc = iommu_get_msi_cookie(hwpt->domain, sw_msi_start); if (rc)
The IOMMU_RESV_SW_MSI is a kernel-managed domain thing. So, it should be only setup on a kernel-managed domain only. If the attaching domain is a user-managed domain, redirect the hwpt to hwpt->parent to do it correctly. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> --- drivers/iommu/iommufd/device.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)