On 2022-04-07 20:08, Jason Gunthorpe wrote:
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.
Thanks, but I still need a device for the iommu_domain_alloc() as well,
so at that point the interrupt check is OK to stay where it is. I
figured out a locking strategy per my original idea that seems pretty
clean, it just needs vfio_group_viable() to go away first:
https://gitlab.arm.com/linux-arm/linux-rm/-/commit/c6057da9f6b5f4b0fb67c6e647d2f8f76a6177fc
Cheers,
Robin.
