From: Bjorn Helgaas <helgaas@kernel.org> To: Christoph Hellwig <hch@infradead.org> Cc: Lu Baolu <baolu.lu@linux.intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Joerg Roedel <joro@8bytes.org>, Alex Williamson <alex.williamson@redhat.com>, Bjorn Helgaas <bhelgaas@google.com>, Jason Gunthorpe <jgg@nvidia.com>, Kevin Tian <kevin.tian@intel.com>, Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Dan Williams <dan.j.williams@intel.com>, rafael@kernel.org, Diana Craciun <diana.craciun@oss.nxp.com>, Cornelia Huck <cohuck@redhat.com>, Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>, Jacob jun Pan <jacob.jun.pan@intel.com>, Chaitanya Kulkarni <kch@nvidia.com>, Stuart Yoder <stuyoder@gmail.com>, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Thierry Reding <thierry.reding@gmail.com>, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, Jonathan Hunter <jonathanh@nvidia.com>, Li Yang <leoyang.li@nxp.com>, Dmitry Osipenko <digetx@gmail.com>, iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces Date: Tue, 4 Jan 2022 10:41:00 -0600 [thread overview] Message-ID: <20220104164100.GA101735@bhelgaas> (raw) In-Reply-To: <YdQcgFhIMYvUwABV@infradead.org> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote: > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote: > > Multiple devices may be placed in the same IOMMU group because they > > cannot be isolated from each other. These devices must either be > > entirely under kernel control or userspace control, never a mixture. I guess the reason is that if a group contained a mixture, userspace could attack the kernel by programming a device to DMA to a device owned by the kernel? > > This adds dma ownership management in iommu core and exposes several > > interfaces for the device drivers and the device userspace assignment > > framework (i.e. vfio), so that any conflict between user and kernel > > controlled DMA could be detected at the beginning. Maybe I'm missing the point because I don't know what "conflict between user and kernel controlled DMA" is. Are you talking about both userspace and the kernel programming the same device to do DMA? > > The device driver oriented interfaces are, > > > > int iommu_device_use_dma_api(struct device *dev); > > void iommu_device_unuse_dma_api(struct device *dev); Nit, do we care whether it uses the actual DMA API? Or is it just that iommu_device_use_dma_api() tells us the driver may program the device to do DMA? > > Devices under kernel drivers control must call iommu_device_use_dma_api() > > before driver probes. The driver binding process must be aborted if it > > returns failure. "Devices" don't call functions. Drivers do, or in this case, it looks like the bus DMA code (platform, amba, fsl, pci, etc). These functions are EXPORT_SYMBOL_GPL(), but it looks like all the callers are built-in, so maybe the export is unnecessary? You use "iommu"/"IOMMU" and "dma"/"DMA" interchangeably above. Would be easier to read if you picked one. > > The vfio oriented interfaces are, > > > > int iommu_group_set_dma_owner(struct iommu_group *group, > > void *owner); > > void iommu_group_release_dma_owner(struct iommu_group *group); > > bool iommu_group_dma_owner_claimed(struct iommu_group *group); > > > > The device userspace assignment must be disallowed if the set dma owner > > interface returns failure. Can you connect this back to the "never a mixture" from the beginning? If all you cared about was prevent an IOMMU group from containing devices with a mixture of kernel drivers and userspace drivers, I assume you could do that without iommu_device_use_dma_api(). So is this a way to *allow* a mixture under certain restricted conditions? Another nit below. > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > > Signed-off-by: Kevin Tian <kevin.tian@intel.com> > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > > --- > > include/linux/iommu.h | 31 ++++++++ > > drivers/iommu/iommu.c | 161 +++++++++++++++++++++++++++++++++++++++++- > > 2 files changed, 189 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > index de0c57a567c8..568f285468cf 100644 > > --- a/include/linux/iommu.h > > +++ b/include/linux/iommu.h > > @@ -682,6 +682,13 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, > > void iommu_sva_unbind_device(struct iommu_sva *handle); > > u32 iommu_sva_get_pasid(struct iommu_sva *handle); > > > > +int iommu_device_use_dma_api(struct device *dev); > > +void iommu_device_unuse_dma_api(struct device *dev); > > + > > +int iommu_group_set_dma_owner(struct iommu_group *group, void *owner); > > +void iommu_group_release_dma_owner(struct iommu_group *group); > > +bool iommu_group_dma_owner_claimed(struct iommu_group *group); > > + > > #else /* CONFIG_IOMMU_API */ > > > > struct iommu_ops {}; > > @@ -1082,6 +1089,30 @@ static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev) > > { > > return NULL; > > } > > + > > +static inline int iommu_device_use_dma_api(struct device *dev) > > +{ > > + return 0; > > +} > > + > > +static inline void iommu_device_unuse_dma_api(struct device *dev) > > +{ > > +} > > + > > +static inline int > > +iommu_group_set_dma_owner(struct iommu_group *group, void *owner) > > +{ > > + return -ENODEV; > > +} > > + > > +static inline void iommu_group_release_dma_owner(struct iommu_group *group) > > +{ > > +} > > + > > +static inline bool iommu_group_dma_owner_claimed(struct iommu_group *group) > > +{ > > + return false; > > +} > > #endif /* CONFIG_IOMMU_API */ > > > > /** > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > index 8b86406b7162..ff0c8c1ad5af 100644 > > --- a/drivers/iommu/iommu.c > > +++ b/drivers/iommu/iommu.c > > @@ -48,6 +48,8 @@ struct iommu_group { > > struct iommu_domain *default_domain; > > struct iommu_domain *domain; > > struct list_head entry; > > + unsigned int owner_cnt; > > + void *owner; > > }; > > > > struct group_device { > > @@ -289,7 +291,12 @@ int iommu_probe_device(struct device *dev) > > mutex_lock(&group->mutex); > > iommu_alloc_default_domain(group, dev); > > > > - if (group->default_domain) { > > + /* > > + * If device joined an existing group which has been claimed > > + * for none kernel DMA purpose, avoid attaching the default > > + * domain. AOL: another "none kernel DMA purpose" that doesn't read well. Is this supposed to be "non-kernel"? What does "claimed for non-kernel DMA purpose" mean? What interface does that? > > + */ > > + if (group->default_domain && !group->owner) { > > ret = __iommu_attach_device(group->default_domain, dev); > > if (ret) { > > mutex_unlock(&group->mutex); > > @@ -2320,7 +2327,7 @@ static int __iommu_attach_group(struct iommu_domain *domain, > > { > > int ret; > > > > - if (group->default_domain && group->domain != group->default_domain) > > + if (group->domain && group->domain != group->default_domain) > > return -EBUSY; > > > > ret = __iommu_group_for_each_dev(group, domain, > > @@ -2357,7 +2364,11 @@ static void __iommu_detach_group(struct iommu_domain *domain, > > { > > int ret; > > > > - if (!group->default_domain) { > > + /* > > + * If group has been claimed for none kernel DMA purpose, avoid > > + * re-attaching the default domain. > > + */ > > none kernel reads odd. But maybe drop that and just say 'claimed > already' ala: > > /* > * If the group has been claimed already, do not re-attach the default > * domain. > */
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org> To: Christoph Hellwig <hch@infradead.org> Cc: Stuart Yoder <stuyoder@gmail.com>, rafael@kernel.org, David Airlie <airlied@linux.ie>, linux-pci@vger.kernel.org, Thierry Reding <thierry.reding@gmail.com>, Diana Craciun <diana.craciun@oss.nxp.com>, Dmitry Osipenko <digetx@gmail.com>, Will Deacon <will@kernel.org>, Ashok Raj <ashok.raj@intel.com>, Jonathan Hunter <jonathanh@nvidia.com>, Jason Gunthorpe <jgg@nvidia.com>, Kevin Tian <kevin.tian@intel.com>, Chaitanya Kulkarni <kch@nvidia.com>, Alex Williamson <alex.williamson@redhat.com>, kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>, Dan Williams <dan.j.williams@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Cornelia Huck <cohuck@redhat.com>, linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>, iommu@lists.linux-foundation.org, Jacob jun Pan <jacob.jun.pan@intel.com>, Daniel Vetter <daniel@ffwll.ch>, Robin Murphy <robin.murphy@arm.com> Subject: Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces Date: Tue, 4 Jan 2022 10:41:00 -0600 [thread overview] Message-ID: <20220104164100.GA101735@bhelgaas> (raw) In-Reply-To: <YdQcgFhIMYvUwABV@infradead.org> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote: > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote: > > Multiple devices may be placed in the same IOMMU group because they > > cannot be isolated from each other. These devices must either be > > entirely under kernel control or userspace control, never a mixture. I guess the reason is that if a group contained a mixture, userspace could attack the kernel by programming a device to DMA to a device owned by the kernel? > > This adds dma ownership management in iommu core and exposes several > > interfaces for the device drivers and the device userspace assignment > > framework (i.e. vfio), so that any conflict between user and kernel > > controlled DMA could be detected at the beginning. Maybe I'm missing the point because I don't know what "conflict between user and kernel controlled DMA" is. Are you talking about both userspace and the kernel programming the same device to do DMA? > > The device driver oriented interfaces are, > > > > int iommu_device_use_dma_api(struct device *dev); > > void iommu_device_unuse_dma_api(struct device *dev); Nit, do we care whether it uses the actual DMA API? Or is it just that iommu_device_use_dma_api() tells us the driver may program the device to do DMA? > > Devices under kernel drivers control must call iommu_device_use_dma_api() > > before driver probes. The driver binding process must be aborted if it > > returns failure. "Devices" don't call functions. Drivers do, or in this case, it looks like the bus DMA code (platform, amba, fsl, pci, etc). These functions are EXPORT_SYMBOL_GPL(), but it looks like all the callers are built-in, so maybe the export is unnecessary? You use "iommu"/"IOMMU" and "dma"/"DMA" interchangeably above. Would be easier to read if you picked one. > > The vfio oriented interfaces are, > > > > int iommu_group_set_dma_owner(struct iommu_group *group, > > void *owner); > > void iommu_group_release_dma_owner(struct iommu_group *group); > > bool iommu_group_dma_owner_claimed(struct iommu_group *group); > > > > The device userspace assignment must be disallowed if the set dma owner > > interface returns failure. Can you connect this back to the "never a mixture" from the beginning? If all you cared about was prevent an IOMMU group from containing devices with a mixture of kernel drivers and userspace drivers, I assume you could do that without iommu_device_use_dma_api(). So is this a way to *allow* a mixture under certain restricted conditions? Another nit below. > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > > Signed-off-by: Kevin Tian <kevin.tian@intel.com> > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > > --- > > include/linux/iommu.h | 31 ++++++++ > > drivers/iommu/iommu.c | 161 +++++++++++++++++++++++++++++++++++++++++- > > 2 files changed, 189 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > > index de0c57a567c8..568f285468cf 100644 > > --- a/include/linux/iommu.h > > +++ b/include/linux/iommu.h > > @@ -682,6 +682,13 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, > > void iommu_sva_unbind_device(struct iommu_sva *handle); > > u32 iommu_sva_get_pasid(struct iommu_sva *handle); > > > > +int iommu_device_use_dma_api(struct device *dev); > > +void iommu_device_unuse_dma_api(struct device *dev); > > + > > +int iommu_group_set_dma_owner(struct iommu_group *group, void *owner); > > +void iommu_group_release_dma_owner(struct iommu_group *group); > > +bool iommu_group_dma_owner_claimed(struct iommu_group *group); > > + > > #else /* CONFIG_IOMMU_API */ > > > > struct iommu_ops {}; > > @@ -1082,6 +1089,30 @@ static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev) > > { > > return NULL; > > } > > + > > +static inline int iommu_device_use_dma_api(struct device *dev) > > +{ > > + return 0; > > +} > > + > > +static inline void iommu_device_unuse_dma_api(struct device *dev) > > +{ > > +} > > + > > +static inline int > > +iommu_group_set_dma_owner(struct iommu_group *group, void *owner) > > +{ > > + return -ENODEV; > > +} > > + > > +static inline void iommu_group_release_dma_owner(struct iommu_group *group) > > +{ > > +} > > + > > +static inline bool iommu_group_dma_owner_claimed(struct iommu_group *group) > > +{ > > + return false; > > +} > > #endif /* CONFIG_IOMMU_API */ > > > > /** > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > index 8b86406b7162..ff0c8c1ad5af 100644 > > --- a/drivers/iommu/iommu.c > > +++ b/drivers/iommu/iommu.c > > @@ -48,6 +48,8 @@ struct iommu_group { > > struct iommu_domain *default_domain; > > struct iommu_domain *domain; > > struct list_head entry; > > + unsigned int owner_cnt; > > + void *owner; > > }; > > > > struct group_device { > > @@ -289,7 +291,12 @@ int iommu_probe_device(struct device *dev) > > mutex_lock(&group->mutex); > > iommu_alloc_default_domain(group, dev); > > > > - if (group->default_domain) { > > + /* > > + * If device joined an existing group which has been claimed > > + * for none kernel DMA purpose, avoid attaching the default > > + * domain. AOL: another "none kernel DMA purpose" that doesn't read well. Is this supposed to be "non-kernel"? What does "claimed for non-kernel DMA purpose" mean? What interface does that? > > + */ > > + if (group->default_domain && !group->owner) { > > ret = __iommu_attach_device(group->default_domain, dev); > > if (ret) { > > mutex_unlock(&group->mutex); > > @@ -2320,7 +2327,7 @@ static int __iommu_attach_group(struct iommu_domain *domain, > > { > > int ret; > > > > - if (group->default_domain && group->domain != group->default_domain) > > + if (group->domain && group->domain != group->default_domain) > > return -EBUSY; > > > > ret = __iommu_group_for_each_dev(group, domain, > > @@ -2357,7 +2364,11 @@ static void __iommu_detach_group(struct iommu_domain *domain, > > { > > int ret; > > > > - if (!group->default_domain) { > > + /* > > + * If group has been claimed for none kernel DMA purpose, avoid > > + * re-attaching the default domain. > > + */ > > none kernel reads odd. But maybe drop that and just say 'claimed > already' ala: > > /* > * If the group has been claimed already, do not re-attach the default > * domain. > */ _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-01-04 16:41 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-04 1:56 [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 01/14] iommu: Add dma ownership management interfaces Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 10:08 ` Christoph Hellwig 2022-01-04 10:08 ` Christoph Hellwig 2022-01-04 16:41 ` Bjorn Helgaas [this message] 2022-01-04 16:41 ` Bjorn Helgaas 2022-01-04 19:23 ` Jason Gunthorpe 2022-01-04 19:23 ` Jason Gunthorpe via iommu 2022-01-06 3:18 ` Lu Baolu 2022-01-06 3:18 ` Lu Baolu 2022-01-06 3:54 ` Lu Baolu 2022-01-06 3:54 ` Lu Baolu 2022-01-06 15:46 ` Jason Gunthorpe 2022-01-06 15:46 ` Jason Gunthorpe via iommu 2022-01-07 1:50 ` Lu Baolu 2022-01-07 1:50 ` Lu Baolu 2022-01-06 3:43 ` Lu Baolu 2022-01-06 3:43 ` Lu Baolu 2022-01-06 3:47 ` Lu Baolu 2022-01-06 3:47 ` Lu Baolu 2022-01-06 3:51 ` Lu Baolu 2022-01-06 3:51 ` Lu Baolu 2022-01-05 6:57 ` Lu Baolu 2022-01-05 6:57 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 02/14] driver core: Add dma_cleanup callback in bus_type Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 10:08 ` Christoph Hellwig 2022-01-04 10:08 ` Christoph Hellwig 2022-01-04 12:39 ` Jason Gunthorpe 2022-01-04 12:39 ` Jason Gunthorpe via iommu 2022-01-04 13:04 ` Greg Kroah-Hartman 2022-01-04 13:04 ` Greg Kroah-Hartman 2022-02-08 5:55 ` Lu Baolu 2022-02-08 5:55 ` Lu Baolu 2022-02-08 11:35 ` Greg Kroah-Hartman 2022-02-08 11:35 ` Greg Kroah-Hartman 2022-02-14 10:01 ` Greg Kroah-Hartman 2022-02-14 10:01 ` Greg Kroah-Hartman 2022-02-14 10:02 ` Greg Kroah-Hartman 2022-02-14 10:02 ` Greg Kroah-Hartman 2022-01-04 1:56 ` [PATCH v5 03/14] amba: Stop sharing platform_dma_configure() Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 04/14] driver core: platform: Add driver dma ownership management Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-02-14 9:59 ` Greg Kroah-Hartman 2022-02-14 9:59 ` Greg Kroah-Hartman 2022-02-14 13:18 ` Jason Gunthorpe 2022-02-14 13:18 ` Jason Gunthorpe via iommu 2022-02-14 13:37 ` Greg Kroah-Hartman 2022-02-14 13:37 ` Greg Kroah-Hartman 2022-02-14 13:43 ` Jason Gunthorpe 2022-02-14 13:43 ` Jason Gunthorpe via iommu 2022-01-04 1:56 ` [PATCH v5 05/14] amba: " Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 06/14] bus: fsl-mc: " Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 07/14] PCI: " Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-02-14 10:03 ` Greg Kroah-Hartman 2022-02-14 10:03 ` Greg Kroah-Hartman 2022-02-14 12:38 ` Jason Gunthorpe 2022-02-14 12:38 ` Jason Gunthorpe via iommu 2022-02-14 12:51 ` Greg Kroah-Hartman 2022-02-14 12:51 ` Greg Kroah-Hartman 2022-02-14 13:11 ` Jason Gunthorpe 2022-02-14 13:11 ` Jason Gunthorpe via iommu 2022-02-14 13:39 ` Greg Kroah-Hartman 2022-02-14 13:39 ` Greg Kroah-Hartman 2022-02-14 13:43 ` Jason Gunthorpe 2022-02-14 13:43 ` Jason Gunthorpe via iommu 2022-02-15 3:06 ` Lu Baolu 2022-02-15 3:06 ` Lu Baolu 2022-02-23 18:00 ` Bjorn Helgaas 2022-02-23 18:00 ` Bjorn Helgaas 2022-02-23 18:07 ` Jason Gunthorpe 2022-02-23 18:07 ` Jason Gunthorpe via iommu 2022-01-04 1:56 ` [PATCH v5 08/14] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 09/14] PCI: portdrv: " Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 17:06 ` Bjorn Helgaas 2022-01-04 17:06 ` Bjorn Helgaas 2022-01-04 19:26 ` Jason Gunthorpe 2022-01-04 19:26 ` Jason Gunthorpe via iommu 2022-01-04 19:51 ` Bjorn Helgaas 2022-01-04 19:51 ` Bjorn Helgaas 2022-01-05 0:35 ` Jason Gunthorpe 2022-01-05 0:35 ` Jason Gunthorpe via iommu 2022-01-06 4:12 ` Lu Baolu 2022-01-06 4:12 ` Lu Baolu 2022-01-06 18:32 ` Bjorn Helgaas 2022-01-06 18:32 ` Bjorn Helgaas 2022-01-07 1:53 ` Lu Baolu 2022-01-07 1:53 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 10/14] vfio: Set DMA ownership for VFIO devices Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 11/14] vfio: Remove use of vfio_group_viable() Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 12/14] vfio: Delete the unbound_list Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 13/14] vfio: Remove iommu group notifier Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 1:56 ` [PATCH v5 14/14] iommu: Remove iommu group changes notifier Lu Baolu 2022-01-04 1:56 ` Lu Baolu 2022-01-04 12:48 ` [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Jason Gunthorpe 2022-01-04 12:48 ` Jason Gunthorpe via iommu 2022-01-05 6:52 ` Lu Baolu 2022-01-05 6:52 ` Lu Baolu 2022-02-18 1:07 ` Lu Baolu 2022-02-18 1:07 ` 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=20220104164100.GA101735@bhelgaas \ --to=helgaas@kernel.org \ --cc=airlied@linux.ie \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=bhelgaas@google.com \ --cc=cohuck@redhat.com \ --cc=dan.j.williams@intel.com \ --cc=daniel@ffwll.ch \ --cc=diana.craciun@oss.nxp.com \ --cc=digetx@gmail.com \ --cc=eric.auger@redhat.com \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@intel.com \ --cc=jgg@nvidia.com \ --cc=jonathanh@nvidia.com \ --cc=joro@8bytes.org \ --cc=kch@nvidia.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=laurentiu.tudor@nxp.com \ --cc=leoyang.li@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=rafael@kernel.org \ --cc=robin.murphy@arm.com \ --cc=stuyoder@gmail.com \ --cc=thierry.reding@gmail.com \ --cc=will@kernel.org \ --cc=yi.l.liu@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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.