Messages in this thread | | | Date | Tue, 30 Aug 2022 10:04:52 +0800 | Subject | Re: [PATCH v12 12/17] arm-smmu-v3/sva: Add SVA domain support | From | Baolu Lu <> |
| |
On 2022/8/30 01:29, Jason Gunthorpe wrote: > On Sun, Aug 28, 2022 at 09:57:21PM +0800, Baolu Lu wrote: >> On 2022/8/26 22:56, Jason Gunthorpe wrote: >>> On Fri, Aug 26, 2022 at 08:11:36PM +0800, Lu Baolu wrote: >>> >>>> +static const struct iommu_domain_ops arm_smmu_sva_domain_ops = { >>>> + .set_dev_pasid = arm_smmu_sva_set_dev_pasid, >>> Do we want to permit drivers to not allow a SVA domain to be set on a >>> RID? >>> >>> It seems like a weird restriction to me >> Conceptually as long as the page table is compatible and user pages are >> pinned (or I/O page fault is supported), the device drivers are valid to >> set SVA domain to a RID. But I don't see a real use case as far as I can >> see. > It may be interesting for something like DPDK type applications where > having the entire process address space mapped SVA to the device could > be quite nice. > > You, currently, give up interrupts, but perhaps that is solvable in some > way. > > So, IDK.. I wouldn't dismiss it entirely but I wouldn't do a bunch of > work to support it either.
Then we can do this through the set_dev callback, as it's the right callback to set a domain to the RID, right? Not sure whether it worth a new type of domain. The current implementation doesn't prevent us from achieving this in the future anyway.
> >> A reasonable use case is sharing EPT between KVM and IOMMU. That demands >> a new type of domain and implements its own .set_dev for page table >> attachment. > Not everything is virtualization:)
Yes. Fair enough. :-)
Best regards, baolu
| |