On 6/2/21 1:26 AM, Jason Gunthorpe wrote:
On Tue, Jun 01, 2021 at 07:09:21PM +0800, Lu Baolu wrote:
This version only covers 1) and 4). Do you think we need to support 2),
3) and beyond?
Yes aboslutely. The API should be flexable enough to specify the
creation of all future page table formats we'd want to have and all HW
specific details on those formats.
OK, stay in the same line.
If so, it seems that we need some in-kernel helpers and uAPIs to
support pre-installing a page table to IOASID.
Not sure what this means..
Sorry that I didn't make this clear.
Let me bring back the page table types in my eyes.
1) IOMMU format page table (a.k.a. iommu_domain)
2) user application CPU page table (SVA for example)
3) KVM EPT (future option)
4) VM guest managed page table (nesting mode)
Each type of page table should be able to be associated with its IOASID.
We have BIND protocol for 4); We explicitly allocate an iommu_domain for
1). But we don't have a clear definition for 2) 3) and others. I think
it's necessary to clearly define a time point and kAPI name between
IOASID_ALLOC and IOASID_ATTACH, so that other modules have the
opportunity to associate their page table with the allocated IOASID
before attaching the page table to the real IOMMU hardware.
I/O page fault handling is similar. The provider of the page table
should take the responsibility to handle the possible page faults.
Could this answer the question of "I'm still confused why drivers need
fault handlers at all?" in below thread?
https://lore.kernel.org/linux-iommu/PH0PR12MB54811863B392C644E5365446DC3E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#m15def9e8b236dfcf97e21c8e9f8a58da214e3691
From this point of view an IOASID is actually not just a variant of
iommu_domain, but an I/O page table representation in a broader
sense.
Yes, and things need to evolve in a staged way. The ioctl API should
have room for this growth but you need to start out with some
constrained enough to actually implement then figure out how to grow
from there
Yes, agreed. I just think about it from the perspective of a design
document.
Best regards,
baolu
