On Wed, Sep 11, 2024 at 06:25:16AM +0000, Tian, Kevin wrote:
I think so. One the reasons of introducing vIOMMU is to maintainFrom: Jason Gunthorpe<jgg@xxxxxxxxxx>does it assume that a viommu object cannot span multiple physical
Sent: Friday, September 6, 2024 2:22 AM
On Thu, Sep 05, 2024 at 11:00:49AM -0700, Nicolin Chen wrote:
On Thu, Sep 05, 2024 at 01:20:39PM -0300, Jason Gunthorpe wrote:iommufd_viommu *viommu,
On Tue, Aug 27, 2024 at 09:59:54AM -0700, Nicolin Chen wrote:
+static int arm_smmu_viommu_cache_invalidate(struct
*array)+ struct iommu_user_data_array
iommufd_viommu_to_parent_domain(viommu);+{
+ struct iommu_domain *domain =
Yes, many more patches, and don't try to do it now.. But we can copyOK. When I designed all this stuff, we still haven't made mind+I'd like to have the viommu struct directly hold the VMID. The nested
+ return __arm_smmu_cache_invalidate_user(
+ to_smmu_domain(domain), viommu, array);
parent should be sharable between multiple viommus, it doesn't make
any sense that it would hold the vmid.
This is struggling because it is trying too hard to not have the
driver allocate the viommu, and I think we should just go ahead and do
that. Store the vmid, today copied from the nesting parent in the vmid
private struct. No need for iommufd_viommu_to_parent_domain(), just
rework the APIs to pass the vmid down not a domain.
about sharing the s2 domain, i.e. moving the VMID, which might
need a couple of more patches to achieve.
the vmid from the s2 and place it in the viommu struct during
allocation time.
IOMMUs so there is only one vmid per viommu?
the shareability across physical IOMMUs at the s2 HWPT_PAGING.