On 2022-04-08 10:08, Tian, Kevin wrote:
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)?
I suppose it could if anyone cared enough to make the effort - probably
a case of resolving specific MSI domains for every device in the group,
and potentially having to deal with hotplug later as well.
Realistically, though, I wouldn't expect systems to have mixed
capabilities in that regard (i.e. where the check would return false
even though *some* domains support remapping), so there doesn't seem to
be any pressing need to relax it.
Cheers,
Robin.
+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);
+
