All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
	iommu@lists.linux.dev, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, suravee.suthikulpanit@amd.com,
	yi.l.liu@intel.com
Subject: Re: [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging()
Date: Tue, 6 Aug 2024 09:34:52 -0300	[thread overview]
Message-ID: <20240806123452.GE676757@ziepe.ca> (raw)
In-Reply-To: <098008f7-2b3e-405a-a096-947e5df560e6@amd.com>

On Fri, Aug 02, 2024 at 11:23:52AM +0530, Vasant Hegde wrote:

> >> +    struct iommu_domain *(*domain_alloc_paging)(struct device *dev,
> >> +                            u32 iommu_domain_type, u32 flags);
> > 
> > I still can't see a value to pass the domain type in this callback.
> > Different domain could have different domain allocation callback, hence
> > the domain type has already been implied.

+1

> > For the paging domain, there should be no difference between DMA and
> > UNMNANAGED from iommu driver's point of view.
> 
> That's true. Its all paging domain. But we need a way to indicate the desired
> capability like PASID.
 
> I thoughts we can use `type` for allocating domain and then `flag` to pass the
> quirks. Otherwise we have to club everything in `flags` itself.
> 
> Something like below works ?
> 
>   - DMA-API domain : flag - DOMAIN_ALLOC_FLAG_PASID
>     If both device and IOMMU supports PASID it will allocate PASID capable
>     domain (Like AMD case domain with V2 page table). Else it will alloate
>     non-pasid capable domain (In AMD case it will be domain with v1 page table).

This is a much larger problem. The DMA API domain is created way early
before any drivers are bound. If it doesn't support PASID then no
drivers will get to use PASID at all.

You'd need to figure out some way to switch the DMA API domain on the
fly around when a PASID wanting driver binds. This might be reasonable
since PASID devices tend to need single device groups to work at all
and we could conceivably switch the group under driver control during
early binding.

For now we expect that the DMA API domain will support PASID if the
underyling device supports PASID, that is the only way this can work
today. Meaning domain_alloc_paging() must always return something that
can enable PASID.

>   - UNMANAGED domain : Do not pass *_PASID support flag
>     Since PASID flag is *not* passed, driver will decide best suitable page
>     table (in AMD case, we will allocate V1 page table)

And here this is only VFIO. When you figure out with Alex and Yi how
VFIO will decide to do PASID or not then pass that indication through
the existing flag argument on domain_alloc_user(). At least this is
pretty simple.

But as I said before, the important thing from your perspective is
that VFIO does not default-on PASID support!

Jason

  reply	other threads:[~2024-08-06 12:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01 14:45 [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging() Vasant Hegde
2024-08-02  0:44 ` Baolu Lu
2024-08-02  5:53   ` Vasant Hegde
2024-08-06 12:34     ` Jason Gunthorpe [this message]
2024-08-06 14:41       ` Vasant Hegde
2024-08-06 17:32         ` Jason Gunthorpe
2024-08-07  5:49           ` Baolu Lu
2024-08-07  9:32             ` Vasant Hegde
2024-08-07 12:33             ` Jason Gunthorpe
2024-08-07  9:30           ` Vasant Hegde
2024-08-07 13:59             ` Jason Gunthorpe
2024-08-07 16:52               ` Vasant Hegde
2024-08-07 18:29                 ` Jason Gunthorpe
2024-08-08  1:16                   ` Jason Gunthorpe
2024-08-08 13:08                     ` Jason Gunthorpe
2024-08-09  6:43                       ` Vasant Hegde
2024-08-09 13:44                         ` Jason Gunthorpe
2024-08-12  9:21                           ` Vasant Hegde
2024-08-13 16:22                             ` Jason Gunthorpe
2024-08-14 10:54                               ` Vasant Hegde
2024-08-09  5:36                   ` Vasant Hegde
2024-08-12 12:07                   ` Yi Liu
2024-08-13  9:40                   ` Tian, Kevin
2024-08-13 16:20                     ` Jason Gunthorpe
2024-08-14  2:38                       ` Tian, Kevin
2024-08-14 22:40                         ` Jason Gunthorpe
2024-08-15  3:28                           ` Vasant Hegde
2024-08-15  4:58                             ` Yi Liu
2024-08-15 13:06                               ` Jason Gunthorpe
2024-08-16 11:59                                 ` Yi Liu
2024-08-15  4:59                             ` Baolu Lu
2024-08-15 13:47                               ` Jason Gunthorpe
2024-08-16  8:17                                 ` Vasant Hegde
2024-08-16 12:01                                   ` Yi Liu
2024-08-16 18:37                                   ` Jason Gunthorpe
2024-08-19  8:27                                     ` Vasant Hegde
2024-08-19 17:52                                       ` Jason Gunthorpe
2024-08-20  8:18                                         ` Vasant Hegde
2024-08-15 13:05                             ` Jason Gunthorpe
2024-08-12 12:01               ` Yi Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240806123452.GE676757@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=robin.murphy@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.