All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, Yi Liu <yi.l.liu@intel.com>
Cc: baolu.lu@linux.intel.com, "Tian, Kevin" <kevin.tian@intel.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>
Subject: Re: Two opens about iommufd pasid + IOPF
Date: Fri, 16 Aug 2024 21:05:01 +0800	[thread overview]
Message-ID: <7dcc6982-31db-4273-af5f-5f99982165ca@linux.intel.com> (raw)
In-Reply-To: <20240816124707.GZ2032816@nvidia.com>

On 2024/8/16 20:47, Jason Gunthorpe wrote:
> On Fri, Aug 16, 2024 at 07:50:05PM +0800, Yi Liu wrote:
>> Hi Kevin, Baolu, Jason,
>>
>> I've got two opens when rebasing iommufd pasid series on top of 6.11.
>> Would like to hear about your ideas. 🙂
>>
>> 1) How to retrieve attached domain for pasid in the iommu core. This is
>>     needed when adding domain replacement for pasid. In the before, it can
>>     be done by searching the group->pasid_array[1]. However, the
>>     group->pasid_array stores iommu_attach_handle after the iopf patch [2].
>>     IIUC, iommu_attach_handle is passed only when the domain is
>>     iopf-capable. So, if the old domain does not support iopf, then it's not
>>     able to get this old domain from the group->pasid_array when trying to
>>     do domain replacement. 🙁
>>     Not sure if any side-effect if I always pass an iommu_attach_handle even
>>     if the hwpt/domain is not iopf-capable. @Baolu?
> You should always pass the handle
> 
> Alternatively you could use the xa based encoding I showed earlier to
> store either handles or naked domains in the xarray. But really it
> seems just fine to have iommufd allocate handle memory

That works.

An alternative approach is to separate replace_pasid from set_pasid. In
that case, both new and old domains could be passed from iommufd to
replace callback.

>> 2) Should I enable/disable IOPF when attaching/detaching pasid to/from
>>     domains just like patch [3] does?
>>
>> [1]https://lore.kernel.org/linux-iommu/20240628090557.50898-2-yi.l.liu@intel.com/
>> [2]https://lore.kernel.org/linux-iommu/20240702063444.105814-2-baolu.lu@linux.intel.com/
>> [3]https://lore.kernel.org/linux-iommu/20240702063444.105814-8-baolu.lu@linux.intel.com/
> I would really like to remove IOMMU_DEV_FEAT_IOPF...

That's reasonable. Then iopf is automatically enabled when the first
iopf-capable domain is attached and disabled when the last such domain
is detached.

Thanks,
baolu

      reply	other threads:[~2024-08-16 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 11:50 Two opens about iommufd pasid + IOPF Yi Liu
2024-08-16 12:47 ` Jason Gunthorpe
2024-08-16 13:05   ` Baolu Lu [this message]

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=7dcc6982-31db-4273-af5f-5f99982165ca@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --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.