Re: [RFC] iommu_ops->domain_alloc_paging() enhancement to support AMD IOMMU driver

[Robin Murphy <robin.murphy@arm.com>]

On 12/07/2024 12:49 am, Jason Gunthorpe wrote:
> On Wed, Jul 10, 2024 at 12:17:17PM +0800, Yi Liu wrote:
>> On 2024/7/10 02:23, Jason Gunthorpe wrote:
>>> On Wed, Jul 03, 2024 at 02:57:51PM +0800, Yi Liu wrote:
>>>
>>>> BTW. For AMD, can a single device be attached to multiple V1 page table?
>>>> IIRC. looks like AMD has only one V1 page table pointer per BDF. But there
>>>> is a PASID table which has multiple cr3 page table pointers.
>>>
>>> Yes, ARM and AMD both have kinds of iommu_domains that cannot be
>>> attached to a PASID.
>>
>> I see. VT-d does not have such a limitation AFAIK.
> 
> Yeah, it is nice for software that VT-d put the right bits in to let
> all paths select either format.
> 
>> BTW. SVA domain shall not be attached to RID I suppose. This should
>> be a common restriction across vendors. Do you think it is valuable
>> to let iommu core block such an attempt?
> 
> Yeah, maybe.

There's no functional reason to disallow it for Arm SMMUs, at least, so 
it's something that could potentially want relaxing back to per-driver 
in future. I've heard murmurings over the years about potential 
use-cases for SVA with platform and/or non-PASID PCI devices, but never 
anything concrete for existing hardware. I imagine we can expect to see 
more SVA-interested on-chip accelerators in future, but whether they'll 
all be nice and support Substreams (i.e. "platform PASIDs") is the 
question...

Thanks,
Robin.