From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
Kevin Tian <kevin.tian@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Ashok Raj <ashok.raj@intel.com>,
kvm@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v5 0/5] iommu aux-domain APIs extensions
Date: Fri, 25 Sep 2020 09:09:54 +0800 [thread overview]
Message-ID: <71f1fa5e-f468-0498-1ab4-1c2af9424d2d@linux.intel.com> (raw)
In-Reply-To: <20200924095532.GK27174@8bytes.org>
Hi Joerg,
On 9/24/20 5:55 PM, Joerg Roedel wrote:
> On Tue, Sep 22, 2020 at 02:10:37PM +0800, Lu Baolu wrote:
>> Hi Jorge and Alex,
>>
>> A description of this patch series could be found here.
>>
>> https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu.lu@linux.intel.com/
>
> Hmm, I am wondering if we can avoid all this hassle and special APIs by
> making the mdev framework more visible outside of the vfio code. There
> is an underlying bus implementation for mdevs, so is there a reason
> those can't use the standard iommu-core code to setup IOMMU mappings?
The original purpose of this series is to enable the device driver to
retrieve the aux-domain through iommu core after iommu
ops.aux_attach_dev().
The domain was allocated in vfio/mdev, but it's also needed by the
device driver in mediated callbacks. The idea of this patch series is to
extend the aux-API so that the domain could be saved in group->domain
and get by the mediated driver through the existing
iommu_get_domain_for_dev().
Back when we were developing the aux-domain, I proposed to keep the
domain in vfio/mdev.
https://lore.kernel.org/linux-iommu/20181105073408.21815-7-baolu.lu@linux.intel.com/
It wasn't discussed at that time due to the lack of real consumer. Intel
is now adding aux-domain support in idxd (DMA streaming accelerator)
driver which becomes the first real consumer. So this problem is brought
back to the table.
>
> What speaks against doing:
>
> - IOMMU drivers capable of handling mdevs register iommu-ops
> for the mdev_bus.
>
> - iommu_domain_alloc() takes bus_type as parameter, so there can
> be special domains be allocated for mdevs.
>
> - Group creation and domain allocation will happen
> automatically in the iommu-core when a new mdev is registered
> through device-driver core code.
>
> - There should be no need for special iommu_aux_* APIs, as one
> can attach a domain directly to &mdev->dev with
> iommu_attach_device(domain, &mdev->dev).
>
> Doing it this way will probably also keep the mdev-special code in VFIO
> small.
Fully understand now. Thanks for guide.
>
> Regards,
>
> Joerg
>
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2020-09-25 1:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 6:10 [PATCH v5 0/5] iommu aux-domain APIs extensions Lu Baolu
2020-09-22 6:10 ` [PATCH v5 1/5] iommu: Add optional subdev in aux_at(de)tach ops Lu Baolu
2020-09-22 6:10 ` [PATCH v5 2/5] iommu: Add iommu_at(de)tach_subdev_group() Lu Baolu
2020-09-22 6:10 ` [PATCH v5 3/5] iommu: Add iommu_aux_get_domain_for_dev() Lu Baolu
2020-09-22 6:10 ` [PATCH v5 4/5] vfio/type1: Use iommu_aux_at(de)tach_group() APIs Lu Baolu
2020-09-22 6:10 ` [PATCH v5 5/5] iommu/vt-d: Add is_aux_domain support Lu Baolu
2020-09-24 9:55 ` [PATCH v5 0/5] iommu aux-domain APIs extensions Joerg Roedel
2020-09-25 1:09 ` Lu Baolu [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=71f1fa5e-f468-0498-1ab4-1c2af9424d2d@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=jean-philippe@linaro.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 \
/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