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
