Caveat: on the chance that the IOVA domain init fails due to the rcache init failing, then, if there were another device in the group which probes later, its probe would be ok as the start_pfn is set. Not Good.
Yeah, there's a lot not to like about iommu_dma_init_domain() - I've been banking on it all getting cleaned up when I get to refactoring that area of probing (remember the issue you reported years ago with PCI groups being built in the wrong order? All related...), but in fact since the cookie management got pulled into core code, we can probably tie the IOVA domain setup to that right now without much other involvement. That could be a cheap win, so I'll give it a go soon.
- vdpa just fails to create the domain in vduse_domain_create()
That makes a fair amount of sense, but does mean that we're missing the equivalent in iova_rcache_insert() for it to actually work. Or we just remove it and tighten up the documentation to say that's not valid
I'd be more inclined to remove it. I would rather remove fathpath checks as much as possible and have robust error handling in the domain init.
Afterall I do have the "remove check" craze going.
Sure, like I say I'm happy to be consistent either way. If I do end up reinstating such a check I think I'd prefer to have it explicit in {alloc,free}_iova_fast() anyway, rather than buried in internal implementation details.