From: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
yi.y.sun-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kirti Wankhede
<kwankhede-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
Date: Wed, 25 Jul 2018 09:18:21 +0800 [thread overview]
Message-ID: <5B57CFDD.1070505@linux.intel.com> (raw)
In-Reply-To: <20180724125056.4ae477c9-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
Hi Alex,
On 07/25/2018 02:50 AM, Alex Williamson wrote:
> On Sun, 22 Jul 2018 14:09:24 +0800
> Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
>> This patch adds the support to get the iommu device for a mediated
>> device. The assumption is that each mediated device is a minimal
>> assignable set of a physical PCI device. Hence, we should use the
>> iommu device of the parent PCI device to manage the translation.
> Hmm, is this absolutely a valid assumption? I'm afraid there's an
> assumption throughout this series that the only way an mdev device
> could be interacting with the IOMMU is via S-IOV, but we could choose
> today to make an mdev wrapper for any device, which might provide basic
> RID granularity to the IOMMU. So if I make an mdev wrapper for a PF
> such that I can implement migration for that device, is it valid for
> the IOMMU driver to flag me as an mdev device and base mappings on my
> parent device?
You are right. We should not make it SIOV centric. Let me look into the
patches and identify/fix the unreasonable assumptions.
> Perhaps in this patch we can assume that the parent of
> such an mdev device would be the PF backing it and that results in the
> correct drhd,
Okay.
> but in the next patch we start imposing the assumption
> that because the device is an mdev, the only valid association is via
> pasid, which I'd say is incorrect.
You are right. I will find and fix it.
>
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++
>> drivers/iommu/intel-pasid.h | 16 ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h
>> index 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev)
>> +{
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev");
>> +}
> I assume we're not using mdev_bus_type because mdev is a loadable
> module and that symbol doesn't exist in this statically loaded driver,
Yes.
> but strcmp is a pretty ugly alternative. Could we use symbol_get() so
> that we can use mdev_bus_type? Thanks,
Sure.
Best regards,
Lu Baolu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>,
David Woodhouse <dwmw2@infradead.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
ashok.raj@intel.com, sanjay.k.kumar@intel.com,
jacob.jun.pan@intel.com, kevin.tian@intel.com,
yi.l.liu@intel.com, yi.y.sun@intel.com, peterx@redhat.com,
iommu@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Jacob Pan <jacob.jun.pan@linux.intel.com>
Subject: Re: [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device
Date: Wed, 25 Jul 2018 09:18:21 +0800 [thread overview]
Message-ID: <5B57CFDD.1070505@linux.intel.com> (raw)
In-Reply-To: <20180724125056.4ae477c9@t450s.home>
Hi Alex,
On 07/25/2018 02:50 AM, Alex Williamson wrote:
> On Sun, 22 Jul 2018 14:09:24 +0800
> Lu Baolu <baolu.lu@linux.intel.com> wrote:
>
>> This patch adds the support to get the iommu device for a mediated
>> device. The assumption is that each mediated device is a minimal
>> assignable set of a physical PCI device. Hence, we should use the
>> iommu device of the parent PCI device to manage the translation.
> Hmm, is this absolutely a valid assumption? I'm afraid there's an
> assumption throughout this series that the only way an mdev device
> could be interacting with the IOMMU is via S-IOV, but we could choose
> today to make an mdev wrapper for any device, which might provide basic
> RID granularity to the IOMMU. So if I make an mdev wrapper for a PF
> such that I can implement migration for that device, is it valid for
> the IOMMU driver to flag me as an mdev device and base mappings on my
> parent device?
You are right. We should not make it SIOV centric. Let me look into the
patches and identify/fix the unreasonable assumptions.
> Perhaps in this patch we can assume that the parent of
> such an mdev device would be the PF backing it and that results in the
> correct drhd,
Okay.
> but in the next patch we start imposing the assumption
> that because the device is an mdev, the only valid association is via
> pasid, which I'd say is incorrect.
You are right. I will find and fix it.
>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 6 ++++++
>> drivers/iommu/intel-pasid.h | 16 ++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 7d198ea..fc3ac1c 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -767,6 +767,12 @@ static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devf
>> if (iommu_dummy(dev))
>> return NULL;
>>
>> + if (dev_is_mdev(dev)) {
>> + dev = dev_mdev_parent(dev);
>> + if (WARN_ON(!dev_is_pci(dev)))
>> + return NULL;
>> + }
>> +
>> if (dev_is_pci(dev)) {
>> struct pci_dev *pf_pdev;
>>
>> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h
>> index 518df72..46cde66 100644
>> --- a/drivers/iommu/intel-pasid.h
>> +++ b/drivers/iommu/intel-pasid.h
>> @@ -35,6 +35,22 @@ struct pasid_table {
>> struct list_head dev; /* device list */
>> };
>>
>> +static inline bool dev_is_mdev(struct device *dev)
>> +{
>> + if (!dev)
>> + return false;
>> +
>> + return !strcmp(dev->bus->name, "mdev");
>> +}
> I assume we're not using mdev_bus_type because mdev is a loadable
> module and that symbol doesn't exist in this statically loaded driver,
Yes.
> but strcmp is a pretty ugly alternative. Could we use symbol_get() so
> that we can use mdev_bus_type? Thanks,
Sure.
Best regards,
Lu Baolu
next prev parent reply other threads:[~2018-07-25 1:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-22 6:09 [RFC PATCH 00/10] vfio/mdev: IOMMU aware mediated device Lu Baolu
2018-07-22 6:09 ` Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 01/10] iommu/vt-d: Get iommu device for a " Lu Baolu
2018-07-23 4:44 ` Liu, Yi L
[not found] ` <A2975661238FB949B60364EF0F2C257439CA141D-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-24 2:06 ` Lu Baolu
2018-07-24 2:06 ` Lu Baolu
[not found] ` <1532239773-15325-2-git-send-email-baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-24 18:50 ` Alex Williamson
2018-07-24 18:50 ` Alex Williamson
[not found] ` <20180724125056.4ae477c9-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2018-07-25 1:18 ` Lu Baolu [this message]
2018-07-25 1:18 ` Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 02/10] iommu/vt-d: Alloc domain " Lu Baolu
2018-07-23 4:44 ` Liu, Yi L
[not found] ` <A2975661238FB949B60364EF0F2C257439CA1432-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-24 2:09 ` Lu Baolu
2018-07-24 2:09 ` Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices Lu Baolu
[not found] ` <1532239773-15325-4-git-send-email-baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-23 4:44 ` Liu, Yi L
2018-07-23 4:44 ` Liu, Yi L
[not found] ` <A2975661238FB949B60364EF0F2C257439CA143E-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-24 2:22 ` Lu Baolu
2018-07-24 2:22 ` Lu Baolu
2018-07-24 11:30 ` Jean-Philippe Brucker
2018-07-24 19:51 ` Alex Williamson
2018-07-25 2:06 ` Lu Baolu
[not found] ` <ccf6890a-30c6-770b-4299-8cabfdc32f2b-5wv7dgnIgG8@public.gmane.org>
2018-07-25 2:16 ` Tian, Kevin
2018-07-25 2:16 ` Tian, Kevin
2018-07-25 2:35 ` Liu, Yi L
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19127FB9E@SHSMSX101.ccr.corp.intel.com>
2018-07-25 6:19 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D19127FF05-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-25 19:19 ` Jean-Philippe Brucker
2018-07-25 19:19 ` Jean-Philippe Brucker
[not found] ` <a530c220-9bf1-05ec-5698-526ccbea127f-5wv7dgnIgG8@public.gmane.org>
2018-07-26 3:03 ` Tian, Kevin
2018-07-26 3:03 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D1912826A4-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-26 15:09 ` Jean-Philippe Brucker
2018-07-26 15:09 ` Jean-Philippe Brucker
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D1912826AE@SHSMSX101.ccr.corp.intel.com>
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D1912826AE-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2018-07-26 3:28 ` Tian, Kevin
2018-07-26 3:28 ` Tian, Kevin
2018-07-26 15:09 ` Jean-Philippe Brucker
2018-07-22 6:09 ` [RFC PATCH 04/10] iommu/vt-d: Get pasid table for a mediated device Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 05/10] iommu/vt-d: Setup DMA remapping for mediated devices Lu Baolu
2018-07-23 4:44 ` Liu, Yi L
2018-07-24 2:29 ` Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 06/10] iommu: Add iommu_set_bus API interface Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 07/10] iommu/vt-d: Add set_bus iommu ops Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 08/10] vfio/mdev: Set iommu ops for mdev bus Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 09/10] vfio/mdev: Add mediated device domain type Lu Baolu
2018-07-22 6:09 ` [RFC PATCH 10/10] vfio/type1: Allocate domain for mediated device 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=5B57CFDD.1070505@linux.intel.com \
--to=baolu.lu-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kwankhede-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=yi.y.sun-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/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.