* [RFC 0/5] Clean up VMD DMA Map Ops @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick Inspired by Christoph's last set: https://lkml.org/lkml/2019/8/28/667 VMD currently works with VT-d enabled by pointing DMA and IOMMU actions at the VMD endpoint. The problem with this approach is that the VMD endpoint's device-specific attributes, such as the dma mask, are used instead. This set cleans up VMD by removing the override that redirects dma map operations to the VMD endpoint. Instead it introduces a new dma alias mechanism into the existing dma alias infrastructure. Patch 1 and 2 are miscellaneous fixes discovered during development. Patch 1 is ready, but 2 likely doesn't go far enough for proper teardown on addition failure. Jon Derrick (5): iommu: Remove device link to group on failure iommu/vt-d: Unlink device if failed to add to group x86/PCI: Expose VMD's device in pci_sysdata PCI: vmd: Stop overriding dma_map_ops x86/PCI: Remove unused X86_DEV_DMA_OPS arch/x86/Kconfig | 3 - arch/x86/include/asm/device.h | 10 --- arch/x86/include/asm/pci.h | 4 +- arch/x86/pci/common.c | 44 ++---------- drivers/iommu/intel-iommu.c | 26 ++++--- drivers/iommu/iommu.c | 1 + drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 152 +---------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 11 files changed, 37 insertions(+), 215 deletions(-) -- 1.8.3.1 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 0/5] Clean up VMD DMA Map Ops @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick Inspired by Christoph's last set: https://lkml.org/lkml/2019/8/28/667 VMD currently works with VT-d enabled by pointing DMA and IOMMU actions at the VMD endpoint. The problem with this approach is that the VMD endpoint's device-specific attributes, such as the dma mask, are used instead. This set cleans up VMD by removing the override that redirects dma map operations to the VMD endpoint. Instead it introduces a new dma alias mechanism into the existing dma alias infrastructure. Patch 1 and 2 are miscellaneous fixes discovered during development. Patch 1 is ready, but 2 likely doesn't go far enough for proper teardown on addition failure. Jon Derrick (5): iommu: Remove device link to group on failure iommu/vt-d: Unlink device if failed to add to group x86/PCI: Expose VMD's device in pci_sysdata PCI: vmd: Stop overriding dma_map_ops x86/PCI: Remove unused X86_DEV_DMA_OPS arch/x86/Kconfig | 3 - arch/x86/include/asm/device.h | 10 --- arch/x86/include/asm/pci.h | 4 +- arch/x86/pci/common.c | 44 ++---------- drivers/iommu/intel-iommu.c | 26 ++++--- drivers/iommu/iommu.c | 1 + drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 152 +---------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 11 files changed, 37 insertions(+), 215 deletions(-) -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 1/5] iommu: Remove device link to group on failure 2019-12-31 20:24 ` Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick -1 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index d5174f0..3e35284 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) mutex_unlock(&group->mutex); dev->iommu_group = NULL; kobject_put(group->devices_kobj); + sysfs_remove_link(group->devices_kobj, device->name); err_free_name: kfree(device->name); err_remove_link: -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [RFC 1/5] iommu: Remove device link to group on failure @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index d5174f0..3e35284 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) mutex_unlock(&group->mutex); dev->iommu_group = NULL; kobject_put(group->devices_kobj); + sysfs_remove_link(group->devices_kobj, device->name); err_free_name: kfree(device->name); err_remove_link: -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 1/5] iommu: Remove device link to group on failure 2019-12-31 20:24 ` Jon Derrick @ 2020-01-01 3:59 ` Lu Baolu -1 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-01 3:59 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse Hi, On 1/1/20 4:24 AM, Jon Derrick wrote: > This adds the missing teardown step that removes the device link from > the group when the device addition fails. This change looks good to me. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > --- > drivers/iommu/iommu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index d5174f0..3e35284 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > mutex_unlock(&group->mutex); > dev->iommu_group = NULL; > kobject_put(group->devices_kobj); > + sysfs_remove_link(group->devices_kobj, device->name); > err_free_name: > kfree(device->name); > err_remove_link: > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 1/5] iommu: Remove device link to group on failure @ 2020-01-01 3:59 ` Lu Baolu 0 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-01 3:59 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig Hi, On 1/1/20 4:24 AM, Jon Derrick wrote: > This adds the missing teardown step that removes the device link from > the group when the device addition fails. This change looks good to me. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > --- > drivers/iommu/iommu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index d5174f0..3e35284 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > mutex_unlock(&group->mutex); > dev->iommu_group = NULL; > kobject_put(group->devices_kobj); > + sysfs_remove_link(group->devices_kobj, device->name); > err_free_name: > kfree(device->name); > err_remove_link: > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 ` Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick -1 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/intel-iommu.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index b2526a4..978d502 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) group = iommu_group_get_for_dev(dev); - if (IS_ERR(group)) - return PTR_ERR(group); + if (IS_ERR(group)) { + ret = PTR_ERR(group); + goto unlink; + } iommu_group_put(group); @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) if (!get_private_domain_for_dev(dev)) { dev_warn(dev, "Failed to get a private domain.\n"); - return -ENOMEM; + ret = -ENOMEM; + goto unlink; } dev_info(dev, @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) } return 0; + +unlink: + iommu_device_unlink(&iommu->iommu, dev); + return ret; } static void intel_iommu_remove_device(struct device *dev) -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/intel-iommu.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index b2526a4..978d502 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) group = iommu_group_get_for_dev(dev); - if (IS_ERR(group)) - return PTR_ERR(group); + if (IS_ERR(group)) { + ret = PTR_ERR(group); + goto unlink; + } iommu_group_put(group); @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) if (!get_private_domain_for_dev(dev)) { dev_warn(dev, "Failed to get a private domain.\n"); - return -ENOMEM; + ret = -ENOMEM; + goto unlink; } dev_info(dev, @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) } return 0; + +unlink: + iommu_device_unlink(&iommu->iommu, dev); + return ret; } static void intel_iommu_remove_device(struct device *dev) -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 ` Jon Derrick @ 2020-01-01 4:05 ` Lu Baolu -1 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-01 4:05 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This fix looks reasonable to me. Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > --- > drivers/iommu/intel-iommu.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index b2526a4..978d502 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) > > group = iommu_group_get_for_dev(dev); > > - if (IS_ERR(group)) > - return PTR_ERR(group); > + if (IS_ERR(group)) { > + ret = PTR_ERR(group); > + goto unlink; > + } > > iommu_group_put(group); > > @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) > if (!get_private_domain_for_dev(dev)) { > dev_warn(dev, > "Failed to get a private domain.\n"); > - return -ENOMEM; > + ret = -ENOMEM; > + goto unlink; > } > > dev_info(dev, > @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) > } > > return 0; > + > +unlink: > + iommu_device_unlink(&iommu->iommu, dev); > + return ret; > } > > static void intel_iommu_remove_device(struct device *dev) > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group @ 2020-01-01 4:05 ` Lu Baolu 0 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-01 4:05 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This fix looks reasonable to me. Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > --- > drivers/iommu/intel-iommu.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index b2526a4..978d502 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) > > group = iommu_group_get_for_dev(dev); > > - if (IS_ERR(group)) > - return PTR_ERR(group); > + if (IS_ERR(group)) { > + ret = PTR_ERR(group); > + goto unlink; > + } > > iommu_group_put(group); > > @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) > if (!get_private_domain_for_dev(dev)) { > dev_warn(dev, > "Failed to get a private domain.\n"); > - return -ENOMEM; > + ret = -ENOMEM; > + goto unlink; > } > > dev_info(dev, > @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) > } > > return 0; > + > +unlink: > + iommu_device_unlink(&iommu->iommu, dev); > + return ret; > } > > static void intel_iommu_remove_device(struct device *dev) > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 ` Jon Derrick @ 2020-01-12 1:36 ` Lu Baolu -1 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-12 1:36 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> Queued for v5.6. Best regards, baolu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group @ 2020-01-12 1:36 ` Lu Baolu 0 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-12 1:36 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> Queued for v5.6. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2020-01-12 1:36 ` Lu Baolu @ 2020-01-13 12:20 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-01-13 12:20 UTC (permalink / raw) To: Lu Baolu Cc: Jon Derrick, iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Christoph Hellwig, David Woodhouse On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: > On 1/1/20 4:24 AM, Jon Derrick wrote: > > If the device fails to be added to the group, make sure to unlink the > > reference before returning. > > > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> > > Queued for v5.6. No need to do so, I sent it upstream with the last pile of iommu fixes. Thanks, Joerg ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group @ 2020-01-13 12:20 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-01-13 12:20 UTC (permalink / raw) To: Lu Baolu Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: > On 1/1/20 4:24 AM, Jon Derrick wrote: > > If the device fails to be added to the group, make sure to unlink the > > reference before returning. > > > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> > > Queued for v5.6. No need to do so, I sent it upstream with the last pile of iommu fixes. Thanks, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2020-01-13 12:20 ` Joerg Roedel @ 2020-01-14 1:58 ` Lu Baolu -1 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-14 1:58 UTC (permalink / raw) To: Joerg Roedel Cc: baolu.lu, Jon Derrick, iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Christoph Hellwig, David Woodhouse On 1/13/20 8:20 PM, Joerg Roedel wrote: > On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: >> On 1/1/20 4:24 AM, Jon Derrick wrote: >>> If the device fails to be added to the group, make sure to unlink the >>> reference before returning. >>> >>> Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> >> >> Queued for v5.6. > > No need to do so, I sent it upstream with the last pile of iommu fixes. Got it. Thank you! Best regards, baolu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group @ 2020-01-14 1:58 ` Lu Baolu 0 siblings, 0 replies; 40+ messages in thread From: Lu Baolu @ 2020-01-14 1:58 UTC (permalink / raw) To: Joerg Roedel Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick On 1/13/20 8:20 PM, Joerg Roedel wrote: > On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: >> On 1/1/20 4:24 AM, Jon Derrick wrote: >>> If the device fails to be added to the group, make sure to unlink the >>> reference before returning. >>> >>> Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> >> >> Queued for v5.6. > > No need to do so, I sent it upstream with the last pile of iommu fixes. Got it. Thank you! Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2019-12-31 20:24 ` Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick -1 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick To be used by intel-iommu code to find the correct domain. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/include/asm/pci.h | 4 ++-- drivers/pci/controller/vmd.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index 90d0731..7656807 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -25,7 +25,7 @@ struct pci_sysdata { void *fwnode; /* IRQ domain for MSI assignment */ #endif #if IS_ENABLED(CONFIG_VMD) - bool vmd_domain; /* True if in Intel VMD domain */ + struct device *vmd_dev; /* Non-null if in Intel VMD domain */ #endif }; @@ -65,7 +65,7 @@ static inline bool is_vmd(struct pci_bus *bus) #if IS_ENABLED(CONFIG_VMD) struct pci_sysdata *sd = bus->sysdata; - return sd->vmd_domain; + return !!sd->vmd_dev; #else return false; #endif diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 2128422..907b5bd 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -679,7 +679,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) .parent = res, }; - sd->vmd_domain = true; + sd->vmd_dev = &vmd->dev->dev; sd->domain = vmd_find_free_domain(); if (sd->domain < 0) return sd->domain; -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick To be used by intel-iommu code to find the correct domain. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/include/asm/pci.h | 4 ++-- drivers/pci/controller/vmd.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index 90d0731..7656807 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -25,7 +25,7 @@ struct pci_sysdata { void *fwnode; /* IRQ domain for MSI assignment */ #endif #if IS_ENABLED(CONFIG_VMD) - bool vmd_domain; /* True if in Intel VMD domain */ + struct device *vmd_dev; /* Non-null if in Intel VMD domain */ #endif }; @@ -65,7 +65,7 @@ static inline bool is_vmd(struct pci_bus *bus) #if IS_ENABLED(CONFIG_VMD) struct pci_sysdata *sd = bus->sysdata; - return sd->vmd_domain; + return !!sd->vmd_dev; #else return false; #endif diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 2128422..907b5bd 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -679,7 +679,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) .parent = res, }; - sd->vmd_domain = true; + sd->vmd_dev = &vmd->dev->dev; sd->domain = vmd_find_free_domain(); if (sd->domain < 0) return sd->domain; -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2019-12-31 20:24 ` Jon Derrick @ 2020-01-09 14:33 ` Christoph Hellwig -1 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:33 UTC (permalink / raw) To: Jon Derrick Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > To be used by intel-iommu code to find the correct domain. Any reason to prefer this version over my patches 2 and 3 from the series in August? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata @ 2020-01-09 14:33 ` Christoph Hellwig 0 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:33 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > To be used by intel-iommu code to find the correct domain. Any reason to prefer this version over my patches 2 and 3 from the series in August? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2020-01-09 14:33 ` Christoph Hellwig @ 2020-01-09 15:06 ` Derrick, Jonathan -1 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2, linux-pci On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? Mine uses the correct device's dma mask ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata @ 2020-01-09 15:06 ` Derrick, Jonathan 0 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? Mine uses the correct device's dma mask _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2020-01-09 14:33 ` Christoph Hellwig @ 2020-01-09 16:45 ` Derrick, Jonathan -1 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 16:45 UTC (permalink / raw) To: hch Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2, linux-pci On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? 2 & 3 of your set is fine. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata @ 2020-01-09 16:45 ` Derrick, Jonathan 0 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 16:45 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? 2 & 3 of your set is fine. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 ` Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick -1 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick Devices on the VMD domain use the VMD endpoint's requester-id and have been relying on the VMD endpoint's dma operations. The downside of this was that VMD domain devices would use the VMD endpoint's attributes when doing DMA and IOMMU mapping. We can be smarter about this by only using the VMD endpoint when mapping and providing the correct child device's attributes during dma operations. This patch adds a new dma alias mechanism by adding a hint to a pci_dev to point to a singular DMA requester's pci_dev. This integrates into the existing dma alias infrastructure to reduce the impact of the changes required to support this mode. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/pci/common.c | 6 +- drivers/iommu/intel-iommu.c | 13 ++-- drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 150 ----------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 7 files changed, 23 insertions(+), 158 deletions(-) diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 1e59df0..4022609 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -664,8 +664,12 @@ static void set_dma_domain_ops(struct pci_dev *pdev) {} static void set_dev_domain_options(struct pci_dev *pdev) { - if (is_vmd(pdev->bus)) + if (is_vmd(pdev->bus)) { + struct pci_sysdata *sd = pdev->bus->sysdata; + + pdev->dma_parent = to_pci_dev(sd->vmd_dev); pdev->hotplug_user_indicators = 1; + } } int pcibios_add_device(struct pci_dev *dev) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 978d502..5aee648 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -776,11 +776,8 @@ static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devf pdev = to_pci_dev(dev); -#ifdef CONFIG_X86 - /* VMD child devices currently cannot be handled individually */ - if (is_vmd(pdev->bus)) - return NULL; -#endif + if (pdev->dma_parent) + pdev = pdev->dma_parent; /* VFs aren't listed in scope tables; we need to look up * the PF instead to find the IOMMU. */ @@ -2428,6 +2425,12 @@ static struct dmar_domain *find_domain(struct device *dev) dev->archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO)) return NULL; + if (dev_is_pci(dev)) { + struct pci_dev *pdev = to_pci_dev(dev); + if (pdev->dma_parent) + dev = &pdev->dma_parent->dev; + } + /* No lock here, assumes no domain exit in normal case */ info = dev->archdata.iommu; if (likely(info)) diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig index c77069c..55671429 100644 --- a/drivers/pci/controller/Kconfig +++ b/drivers/pci/controller/Kconfig @@ -239,7 +239,6 @@ config PCIE_TANGO_SMP8759 config VMD depends on PCI_MSI && X86_64 && SRCU - select X86_DEV_DMA_OPS tristate "Intel Volume Management Device Driver" ---help--- Adds support for the Intel Volume Management Device (VMD). VMD is a diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 907b5bd..5824a39 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -98,9 +98,6 @@ struct vmd_dev { struct irq_domain *irq_domain; struct pci_bus *bus; u8 busn_start; - - struct dma_map_ops dma_ops; - struct dma_domain dma_domain; }; static inline struct vmd_dev *vmd_from_bus(struct pci_bus *bus) @@ -295,151 +292,6 @@ static void vmd_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) .chip = &vmd_msi_controller, }; -/* - * VMD replaces the requester ID with its own. DMA mappings for devices in a - * VMD domain need to be mapped for the VMD, not the device requiring - * the mapping. - */ -static struct device *to_vmd_dev(struct device *dev) -{ - struct pci_dev *pdev = to_pci_dev(dev); - struct vmd_dev *vmd = vmd_from_bus(pdev->bus); - - return &vmd->dev->dev; -} - -static void *vmd_alloc(struct device *dev, size_t size, dma_addr_t *addr, - gfp_t flag, unsigned long attrs) -{ - return dma_alloc_attrs(to_vmd_dev(dev), size, addr, flag, attrs); -} - -static void vmd_free(struct device *dev, size_t size, void *vaddr, - dma_addr_t addr, unsigned long attrs) -{ - return dma_free_attrs(to_vmd_dev(dev), size, vaddr, addr, attrs); -} - -static int vmd_mmap(struct device *dev, struct vm_area_struct *vma, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_mmap_attrs(to_vmd_dev(dev), vma, cpu_addr, addr, size, - attrs); -} - -static int vmd_get_sgtable(struct device *dev, struct sg_table *sgt, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_get_sgtable_attrs(to_vmd_dev(dev), sgt, cpu_addr, addr, size, - attrs); -} - -static dma_addr_t vmd_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, - enum dma_data_direction dir, - unsigned long attrs) -{ - return dma_map_page_attrs(to_vmd_dev(dev), page, offset, size, dir, - attrs); -} - -static void vmd_unmap_page(struct device *dev, dma_addr_t addr, size_t size, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_page_attrs(to_vmd_dev(dev), addr, size, dir, attrs); -} - -static int vmd_map_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - return dma_map_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_sync_single_for_cpu(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_cpu(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_single_for_device(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_device(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_cpu(to_vmd_dev(dev), sg, nents, dir); -} - -static void vmd_sync_sg_for_device(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_device(to_vmd_dev(dev), sg, nents, dir); -} - -static int vmd_dma_supported(struct device *dev, u64 mask) -{ - return dma_supported(to_vmd_dev(dev), mask); -} - -static u64 vmd_get_required_mask(struct device *dev) -{ - return dma_get_required_mask(to_vmd_dev(dev)); -} - -static void vmd_teardown_dma_ops(struct vmd_dev *vmd) -{ - struct dma_domain *domain = &vmd->dma_domain; - - if (get_dma_ops(&vmd->dev->dev)) - del_dma_domain(domain); -} - -#define ASSIGN_VMD_DMA_OPS(source, dest, fn) \ - do { \ - if (source->fn) \ - dest->fn = vmd_##fn; \ - } while (0) - -static void vmd_setup_dma_ops(struct vmd_dev *vmd) -{ - const struct dma_map_ops *source = get_dma_ops(&vmd->dev->dev); - struct dma_map_ops *dest = &vmd->dma_ops; - struct dma_domain *domain = &vmd->dma_domain; - - domain->domain_nr = vmd->sysdata.domain; - domain->dma_ops = dest; - - if (!source) - return; - ASSIGN_VMD_DMA_OPS(source, dest, alloc); - ASSIGN_VMD_DMA_OPS(source, dest, free); - ASSIGN_VMD_DMA_OPS(source, dest, mmap); - ASSIGN_VMD_DMA_OPS(source, dest, get_sgtable); - ASSIGN_VMD_DMA_OPS(source, dest, map_page); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_page); - ASSIGN_VMD_DMA_OPS(source, dest, map_sg); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_sg); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, dma_supported); - ASSIGN_VMD_DMA_OPS(source, dest, get_required_mask); - add_dma_domain(domain); -} -#undef ASSIGN_VMD_DMA_OPS - static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus, unsigned int devfn, int reg, int len) { @@ -709,7 +561,6 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) } vmd_attach_resources(vmd); - vmd_setup_dma_ops(vmd); dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain); pci_scan_child_bus(vmd->bus); @@ -824,7 +675,6 @@ static void vmd_remove(struct pci_dev *dev) pci_stop_root_bus(vmd->bus); pci_remove_root_bus(vmd->bus); vmd_cleanup_srcu(vmd); - vmd_teardown_dma_ops(vmd); vmd_detach_resources(vmd); irq_domain_remove(vmd->irq_domain); } diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index ad746d9..ef7f219 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -6034,7 +6034,9 @@ bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2) return (dev1->dma_alias_mask && test_bit(dev2->devfn, dev1->dma_alias_mask)) || (dev2->dma_alias_mask && - test_bit(dev1->devfn, dev2->dma_alias_mask)); + test_bit(dev1->devfn, dev2->dma_alias_mask)) || + (dev1->dma_parent && dev1->dma_parent == dev2) || + (dev2->dma_parent && dev2->dma_parent == dev1); } bool pci_device_is_present(struct pci_dev *pdev) diff --git a/drivers/pci/search.c b/drivers/pci/search.c index bade140..a1d4899 100644 --- a/drivers/pci/search.c +++ b/drivers/pci/search.c @@ -32,6 +32,12 @@ int pci_for_each_dma_alias(struct pci_dev *pdev, struct pci_bus *bus; int ret; + if (unlikely(pdev->dma_parent)) { + pdev = pdev->dma_parent; + return fn(pdev, PCI_DEVID(pdev->bus->number, pdev->devfn), + data); + } + ret = fn(pdev, pci_dev_id(pdev), data); if (ret) return ret; diff --git a/include/linux/pci.h b/include/linux/pci.h index c393dff..0a10d1e 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -316,6 +316,7 @@ struct pci_dev { u8 pin; /* Interrupt pin this device uses */ u16 pcie_flags_reg; /* Cached PCIe Capabilities Register */ unsigned long *dma_alias_mask;/* Mask of enabled devfn aliases */ + struct pci_dev *dma_parent; /* DMA requester on another bus */ struct pci_driver *driver; /* Driver bound to this device */ u64 dma_mask; /* Mask of the bits of bus address this -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick Devices on the VMD domain use the VMD endpoint's requester-id and have been relying on the VMD endpoint's dma operations. The downside of this was that VMD domain devices would use the VMD endpoint's attributes when doing DMA and IOMMU mapping. We can be smarter about this by only using the VMD endpoint when mapping and providing the correct child device's attributes during dma operations. This patch adds a new dma alias mechanism by adding a hint to a pci_dev to point to a singular DMA requester's pci_dev. This integrates into the existing dma alias infrastructure to reduce the impact of the changes required to support this mode. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/pci/common.c | 6 +- drivers/iommu/intel-iommu.c | 13 ++-- drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 150 ----------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 7 files changed, 23 insertions(+), 158 deletions(-) diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 1e59df0..4022609 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -664,8 +664,12 @@ static void set_dma_domain_ops(struct pci_dev *pdev) {} static void set_dev_domain_options(struct pci_dev *pdev) { - if (is_vmd(pdev->bus)) + if (is_vmd(pdev->bus)) { + struct pci_sysdata *sd = pdev->bus->sysdata; + + pdev->dma_parent = to_pci_dev(sd->vmd_dev); pdev->hotplug_user_indicators = 1; + } } int pcibios_add_device(struct pci_dev *dev) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 978d502..5aee648 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -776,11 +776,8 @@ static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devf pdev = to_pci_dev(dev); -#ifdef CONFIG_X86 - /* VMD child devices currently cannot be handled individually */ - if (is_vmd(pdev->bus)) - return NULL; -#endif + if (pdev->dma_parent) + pdev = pdev->dma_parent; /* VFs aren't listed in scope tables; we need to look up * the PF instead to find the IOMMU. */ @@ -2428,6 +2425,12 @@ static struct dmar_domain *find_domain(struct device *dev) dev->archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO)) return NULL; + if (dev_is_pci(dev)) { + struct pci_dev *pdev = to_pci_dev(dev); + if (pdev->dma_parent) + dev = &pdev->dma_parent->dev; + } + /* No lock here, assumes no domain exit in normal case */ info = dev->archdata.iommu; if (likely(info)) diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig index c77069c..55671429 100644 --- a/drivers/pci/controller/Kconfig +++ b/drivers/pci/controller/Kconfig @@ -239,7 +239,6 @@ config PCIE_TANGO_SMP8759 config VMD depends on PCI_MSI && X86_64 && SRCU - select X86_DEV_DMA_OPS tristate "Intel Volume Management Device Driver" ---help--- Adds support for the Intel Volume Management Device (VMD). VMD is a diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 907b5bd..5824a39 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -98,9 +98,6 @@ struct vmd_dev { struct irq_domain *irq_domain; struct pci_bus *bus; u8 busn_start; - - struct dma_map_ops dma_ops; - struct dma_domain dma_domain; }; static inline struct vmd_dev *vmd_from_bus(struct pci_bus *bus) @@ -295,151 +292,6 @@ static void vmd_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) .chip = &vmd_msi_controller, }; -/* - * VMD replaces the requester ID with its own. DMA mappings for devices in a - * VMD domain need to be mapped for the VMD, not the device requiring - * the mapping. - */ -static struct device *to_vmd_dev(struct device *dev) -{ - struct pci_dev *pdev = to_pci_dev(dev); - struct vmd_dev *vmd = vmd_from_bus(pdev->bus); - - return &vmd->dev->dev; -} - -static void *vmd_alloc(struct device *dev, size_t size, dma_addr_t *addr, - gfp_t flag, unsigned long attrs) -{ - return dma_alloc_attrs(to_vmd_dev(dev), size, addr, flag, attrs); -} - -static void vmd_free(struct device *dev, size_t size, void *vaddr, - dma_addr_t addr, unsigned long attrs) -{ - return dma_free_attrs(to_vmd_dev(dev), size, vaddr, addr, attrs); -} - -static int vmd_mmap(struct device *dev, struct vm_area_struct *vma, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_mmap_attrs(to_vmd_dev(dev), vma, cpu_addr, addr, size, - attrs); -} - -static int vmd_get_sgtable(struct device *dev, struct sg_table *sgt, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_get_sgtable_attrs(to_vmd_dev(dev), sgt, cpu_addr, addr, size, - attrs); -} - -static dma_addr_t vmd_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, - enum dma_data_direction dir, - unsigned long attrs) -{ - return dma_map_page_attrs(to_vmd_dev(dev), page, offset, size, dir, - attrs); -} - -static void vmd_unmap_page(struct device *dev, dma_addr_t addr, size_t size, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_page_attrs(to_vmd_dev(dev), addr, size, dir, attrs); -} - -static int vmd_map_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - return dma_map_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_sync_single_for_cpu(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_cpu(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_single_for_device(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_device(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_cpu(to_vmd_dev(dev), sg, nents, dir); -} - -static void vmd_sync_sg_for_device(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_device(to_vmd_dev(dev), sg, nents, dir); -} - -static int vmd_dma_supported(struct device *dev, u64 mask) -{ - return dma_supported(to_vmd_dev(dev), mask); -} - -static u64 vmd_get_required_mask(struct device *dev) -{ - return dma_get_required_mask(to_vmd_dev(dev)); -} - -static void vmd_teardown_dma_ops(struct vmd_dev *vmd) -{ - struct dma_domain *domain = &vmd->dma_domain; - - if (get_dma_ops(&vmd->dev->dev)) - del_dma_domain(domain); -} - -#define ASSIGN_VMD_DMA_OPS(source, dest, fn) \ - do { \ - if (source->fn) \ - dest->fn = vmd_##fn; \ - } while (0) - -static void vmd_setup_dma_ops(struct vmd_dev *vmd) -{ - const struct dma_map_ops *source = get_dma_ops(&vmd->dev->dev); - struct dma_map_ops *dest = &vmd->dma_ops; - struct dma_domain *domain = &vmd->dma_domain; - - domain->domain_nr = vmd->sysdata.domain; - domain->dma_ops = dest; - - if (!source) - return; - ASSIGN_VMD_DMA_OPS(source, dest, alloc); - ASSIGN_VMD_DMA_OPS(source, dest, free); - ASSIGN_VMD_DMA_OPS(source, dest, mmap); - ASSIGN_VMD_DMA_OPS(source, dest, get_sgtable); - ASSIGN_VMD_DMA_OPS(source, dest, map_page); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_page); - ASSIGN_VMD_DMA_OPS(source, dest, map_sg); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_sg); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, dma_supported); - ASSIGN_VMD_DMA_OPS(source, dest, get_required_mask); - add_dma_domain(domain); -} -#undef ASSIGN_VMD_DMA_OPS - static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus, unsigned int devfn, int reg, int len) { @@ -709,7 +561,6 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) } vmd_attach_resources(vmd); - vmd_setup_dma_ops(vmd); dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain); pci_scan_child_bus(vmd->bus); @@ -824,7 +675,6 @@ static void vmd_remove(struct pci_dev *dev) pci_stop_root_bus(vmd->bus); pci_remove_root_bus(vmd->bus); vmd_cleanup_srcu(vmd); - vmd_teardown_dma_ops(vmd); vmd_detach_resources(vmd); irq_domain_remove(vmd->irq_domain); } diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index ad746d9..ef7f219 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -6034,7 +6034,9 @@ bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2) return (dev1->dma_alias_mask && test_bit(dev2->devfn, dev1->dma_alias_mask)) || (dev2->dma_alias_mask && - test_bit(dev1->devfn, dev2->dma_alias_mask)); + test_bit(dev1->devfn, dev2->dma_alias_mask)) || + (dev1->dma_parent && dev1->dma_parent == dev2) || + (dev2->dma_parent && dev2->dma_parent == dev1); } bool pci_device_is_present(struct pci_dev *pdev) diff --git a/drivers/pci/search.c b/drivers/pci/search.c index bade140..a1d4899 100644 --- a/drivers/pci/search.c +++ b/drivers/pci/search.c @@ -32,6 +32,12 @@ int pci_for_each_dma_alias(struct pci_dev *pdev, struct pci_bus *bus; int ret; + if (unlikely(pdev->dma_parent)) { + pdev = pdev->dma_parent; + return fn(pdev, PCI_DEVID(pdev->bus->number, pdev->devfn), + data); + } + ret = fn(pdev, pci_dev_id(pdev), data); if (ret) return ret; diff --git a/include/linux/pci.h b/include/linux/pci.h index c393dff..0a10d1e 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -316,6 +316,7 @@ struct pci_dev { u8 pin; /* Interrupt pin this device uses */ u16 pcie_flags_reg; /* Cached PCIe Capabilities Register */ unsigned long *dma_alias_mask;/* Mask of enabled devfn aliases */ + struct pci_dev *dma_parent; /* DMA requester on another bus */ struct pci_driver *driver; /* Driver bound to this device */ u64 dma_mask; /* Mask of the bits of bus address this -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 ` Jon Derrick (?) @ 2020-01-03 15:00 ` kbuild test robot -1 siblings, 0 replies; 40+ messages in thread From: kbuild test robot @ 2020-01-03 15:00 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 5222 bytes --] Hi Jon, [FYI, it's a private test report for your RFC patch.] [auto build test ERROR on pci/next] [also build test ERROR on iommu/next tip/x86/core v5.5-rc4 next-20191220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Jon-Derrick/Clean-up-VMD-DMA-Map-Ops/20200103-175834 base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next config: x86_64-lkp (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp@intel.com> All error/warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/percpu.h:45:0, from arch/x86/include/asm/current.h:6, from include/linux/sched.h:12, from arch/x86/pci/common.c:8: arch/x86/pci/common.c: In function 'set_dev_domain_options': >> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/kernel.h:995:26: note: in definition of macro 'container_of' void *__mptr = (void *)(ptr); \ ^~~ >> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ In file included from arch/x86/include/asm/current.h:5:0, from include/linux/sched.h:12, from arch/x86/pci/common.c:8: >> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' if (!(condition)) \ ^~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:996:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~ >> include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ >> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ >> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' if (!(condition)) \ ^~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:997:6: note: in expansion of macro '__same_type' !__same_type(*(ptr), void), \ ^~~~~~~~~~~ >> include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ >> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ vim +670 arch/x86/pci/common.c 664 665 static void set_dev_domain_options(struct pci_dev *pdev) 666 { 667 if (is_vmd(pdev->bus)) { 668 struct pci_sysdata *sd = pdev->bus->sysdata; 669 > 670 pdev->dma_parent = to_pci_dev(sd->vmd_dev); 671 pdev->hotplug_user_indicators = 1; 672 } 673 } 674 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 28801 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 ` Jon Derrick (?) (?) @ 2020-01-04 9:39 ` kbuild test robot -1 siblings, 0 replies; 40+ messages in thread From: kbuild test robot @ 2020-01-04 9:39 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 14231 bytes --] Hi Jon, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on pci/next] [also build test WARNING on iommu/next tip/x86/core v5.5-rc4 next-20191220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Jon-Derrick/Clean-up-VMD-DMA-Map-Ops/20200103-175834 base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next config: x86_64-randconfig-f001-20200103 (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp@intel.com> All warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/percpu.h:45:0, from arch/x86/include/asm/current.h:6, from include/linux/sched.h:12, from arch/x86/pci/common.c:8: arch/x86/pci/common.c: In function 'set_dev_domain_options': arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/kernel.h:995:26: note: in definition of macro 'container_of' void *__mptr = (void *)(ptr); \ ^~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ In file included from arch/x86/include/asm/current.h:5:0, from include/linux/sched.h:12, from arch/x86/pci/common.c:8: arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var' #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond)) ^~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:996:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var' #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond)) ^~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:997:6: note: in expansion of macro '__same_type' !__same_type(*(ptr), void), \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var' #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond)) ^~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:996:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var' #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond)) ^~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:997:6: note: in expansion of macro '__same_type' !__same_type(*(ptr), void), \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:69:3: note: in definition of macro '__trace_if_value' (cond) ? \ ^~~~ include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var' #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) ) ^~~~~~~~~~~~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:996:20: note: in expansion of macro '__same_type' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^ include/linux/compiler.h:69:3: note: in definition of macro '__trace_if_value' (cond) ? \ ^~~~ include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var' #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) ) ^~~~~~~~~~~~~~ >> include/linux/compiler.h:330:3: note: in expansion of macro 'if' if (!(condition)) \ ^~ include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert' __compiletime_assert(condition, msg, prefix, suffix) ^~~~~~~~~~~~~~~~~~~~ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \ ^~~~~~~~~~~~~~~~ include/linux/kernel.h:997:6: note: in expansion of macro '__same_type' !__same_type(*(ptr), void), \ ^~~~~~~~~~~ include/linux/pci.h:486:23: note: in expansion of macro 'container_of' #define to_pci_dev(n) container_of(n, struct pci_dev, dev) ^~~~~~~~~~~~ arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev' pdev->dma_parent = to_pci_dev(sd->vmd_dev); ^~~~~~~~~~ vim +/if +330 include/linux/compiler.h c361d3e54364d1 Daniel Santos 2013-02-21 325 c03567a8e8d5cf Joe Stringer 2017-08-31 326 #ifdef __OPTIMIZE__ 9a8ab1c39970a4 Daniel Santos 2013-02-21 327 # define __compiletime_assert(condition, msg, prefix, suffix) \ 9a8ab1c39970a4 Daniel Santos 2013-02-21 328 do { \ 9a8ab1c39970a4 Daniel Santos 2013-02-21 329 extern void prefix ## suffix(void) __compiletime_error(msg); \ 81b45683487a51 Masahiro Yamada 2018-08-26 @330 if (!(condition)) \ 9a8ab1c39970a4 Daniel Santos 2013-02-21 331 prefix ## suffix(); \ 9a8ab1c39970a4 Daniel Santos 2013-02-21 332 } while (0) c03567a8e8d5cf Joe Stringer 2017-08-31 333 #else c03567a8e8d5cf Joe Stringer 2017-08-31 334 # define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0) c03567a8e8d5cf Joe Stringer 2017-08-31 335 #endif 9a8ab1c39970a4 Daniel Santos 2013-02-21 336 :::::: The code at line 330 was first introduced by commit :::::: 81b45683487a51b0f4d3b29d37f20d6d078544e4 compiler.h: give up __compiletime_assert_fallback() :::::: TO: Masahiro Yamada <yamada.masahiro@socionext.com> :::::: CC: Kees Cook <keescook@chromium.org> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 32604 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 ` Jon Derrick @ 2020-01-09 14:36 ` Christoph Hellwig -1 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:36 UTC (permalink / raw) To: Jon Derrick Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > Devices on the VMD domain use the VMD endpoint's requester-id and have > been relying on the VMD endpoint's dma operations. The downside of this > was that VMD domain devices would use the VMD endpoint's attributes when > doing DMA and IOMMU mapping. We can be smarter about this by only using > the VMD endpoint when mapping and providing the correct child device's > attributes during dma operations. > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > to point to a singular DMA requester's pci_dev. This integrates into the > existing dma alias infrastructure to reduce the impact of the changes > required to support this mode. If we want to lift this check into common code I think it should go into struct device, as that is what DMA operates on normally. That being said given that this insane hack only exists for braindamage in Intel hardware I'd rather keep it as isolated as possible. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops @ 2020-01-09 14:36 ` Christoph Hellwig 0 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:36 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > Devices on the VMD domain use the VMD endpoint's requester-id and have > been relying on the VMD endpoint's dma operations. The downside of this > was that VMD domain devices would use the VMD endpoint's attributes when > doing DMA and IOMMU mapping. We can be smarter about this by only using > the VMD endpoint when mapping and providing the correct child device's > attributes during dma operations. > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > to point to a singular DMA requester's pci_dev. This integrates into the > existing dma alias infrastructure to reduce the impact of the changes > required to support this mode. If we want to lift this check into common code I think it should go into struct device, as that is what DMA operates on normally. That being said given that this insane hack only exists for braindamage in Intel hardware I'd rather keep it as isolated as possible. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2020-01-09 14:36 ` Christoph Hellwig @ 2020-01-09 15:08 ` Derrick, Jonathan -1 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:08 UTC (permalink / raw) To: hch Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2, linux-pci On Thu, 2020-01-09 at 15:36 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > > Devices on the VMD domain use the VMD endpoint's requester-id and have > > been relying on the VMD endpoint's dma operations. The downside of this > > was that VMD domain devices would use the VMD endpoint's attributes when > > doing DMA and IOMMU mapping. We can be smarter about this by only using > > the VMD endpoint when mapping and providing the correct child device's > > attributes during dma operations. > > > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > > to point to a singular DMA requester's pci_dev. This integrates into the > > existing dma alias infrastructure to reduce the impact of the changes > > required to support this mode. > > If we want to lift this check into common code I think it should go > into struct device, as that is what DMA operates on normally. I thought about that too, but the dma alias mechanism was in pci_dev. I can prepare a new version with struct device. > That > being said given that this insane hack only exists for braindamage in > Intel hardware I'd rather keep it as isolated as possible. jmho but the footprint of the new set is pretty minimal and removes a lot of dubious code in vmd.c. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops @ 2020-01-09 15:08 ` Derrick, Jonathan 0 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:08 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:36 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > > Devices on the VMD domain use the VMD endpoint's requester-id and have > > been relying on the VMD endpoint's dma operations. The downside of this > > was that VMD domain devices would use the VMD endpoint's attributes when > > doing DMA and IOMMU mapping. We can be smarter about this by only using > > the VMD endpoint when mapping and providing the correct child device's > > attributes during dma operations. > > > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > > to point to a singular DMA requester's pci_dev. This integrates into the > > existing dma alias infrastructure to reduce the impact of the changes > > required to support this mode. > > If we want to lift this check into common code I think it should go > into struct device, as that is what DMA operates on normally. I thought about that too, but the dma alias mechanism was in pci_dev. I can prepare a new version with struct device. > That > being said given that this insane hack only exists for braindamage in > Intel hardware I'd rather keep it as isolated as possible. jmho but the footprint of the new set is pretty minimal and removes a lot of dubious code in vmd.c. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2019-12-31 20:24 ` Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick -1 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu, Jon Derrick VMD was the only user of device dma operations. Now that the IOMMU has been made aware of direct DMA aliases, VMD domain devices can reference the VMD endpoint directly and the VMD device dma operations has been made obsolete. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/Kconfig | 3 --- arch/x86/include/asm/device.h | 10 ---------- arch/x86/pci/common.c | 38 -------------------------------------- 3 files changed, 51 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5e89499..77f9426 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2955,9 +2955,6 @@ config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32 -config X86_DEV_DMA_OPS - bool - source "drivers/firmware/Kconfig" source "arch/x86/kvm/Kconfig" diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h index 5e12c63..7e31f7f 100644 --- a/arch/x86/include/asm/device.h +++ b/arch/x86/include/asm/device.h @@ -8,16 +8,6 @@ struct dev_archdata { #endif }; -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -struct dma_domain { - struct list_head node; - const struct dma_map_ops *dma_ops; - int domain_nr; -}; -void add_dma_domain(struct dma_domain *domain); -void del_dma_domain(struct dma_domain *domain); -#endif - struct pdev_archdata { }; diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 4022609..fcf03da 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -625,43 +625,6 @@ unsigned int pcibios_assign_all_busses(void) return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0; } -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -static LIST_HEAD(dma_domain_list); -static DEFINE_SPINLOCK(dma_domain_list_lock); - -void add_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_add(&domain->node, &dma_domain_list); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(add_dma_domain); - -void del_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_del(&domain->node); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(del_dma_domain); - -static void set_dma_domain_ops(struct pci_dev *pdev) -{ - struct dma_domain *domain; - - spin_lock(&dma_domain_list_lock); - list_for_each_entry(domain, &dma_domain_list, node) { - if (pci_domain_nr(pdev->bus) == domain->domain_nr) { - pdev->dev.dma_ops = domain->dma_ops; - break; - } - } - spin_unlock(&dma_domain_list_lock); -} -#else -static void set_dma_domain_ops(struct pci_dev *pdev) {} -#endif - static void set_dev_domain_options(struct pci_dev *pdev) { if (is_vmd(pdev->bus)) { @@ -701,7 +664,6 @@ int pcibios_add_device(struct pci_dev *dev) pa_data = data->next; memunmap(data); } - set_dma_domain_ops(dev); set_dev_domain_options(dev); return 0; } -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS @ 2019-12-31 20:24 ` Jon Derrick 0 siblings, 0 replies; 40+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick VMD was the only user of device dma operations. Now that the IOMMU has been made aware of direct DMA aliases, VMD domain devices can reference the VMD endpoint directly and the VMD device dma operations has been made obsolete. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/Kconfig | 3 --- arch/x86/include/asm/device.h | 10 ---------- arch/x86/pci/common.c | 38 -------------------------------------- 3 files changed, 51 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5e89499..77f9426 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2955,9 +2955,6 @@ config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32 -config X86_DEV_DMA_OPS - bool - source "drivers/firmware/Kconfig" source "arch/x86/kvm/Kconfig" diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h index 5e12c63..7e31f7f 100644 --- a/arch/x86/include/asm/device.h +++ b/arch/x86/include/asm/device.h @@ -8,16 +8,6 @@ struct dev_archdata { #endif }; -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -struct dma_domain { - struct list_head node; - const struct dma_map_ops *dma_ops; - int domain_nr; -}; -void add_dma_domain(struct dma_domain *domain); -void del_dma_domain(struct dma_domain *domain); -#endif - struct pdev_archdata { }; diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 4022609..fcf03da 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -625,43 +625,6 @@ unsigned int pcibios_assign_all_busses(void) return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0; } -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -static LIST_HEAD(dma_domain_list); -static DEFINE_SPINLOCK(dma_domain_list_lock); - -void add_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_add(&domain->node, &dma_domain_list); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(add_dma_domain); - -void del_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_del(&domain->node); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(del_dma_domain); - -static void set_dma_domain_ops(struct pci_dev *pdev) -{ - struct dma_domain *domain; - - spin_lock(&dma_domain_list_lock); - list_for_each_entry(domain, &dma_domain_list, node) { - if (pci_domain_nr(pdev->bus) == domain->domain_nr) { - pdev->dev.dma_ops = domain->dma_ops; - break; - } - } - spin_unlock(&dma_domain_list_lock); -} -#else -static void set_dma_domain_ops(struct pci_dev *pdev) {} -#endif - static void set_dev_domain_options(struct pci_dev *pdev) { if (is_vmd(pdev->bus)) { @@ -701,7 +664,6 @@ int pcibios_add_device(struct pci_dev *dev) pa_data = data->next; memunmap(data); } - set_dma_domain_ops(dev); set_dev_domain_options(dev); return 0; } -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2019-12-31 20:24 ` Jon Derrick @ 2020-01-09 14:37 ` Christoph Hellwig -1 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:37 UTC (permalink / raw) To: Jon Derrick Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > VMD was the only user of device dma operations. Now that the IOMMU has > been made aware of direct DMA aliases, VMD domain devices can reference > the VMD endpoint directly and the VMD device dma operations has been > made obsolete. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This seems to be a 1:1 copy of my patch from August? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS @ 2020-01-09 14:37 ` Christoph Hellwig 0 siblings, 0 replies; 40+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:37 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > VMD was the only user of device dma operations. Now that the IOMMU has > been made aware of direct DMA aliases, VMD domain devices can reference > the VMD endpoint directly and the VMD device dma operations has been > made obsolete. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This seems to be a 1:1 copy of my patch from August? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2020-01-09 14:37 ` Christoph Hellwig @ 2020-01-09 15:06 ` Derrick, Jonathan -1 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2, linux-pci On Thu, 2020-01-09 at 15:37 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > > VMD was the only user of device dma operations. Now that the IOMMU has > > been made aware of direct DMA aliases, VMD domain devices can reference > > the VMD endpoint directly and the VMD device dma operations has been > > made obsolete. > > > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > > This seems to be a 1:1 copy of my patch from August? Sorry I didn't notice that. I'll give you attributions. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS @ 2020-01-09 15:06 ` Derrick, Jonathan 0 siblings, 0 replies; 40+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:37 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > > VMD was the only user of device dma operations. Now that the IOMMU has > > been made aware of direct DMA aliases, VMD domain devices can reference > > the VMD endpoint directly and the VMD device dma operations has been > > made obsolete. > > > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > > This seems to be a 1:1 copy of my patch from August? Sorry I didn't notice that. I'll give you attributions. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/5] Clean up VMD DMA Map Ops 2019-12-31 20:24 ` Jon Derrick @ 2020-01-07 13:41 ` Joerg Roedel -1 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-01-07 13:41 UTC (permalink / raw) To: Jon Derrick Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Christoph Hellwig, David Woodhouse, Lu Baolu On Tue, Dec 31, 2019 at 01:24:18PM -0700, Jon Derrick wrote: > Jon Derrick (5): > iommu: Remove device link to group on failure > iommu/vt-d: Unlink device if failed to add to group Added 'Fixes:' tags to these two and applied them for v5.5, thanks. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/5] Clean up VMD DMA Map Ops @ 2020-01-07 13:41 ` Joerg Roedel 0 siblings, 0 replies; 40+ messages in thread From: Joerg Roedel @ 2020-01-07 13:41 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:18PM -0700, Jon Derrick wrote: > Jon Derrick (5): > iommu: Remove device link to group on failure > iommu/vt-d: Unlink device if failed to add to group Added 'Fixes:' tags to these two and applied them for v5.5, thanks. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2020-01-14 1:59 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2020-01-01 3:59 ` Lu Baolu 2020-01-01 3:59 ` Lu Baolu 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2020-01-01 4:05 ` Lu Baolu 2020-01-01 4:05 ` Lu Baolu 2020-01-12 1:36 ` Lu Baolu 2020-01-12 1:36 ` Lu Baolu 2020-01-13 12:20 ` Joerg Roedel 2020-01-13 12:20 ` Joerg Roedel 2020-01-14 1:58 ` Lu Baolu 2020-01-14 1:58 ` Lu Baolu 2019-12-31 20:24 ` [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2020-01-09 14:33 ` Christoph Hellwig 2020-01-09 14:33 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 16:45 ` Derrick, Jonathan 2020-01-09 16:45 ` Derrick, Jonathan 2019-12-31 20:24 ` [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2020-01-03 15:00 ` kbuild test robot 2020-01-04 9:39 ` kbuild test robot 2020-01-09 14:36 ` Christoph Hellwig 2020-01-09 14:36 ` Christoph Hellwig 2020-01-09 15:08 ` Derrick, Jonathan 2020-01-09 15:08 ` Derrick, Jonathan 2019-12-31 20:24 ` [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS Jon Derrick 2019-12-31 20:24 ` Jon Derrick 2020-01-09 14:37 ` Christoph Hellwig 2020-01-09 14:37 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-07 13:41 ` [RFC 0/5] Clean up VMD DMA Map Ops Joerg Roedel 2020-01-07 13:41 ` Joerg Roedel
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.