All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	"Tian,  Kevin" <kevin.tian@intel.com>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"Xu, Terrence" <terrence.xu@intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"joro@8bytes.org" <joro@8bytes.org>
Subject: Re: [Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()
Date: Wed, 15 Mar 2023 02:03:09 -0700	[thread overview]
Message-ID: <ZBGJzefTm4p/ReIu@Asurada-Nvidia> (raw)
In-Reply-To: <BN9PR11MB52765D7977F987960072482E8CBF9@BN9PR11MB5276.namprd11.prod.outlook.com>

Hi,

On Wed, Mar 15, 2023 at 06:50:53AM +0000, Tian, Kevin wrote:

> > So, this preparatory series will add a pair of simple attach()
> > and detach() APIs. Then the cdev series will add the locking
> > and the ioas_unpin stuff as a rework of the detach() API.

> > I think they can be something mingled... the sample code that
> > I sent previously could take care of those conditions. But, I
> > am also thinking a bit that maybe attach() does not need the
> > locking? I can do a separate replace() function in this case.
> >
> 
> w/o locking then you need smp_store_release() and its pair.
> 
> anyway it's not in perf critical path. Keeping lock for attach
> is simpler and safe.

OK. Basically I followed what Jason suggested by having three
APIs and combined Kevin's inputs about the difference between
the attach/replace(). I also updated the replace changes, and
rebased all nesting (infrastructure, VT-d and SMMU):
https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03142023

The major three changes for those APIs:
[1] This adds iommufd_access_attach() in this series:
    "iommufd: Create access in vfio_iommufd_emulated_bind()"
    https://github.com/nicolinc/iommufd/commit/34fba7509429380f828fb23dcca5ceaeb40e22b5
[2] This adds iommufd_access_detach() in the cdev series:
    "iommufd/device: Add iommufd_access_detach() API"
    https://github.com/nicolinc/iommufd/commit/4110522146ca1fc0d5321c04a097e2c9d9e26af4
[3] This adds iommufd_access_replace() in the replace series:
    "iommufd: Add iommufd_access_replace() API"
    https://github.com/nicolinc/iommufd/commit/36507fa9f0f42cf1a5bebe7c9bc2bf319b7654a8

Please check if they look okay, so that Yi can integrate them
accordingly to the emulated/cdev series.

[*] This is the patch that I posted in the other mail addressing
    Kevin's comments on iommufd_ctx_get():
    "iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()"
    https://github.com/nicolinc/iommufd/commit/077b09bb83329dc046753f4ef672f5bf6386755c
    (I just saw Yi's reply concerning its necessity. Feel free
     to drop in that case.)

Thanks
Nicolin

P.S. Attaching the list of changes with their locations:
3791dedf98e8 cover-letter: Add IO page table replacement support
c8ebf51c3c9b vfio: Support IO page table replacement
c5710f23e8f6 iommufd/selftest: Add IOMMU_TEST_OP_ACCESS_REPLACE_IOAS coverage
[3] 36507fa9f0f4 iommufd: Add iommufd_access_replace() API
0263855d1e8b vfio: Do not allow !ops->dma_unmap in vfio_pin/unpin_pages()
e39ed55e77a0 cover-letter: Add vfio_device cdev for iommufd support
26fd7fccaef3 docs: vfio: Add vfio device cdev description
f10f3e3162bb vfio: Compile group optionally
9588ae4c4049 vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
3e57108eac64 vfio: Add VFIO_DEVICE_BIND_IOMMUFD
b925716dd226 vfio: Add cdev for vfio_device
db309463ab92 vfio-iommufd: Add detach_ioas support for emulated VFIO devices
[2] 4110522146ca iommufd/device: Add iommufd_access_detach() API
abca7e1e063a vfio-iommufd: Add detach_ioas support for physical VFIO devices
9d368f7247c7 vfio: Record devid in vfio_device_file
683af0a471e1 vfio-iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()
32a2e7de1d53 vfio-iommufd: Split the no-iommu support out from vfio_iommufd_bind()
8a1c042379f5 vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu
fc6e0ed2aa44 vfio: Make vfio_device_open() single open for device cdev path
3f6821d507a4 vfio: Add cdev_device_open_cnt to vfio_group
896cde40a016 vfio: Block device access via device fd until device is opened
f422c4216a19 vfio: Pass struct vfio_device_file * to vfio_device_open/close()
b187f9980fed kvm/vfio: Accept vfio device file from userspace
721e2e60ff54 kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd
8993c4c75c20 vfio: Accept vfio device file in the KVM facing kAPI
a92c45ae0ce6 vfio: Remove vfio_file_is_group()
fb586f783934 vfio: Refine vfio file kAPIs for KVM
50694af6f3c0 vfio: Allocate per device file structure
df21c0737eef cover-letter: Make vfio-pci hot reset prepared for vfio device cdev
5c25c874d7e0 vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
7c30ce8b54db vfio: Accpet device file from vfio PCI hot reset path
e3209342db44 vfio: Refine vfio file kAPIs for vfio PCI hot reset
8354fd79944e vfio/pci: Rename the helpers and data in hot reset path to accept device fd
54387efb858c vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
cd93ffb62c51 vfio/pci: Only need to check opened devices in the dev_set for hot reset
2a6fd7231cbf vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()
480abea5961e cover-letter: vfio: Make emulated devices prepared for vfio device cdev
46b6d1ae1754 vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
6064b9f81817 Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers
c20852af7291 vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID
3405865b0b3f vfio-iommufd: No need to record iommufd_ctx in vfio_device
[*] 077b09bb8332 iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()
[1] 34fba7509429 iommufd: Create access in vfio_iommufd_emulated_bind()
a5d8ac47554f docs: kvm: vfio: Require call KVM_DEV_VFIO_GROUP_ADD before VFIO_GROUP_GET_DEVICE_FD

WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicolinc@nvidia.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Cc: "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"Xu, Terrence" <terrence.xu@intel.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()
Date: Wed, 15 Mar 2023 02:03:09 -0700	[thread overview]
Message-ID: <ZBGJzefTm4p/ReIu@Asurada-Nvidia> (raw)
In-Reply-To: <BN9PR11MB52765D7977F987960072482E8CBF9@BN9PR11MB5276.namprd11.prod.outlook.com>

Hi,

On Wed, Mar 15, 2023 at 06:50:53AM +0000, Tian, Kevin wrote:

> > So, this preparatory series will add a pair of simple attach()
> > and detach() APIs. Then the cdev series will add the locking
> > and the ioas_unpin stuff as a rework of the detach() API.

> > I think they can be something mingled... the sample code that
> > I sent previously could take care of those conditions. But, I
> > am also thinking a bit that maybe attach() does not need the
> > locking? I can do a separate replace() function in this case.
> >
> 
> w/o locking then you need smp_store_release() and its pair.
> 
> anyway it's not in perf critical path. Keeping lock for attach
> is simpler and safe.

OK. Basically I followed what Jason suggested by having three
APIs and combined Kevin's inputs about the difference between
the attach/replace(). I also updated the replace changes, and
rebased all nesting (infrastructure, VT-d and SMMU):
https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03142023

The major three changes for those APIs:
[1] This adds iommufd_access_attach() in this series:
    "iommufd: Create access in vfio_iommufd_emulated_bind()"
    https://github.com/nicolinc/iommufd/commit/34fba7509429380f828fb23dcca5ceaeb40e22b5
[2] This adds iommufd_access_detach() in the cdev series:
    "iommufd/device: Add iommufd_access_detach() API"
    https://github.com/nicolinc/iommufd/commit/4110522146ca1fc0d5321c04a097e2c9d9e26af4
[3] This adds iommufd_access_replace() in the replace series:
    "iommufd: Add iommufd_access_replace() API"
    https://github.com/nicolinc/iommufd/commit/36507fa9f0f42cf1a5bebe7c9bc2bf319b7654a8

Please check if they look okay, so that Yi can integrate them
accordingly to the emulated/cdev series.

[*] This is the patch that I posted in the other mail addressing
    Kevin's comments on iommufd_ctx_get():
    "iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()"
    https://github.com/nicolinc/iommufd/commit/077b09bb83329dc046753f4ef672f5bf6386755c
    (I just saw Yi's reply concerning its necessity. Feel free
     to drop in that case.)

Thanks
Nicolin

P.S. Attaching the list of changes with their locations:
3791dedf98e8 cover-letter: Add IO page table replacement support
c8ebf51c3c9b vfio: Support IO page table replacement
c5710f23e8f6 iommufd/selftest: Add IOMMU_TEST_OP_ACCESS_REPLACE_IOAS coverage
[3] 36507fa9f0f4 iommufd: Add iommufd_access_replace() API
0263855d1e8b vfio: Do not allow !ops->dma_unmap in vfio_pin/unpin_pages()
e39ed55e77a0 cover-letter: Add vfio_device cdev for iommufd support
26fd7fccaef3 docs: vfio: Add vfio device cdev description
f10f3e3162bb vfio: Compile group optionally
9588ae4c4049 vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
3e57108eac64 vfio: Add VFIO_DEVICE_BIND_IOMMUFD
b925716dd226 vfio: Add cdev for vfio_device
db309463ab92 vfio-iommufd: Add detach_ioas support for emulated VFIO devices
[2] 4110522146ca iommufd/device: Add iommufd_access_detach() API
abca7e1e063a vfio-iommufd: Add detach_ioas support for physical VFIO devices
9d368f7247c7 vfio: Record devid in vfio_device_file
683af0a471e1 vfio-iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()
32a2e7de1d53 vfio-iommufd: Split the no-iommu support out from vfio_iommufd_bind()
8a1c042379f5 vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu
fc6e0ed2aa44 vfio: Make vfio_device_open() single open for device cdev path
3f6821d507a4 vfio: Add cdev_device_open_cnt to vfio_group
896cde40a016 vfio: Block device access via device fd until device is opened
f422c4216a19 vfio: Pass struct vfio_device_file * to vfio_device_open/close()
b187f9980fed kvm/vfio: Accept vfio device file from userspace
721e2e60ff54 kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd
8993c4c75c20 vfio: Accept vfio device file in the KVM facing kAPI
a92c45ae0ce6 vfio: Remove vfio_file_is_group()
fb586f783934 vfio: Refine vfio file kAPIs for KVM
50694af6f3c0 vfio: Allocate per device file structure
df21c0737eef cover-letter: Make vfio-pci hot reset prepared for vfio device cdev
5c25c874d7e0 vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
7c30ce8b54db vfio: Accpet device file from vfio PCI hot reset path
e3209342db44 vfio: Refine vfio file kAPIs for vfio PCI hot reset
8354fd79944e vfio/pci: Rename the helpers and data in hot reset path to accept device fd
54387efb858c vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
cd93ffb62c51 vfio/pci: Only need to check opened devices in the dev_set for hot reset
2a6fd7231cbf vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()
480abea5961e cover-letter: vfio: Make emulated devices prepared for vfio device cdev
46b6d1ae1754 vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
6064b9f81817 Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers
c20852af7291 vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID
3405865b0b3f vfio-iommufd: No need to record iommufd_ctx in vfio_device
[*] 077b09bb8332 iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()
[1] 34fba7509429 iommufd: Create access in vfio_iommufd_emulated_bind()
a5d8ac47554f docs: kvm: vfio: Require call KVM_DEV_VFIO_GROUP_ADD before VFIO_GROUP_GET_DEVICE_FD

  reply	other threads:[~2023-03-15  9:03 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 13:13 [Intel-gfx] [PATCH v1 0/5] vfio: Make emulated devices prepared for vfio device cdev Yi Liu
2023-03-08 13:13 ` Yi Liu
2023-03-08 13:13 ` [Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind() Yi Liu
2023-03-08 13:13   ` Yi Liu
2023-03-10  2:08   ` [Intel-gfx] " Tian, Kevin
2023-03-10  2:08     ` Tian, Kevin
2023-03-14 18:50     ` [Intel-gfx] " Nicolin Chen
2023-03-14 18:50       ` Nicolin Chen
2023-03-15  6:16       ` [Intel-gfx] " Tian, Kevin
2023-03-15  6:16         ` Tian, Kevin
2023-03-15  6:21         ` [Intel-gfx] " Nicolin Chen
2023-03-15  6:21           ` Nicolin Chen
2023-03-15  6:52           ` [Intel-gfx] " Tian, Kevin
2023-03-15  6:52             ` Tian, Kevin
2023-03-15  8:52             ` [Intel-gfx] " Liu, Yi L
2023-03-15  8:52               ` Liu, Yi L
2023-03-16  0:17               ` [Intel-gfx] " Tian, Kevin
2023-03-16  0:17                 ` Tian, Kevin
2023-03-16  0:28                 ` [Intel-gfx] " Nicolin Chen
2023-03-16  0:28                   ` Nicolin Chen
2023-03-10 17:36   ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 17:36     ` Jason Gunthorpe
2023-03-14  8:20     ` [Intel-gfx] " Nicolin Chen
2023-03-14  8:20       ` Nicolin Chen
2023-03-15  1:01       ` [Intel-gfx] " Nicolin Chen
2023-03-15  1:01         ` Nicolin Chen
2023-03-15  6:15         ` [Intel-gfx] " Tian, Kevin
2023-03-15  6:15           ` Tian, Kevin
2023-03-15  6:32           ` [Intel-gfx] " Nicolin Chen
2023-03-15  6:32             ` Nicolin Chen
2023-03-15  6:50             ` [Intel-gfx] " Tian, Kevin
2023-03-15  6:50               ` Tian, Kevin
2023-03-15  9:03               ` Nicolin Chen [this message]
2023-03-15  9:03                 ` Nicolin Chen
2023-03-15 12:18                 ` [Intel-gfx] " Liu, Yi L
2023-03-15 12:18                   ` Liu, Yi L
2023-03-16  0:32                   ` [Intel-gfx] " Nicolin Chen
2023-03-16  0:32                     ` Nicolin Chen
2023-03-16  2:53                 ` [Intel-gfx] " Tian, Kevin
2023-03-16  2:53                   ` Tian, Kevin
2023-03-16  3:25                   ` [Intel-gfx] " Nicolin Chen
2023-03-16  3:25                     ` Nicolin Chen
2023-03-16  5:33                   ` [Intel-gfx] " Nicolin Chen
2023-03-16  5:33                     ` Nicolin Chen
2023-03-16  5:38                     ` [Intel-gfx] " Tian, Kevin
2023-03-16  5:38                       ` Tian, Kevin
2023-03-16  5:43                       ` [Intel-gfx] " Nicolin Chen
2023-03-16  5:43                         ` Nicolin Chen
2023-03-16  5:49                         ` [Intel-gfx] " Tian, Kevin
2023-03-16  5:49                           ` Tian, Kevin
2023-03-16  5:56                           ` [Intel-gfx] " Nicolin Chen
2023-03-16  5:56                             ` Nicolin Chen
2023-03-16  6:01                           ` [Intel-gfx] " Liu, Yi L
2023-03-16  6:01                             ` Liu, Yi L
2023-03-20 14:49                 ` [Intel-gfx] " Jason Gunthorpe
2023-03-20 14:49                   ` Jason Gunthorpe
2023-03-20 15:11                   ` [Intel-gfx] " Yi Liu
2023-03-20 15:11                     ` Yi Liu
2023-03-20 15:33                     ` [Intel-gfx] " Jason Gunthorpe
2023-03-20 15:33                       ` Jason Gunthorpe
2023-03-08 13:13 ` [Intel-gfx] [PATCH v1 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device Yi Liu
2023-03-08 13:13   ` Yi Liu
2023-03-10 17:37   ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 17:37     ` Jason Gunthorpe
2023-03-08 13:13 ` [Intel-gfx] [PATCH v1 3/5] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID Yi Liu
2023-03-08 13:13   ` Yi Liu
2023-03-10  2:08   ` [Intel-gfx] " Tian, Kevin
2023-03-10  2:08     ` Tian, Kevin
2023-03-10 17:37   ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 17:37     ` Jason Gunthorpe
2023-03-08 13:13 ` [Intel-gfx] [PATCH v1 4/5] Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers Yi Liu
2023-03-08 13:13   ` Yi Liu
2023-03-10  2:10   ` [Intel-gfx] " Tian, Kevin
2023-03-10  2:10     ` Tian, Kevin
2023-03-10 17:39   ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 17:39     ` Jason Gunthorpe
2023-03-08 13:13 ` [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev() Yi Liu
2023-03-08 13:13   ` Yi Liu
2023-03-10  2:15   ` [Intel-gfx] " Tian, Kevin
2023-03-10  2:15     ` Tian, Kevin
2023-03-10 14:04     ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 14:04       ` Jason Gunthorpe
2023-03-10 14:12       ` [Intel-gfx] " Liu, Yi L
2023-03-10 14:12         ` Liu, Yi L
2023-03-10 15:25         ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 15:25           ` Jason Gunthorpe
2023-03-13  1:49       ` [Intel-gfx] " Tian, Kevin
2023-03-13  1:49         ` Tian, Kevin
2023-03-10 17:39   ` [Intel-gfx] " Jason Gunthorpe
2023-03-10 17:39     ` Jason Gunthorpe
2023-03-15 12:15     ` [Intel-gfx] " Liu, Yi L
2023-03-15 12:15       ` Liu, Yi L
2023-03-08 14:28 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for vfio: Make emulated devices prepared for vfio device cdev Patchwork
2023-03-08 14:54 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-03-15  6:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for vfio: Make emulated devices prepared for vfio device cdev (rev2) Patchwork

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=ZBGJzefTm4p/ReIu@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=terrence.xu@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.