From: Lu Baolu <baolu.lu@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Cornelia Huck <cohuck@redhat.com>,
Kevin Tian <kevin.tian@intel.com>,
Ashok Raj <ashok.raj@intel.com>,
Dave Jiang <dave.jiang@intel.com>, Liu Yi L <yi.l.liu@intel.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/2] iommu: iommu_aux_at(de)tach_device() extension
Date: Thu, 9 Jul 2020 08:37:08 +0800 [thread overview]
Message-ID: <f1946060-d01c-70d2-7dd5-7730694a4d46@linux.intel.com> (raw)
In-Reply-To: <20200708130749.1b1e1421@x1.home>
Hi Alex,
On 7/9/20 3:07 AM, Alex Williamson wrote:
> On Wed, 8 Jul 2020 10:53:12 +0800
> Lu Baolu <baolu.lu@linux.intel.com> wrote:
>
>> Hi Alex,
>>
>> Thanks a lot for your comments. Please check my reply inline.
>>
>> On 7/8/20 5:04 AM, Alex Williamson wrote:
>>> On Tue, 7 Jul 2020 09:39:56 +0800
>>> Lu Baolu<baolu.lu@linux.intel.com> wrote:
>>>
>>>> The hardware assistant vfio mediated device is a use case of iommu
>>>> aux-domain. The interactions between vfio/mdev and iommu during mdev
>>>> creation and passthr are:
>>>>
>>>> - Create a group for mdev with iommu_group_alloc();
>>>> - Add the device to the group with
>>>> group = iommu_group_alloc();
>>>> if (IS_ERR(group))
>>>> return PTR_ERR(group);
>>>>
>>>> ret = iommu_group_add_device(group, &mdev->dev);
>>>> if (!ret)
>>>> dev_info(&mdev->dev, "MDEV: group_id = %d\n",
>>>> iommu_group_id(group));
>>>> - Allocate an aux-domain
>>>> iommu_domain_alloc()
>>>> - Attach the aux-domain to the physical device from which the mdev is
>>>> created.
>>>> iommu_aux_attach_device()
>>>>
>>>> In the whole process, an iommu group was allocated for the mdev and an
>>>> iommu domain was attached to the group, but the group->domain leaves
>>>> NULL. As the result, iommu_get_domain_for_dev() doesn't work anymore.
>>>>
>>>> The iommu_get_domain_for_dev() is a necessary interface for device
>>>> drivers that want to support aux-domain. For example,
>>>>
>>>> struct iommu_domain *domain;
>>>> struct device *dev = mdev_dev(mdev);
>>>> unsigned long pasid;
>>>>
>>>> domain = iommu_get_domain_for_dev(dev);
>>>> if (!domain)
>>>> return -ENODEV;
>>>>
>>>> pasid = iommu_aux_get_pasid(domain, dev->parent);
>>> How did we know this was an aux domain? ie. How did we know we could
>>> use it with iommu_aux_get_pasid()?
>>
>> Yes. It's a bit confusing if iommu_get_domain_for_dev() is reused here
>> for aux-domain.
>>
>>>
>>> Why did we assume the parent device is the iommu device for the aux
>>> domain? Should that level of detail be already known by the aux domain?
>>>
>>> Nits - The iomu device of an mdev device is found via
>>> mdev_get_iommu_device(dev), it should not be assumed to be the parent.
>>> The parent of an mdev device is found via mdev_parent_dev(mdev).
>>
>> My bad. The driver should use mdev_get_iommu_device() instead.
>>
>>>
>>> The leaps in logic here make me wonder if we should instead be exposing
>>> more of an aux domain API rather than blurring the differences between
>>> these domains. Thanks,
>>
>> How about add below API?
>>
>> /**
>> * iommu_aux_get_domain_for_dev - get aux domain for a device
>> * @dev: the accessory device
>> *
>> * The caller should pass a valid @dev to iommu_aux_attach_device() before
>> * calling this api. Return an attached aux-domain, or NULL otherwise.
>
> That's not necessarily the caller's responsibility, that might happen
> elsewhere, this function simply returns an aux domain for the device if
> it's attached to one.
Yes. Fair enough. This piece of comments will be removed.
>
>> */
>> struct iommu_domain *iommu_aux_get_domain_for_dev(struct device *dev)
>> {
>> struct iommu_domain *domain = NULL;
>> struct iommu_group *group;
>>
>> group = iommu_group_get(dev);
>> if (!group)
>> return NULL;
>>
>> if (group->aux_domain_attached)
>> domain = group->domain;
>>
>> iommu_group_put(group);
>>
>> return domain;
>> }
>> EXPORT_SYMBOL_GPL(iommu_aux_get_domain_for_dev);
>
> For your example use case, this seems more clear to me. Thanks,
>
Okay, thank you!
> Alex
Best regards,
baolu
next prev parent reply other threads:[~2020-07-09 0:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 1:39 [PATCH v2 0/2] iommu_aux_at(de)tach_device() enhancement Lu Baolu
2020-07-07 1:39 ` [PATCH v2 1/2] iommu: iommu_aux_at(de)tach_device() extension Lu Baolu
2020-07-07 21:04 ` Alex Williamson
2020-07-08 2:53 ` Lu Baolu
2020-07-08 19:07 ` Alex Williamson
2020-07-09 0:37 ` Lu Baolu [this message]
2020-07-09 6:52 ` Lu Baolu
2020-07-07 1:39 ` [PATCH v2 2/2] iommu: Add aux_domain_attached flag to iommu_group Lu Baolu
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=f1946060-d01c-70d2-7dd5-7730694a4d46@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=cohuck@redhat.com \
--cc=dave.jiang@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).