> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Friday, April 8, 2022 3:08 AM
> On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> > On 2022-04-07 18:43, Jason Gunthorpe wrote:
> > > On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
> > > > At a glance, this all looks about the right shape to me now, thanks!
> > >
> > > Thanks!
> > >
> > > > Ideally I'd hope patch #4 could go straight to device_iommu_capable()
> from
> > > > my Thunderbolt series, but we can figure that out in a couple of weeks
> once
> > >
> > > Yes, this does helps that because now the only iommu_capable call is
> > > in a context where a device is available :)
> >
> > Derp, of course I have *two* VFIO patches waiting, the other one touching
> > the iommu_capable() calls (there's still IOMMU_CAP_INTR_REMAP, which,
> much
> > as I hate it and would love to boot all that stuff over to
> > drivers/irqchip,
>
> Oh me too...
>
> > it's not in my way so I'm leaving it be for now). I'll have to rebase that
> > anyway, so merging this as-is is absolutely fine!
>
> This might help your effort - after this series and this below there
> are no 'bus' users of iommu_capable left at all.
>
Out of curiosity, while iommu_capable is being moved to a per-device
interface what about irq_domain_check_msi_remap() below (which
is also a global check)?
> +static int vfio_iommu_device_ok(void *iommu_data, struct device *device)
> +{
> + bool msi_remap;
> +
> + msi_remap = irq_domain_check_msi_remap() ||
> + iommu_capable(device->bus, IOMMU_CAP_INTR_REMAP);
> +
