From: Yan Zhao <yan.y.zhao@intel.com> To: Sean Mooney <smooney@redhat.com> Cc: "Cornelia Huck" <cohuck@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>, kvm@vger.kernel.org, libvir-list@redhat.com, "Jason Wang" <jasowang@redhat.com>, qemu-devel@nongnu.org, kwankhede@nvidia.com, eauger@redhat.com, xin-ran.wang@intel.com, corbet@lwn.net, openstack-discuss@lists.openstack.org, shaohe.feng@intel.com, kevin.tian@intel.com, "Parav Pandit" <parav@mellanox.com>, jian-feng.ding@intel.com, dgilbert@redhat.com, zhenyuw@linux.intel.com, hejie.xu@intel.com, bao.yumeng@zte.com.cn, "Alex Williamson" <alex.williamson@redhat.com>, intel-gvt-dev@lists.freedesktop.org, eskultet@redhat.com, "Jiri Pirko" <jiri@mellanox.com>, dinechin@redhat.com, devel@ovirt.org Subject: Re: device compatibility interface for live migration with assigned devices Date: Thu, 20 Aug 2020 12:01:16 +0800 [thread overview] Message-ID: <20200820040116.GB24121@joy-OptiPlex-7040> (raw) In-Reply-To: <242591bb809b68c618f62fdc93d4f8ae7b146b6d.camel@redhat.com> On Thu, Aug 20, 2020 at 02:29:07AM +0100, Sean Mooney wrote: > On Thu, 2020-08-20 at 08:39 +0800, Yan Zhao wrote: > > On Tue, Aug 18, 2020 at 11:36:52AM +0200, Cornelia Huck wrote: > > > On Tue, 18 Aug 2020 10:16:28 +0100 > > > Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > > > > On Tue, Aug 18, 2020 at 05:01:51PM +0800, Jason Wang wrote: > > > > > On 2020/8/18 下午4:55, Daniel P. Berrangé wrote: > > > > > > > > > > On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote: > > > > > > > > > > On 2020/8/14 下午1:16, Yan Zhao wrote: > > > > > > > > > > On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote: > > > > > > > > > > On 2020/8/10 下午3:46, Yan Zhao wrote: > > > > > we actually can also retrieve the same information through sysfs, .e.g > > > > > > > > > > |- [path to device] > > > > > |--- migration > > > > > | |--- self > > > > > | | |---device_api > > > > > | | |---mdev_type > > > > > | | |---software_version > > > > > | | |---device_id > > > > > | | |---aggregator > > > > > | |--- compatible > > > > > | | |---device_api > > > > > | | |---mdev_type > > > > > | | |---software_version > > > > > | | |---device_id > > > > > | | |---aggregator > > > > > > > > > > > > > > > Yes but: > > > > > > > > > > - You need one file per attribute (one syscall for one attribute) > > > > > - Attribute is coupled with kobject > > > > > > Is that really that bad? You have the device with an embedded kobject > > > anyway, and you can just put things into an attribute group? > > > > > > [Also, I think that self/compatible split in the example makes things > > > needlessly complex. Shouldn't semantic versioning and matching already > > > cover nearly everything? I would expect very few cases that are more > > > complex than that. Maybe the aggregation stuff, but I don't think we > > > need that self/compatible split for that, either.] > > > > Hi Cornelia, > > > > The reason I want to declare compatible list of attributes is that > > sometimes it's not a simple 1:1 matching of source attributes and target attributes > > as I demonstrated below, > > source mdev of (mdev_type i915-GVTg_V5_2 + aggregator 1) is compatible to > > target mdev of (mdev_type i915-GVTg_V5_4 + aggregator 2), > > (mdev_type i915-GVTg_V5_8 + aggregator 4) > the way you are doing the nameing is till really confusing by the way > if this has not already been merged in the kernel can you chagne the mdev > so that mdev_type i915-GVTg_V5_2 is 2 of mdev_type i915-GVTg_V5_1 instead of half the device > > currently you need to deived the aggratod by the number at the end of the mdev type to figure out > how much of the phsicial device is being used with is a very unfridly api convention > > the way aggrator are being proposed in general is not really someting i like but i thin this at least > is something that should be able to correct. > > with the complexity in the mdev type name + aggrator i suspect that this will never be support > in openstack nova directly requireing integration via cyborg unless we can pre partion the > device in to mdevs staicaly and just ignore this. > > this is way to vendor sepecif to integrate into something like openstack in nova unless we can guarentee > taht how aggreator work will be portable across vendors genericly. > > > > > and aggragator may be just one of such examples that 1:1 matching does not > > fit. > for openstack nova i dont see us support anything beyond the 1:1 case where the mdev type does not change. > hi Sean, I understand it's hard for openstack. but 1:N is always meaningful. e.g. if source device 1 has cap A, it is compatible to device 2: cap A, device 3: cap A+B, device 4: cap A+B+C .... to allow openstack to detect it correctly, in compatible list of device 2, we would say compatible cap is A; device 3, compatible cap is A or A+B; device 4, compatible cap is A or A+B, or A+B+C; then if openstack finds device A's self cap A is contained in compatible cap of device 2/3/4, it can migrate device 1 to device 2,3,4. conversely, device 1's compatible cap is only A, so it is able to migrate device 2 to device 1, and it is not able to migrate device 3/4 to device 1. Thanks Yan > i woudl really prefer if there was just one mdev type that repsented the minimal allcatable unit and the > aggragaotr where used to create compostions of that. i.e instad of i915-GVTg_V5_2 beign half the device, > have 1 mdev type i915-GVTg and if the device support 8 of them then we can aggrate 4 of i915-GVTg > > if you want to have muplie mdev type to model the different amoutn of the resouce e.g. i915-GVTg_small i915-GVTg_large > that is totlaly fine too or even i915-GVTg_4 indcating it sis 4 of i915-GVTg > > failing that i would just expose an mdev type per composable resouce and allow us to compose them a the user level with > some other construct mudeling a attament to the device. e.g. create composed mdev or somethig that is an aggreateion of > multiple sub resouces each of which is an mdev. so kind of like how bond port work. we would create an mdev for each of > the sub resouces and then create a bond or aggrated mdev by reference the other mdevs by uuid then attach only the > aggreated mdev to the instance. > > the current aggrator syntax and sematic however make me rather uncofrotable when i think about orchestating vms on top > of it even to boot them let alone migrate them. > > > > So, we explicitly list out self/compatible attributes, and management > > tools only need to check if self attributes is contained compatible > > attributes. > > > > or do you mean only compatible list is enough, and the management tools > > need to find out self list by themselves? > > But I think provide a self list is easier for management tools. > > > > Thanks > > Yan > > >
WARNING: multiple messages have this Message-ID (diff)
From: Yan Zhao <yan.y.zhao@intel.com> To: Sean Mooney <smooney@redhat.com> Cc: kvm@vger.kernel.org, libvir-list@redhat.com, "Jason Wang" <jasowang@redhat.com>, qemu-devel@nongnu.org, kwankhede@nvidia.com, eauger@redhat.com, xin-ran.wang@intel.com, corbet@lwn.net, openstack-discuss@lists.openstack.org, shaohe.feng@intel.com, kevin.tian@intel.com, "Parav Pandit" <parav@mellanox.com>, jian-feng.ding@intel.com, dgilbert@redhat.com, zhenyuw@linux.intel.com, hejie.xu@intel.com, bao.yumeng@zte.com.cn, "Alex Williamson" <alex.williamson@redhat.com>, eskultet@redhat.com, intel-gvt-dev@lists.freedesktop.org, "Daniel P. Berrangé" <berrange@redhat.com>, "Cornelia Huck" <cohuck@redhat.com>, "Jiri Pirko" <jiri@mellanox.com>, dinechin@redhat.com, devel@ovirt.org Subject: Re: device compatibility interface for live migration with assigned devices Date: Thu, 20 Aug 2020 12:01:16 +0800 [thread overview] Message-ID: <20200820040116.GB24121@joy-OptiPlex-7040> (raw) In-Reply-To: <242591bb809b68c618f62fdc93d4f8ae7b146b6d.camel@redhat.com> On Thu, Aug 20, 2020 at 02:29:07AM +0100, Sean Mooney wrote: > On Thu, 2020-08-20 at 08:39 +0800, Yan Zhao wrote: > > On Tue, Aug 18, 2020 at 11:36:52AM +0200, Cornelia Huck wrote: > > > On Tue, 18 Aug 2020 10:16:28 +0100 > > > Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > > > > On Tue, Aug 18, 2020 at 05:01:51PM +0800, Jason Wang wrote: > > > > > On 2020/8/18 下午4:55, Daniel P. Berrangé wrote: > > > > > > > > > > On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote: > > > > > > > > > > On 2020/8/14 下午1:16, Yan Zhao wrote: > > > > > > > > > > On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote: > > > > > > > > > > On 2020/8/10 下午3:46, Yan Zhao wrote: > > > > > we actually can also retrieve the same information through sysfs, .e.g > > > > > > > > > > |- [path to device] > > > > > |--- migration > > > > > | |--- self > > > > > | | |---device_api > > > > > | | |---mdev_type > > > > > | | |---software_version > > > > > | | |---device_id > > > > > | | |---aggregator > > > > > | |--- compatible > > > > > | | |---device_api > > > > > | | |---mdev_type > > > > > | | |---software_version > > > > > | | |---device_id > > > > > | | |---aggregator > > > > > > > > > > > > > > > Yes but: > > > > > > > > > > - You need one file per attribute (one syscall for one attribute) > > > > > - Attribute is coupled with kobject > > > > > > Is that really that bad? You have the device with an embedded kobject > > > anyway, and you can just put things into an attribute group? > > > > > > [Also, I think that self/compatible split in the example makes things > > > needlessly complex. Shouldn't semantic versioning and matching already > > > cover nearly everything? I would expect very few cases that are more > > > complex than that. Maybe the aggregation stuff, but I don't think we > > > need that self/compatible split for that, either.] > > > > Hi Cornelia, > > > > The reason I want to declare compatible list of attributes is that > > sometimes it's not a simple 1:1 matching of source attributes and target attributes > > as I demonstrated below, > > source mdev of (mdev_type i915-GVTg_V5_2 + aggregator 1) is compatible to > > target mdev of (mdev_type i915-GVTg_V5_4 + aggregator 2), > > (mdev_type i915-GVTg_V5_8 + aggregator 4) > the way you are doing the nameing is till really confusing by the way > if this has not already been merged in the kernel can you chagne the mdev > so that mdev_type i915-GVTg_V5_2 is 2 of mdev_type i915-GVTg_V5_1 instead of half the device > > currently you need to deived the aggratod by the number at the end of the mdev type to figure out > how much of the phsicial device is being used with is a very unfridly api convention > > the way aggrator are being proposed in general is not really someting i like but i thin this at least > is something that should be able to correct. > > with the complexity in the mdev type name + aggrator i suspect that this will never be support > in openstack nova directly requireing integration via cyborg unless we can pre partion the > device in to mdevs staicaly and just ignore this. > > this is way to vendor sepecif to integrate into something like openstack in nova unless we can guarentee > taht how aggreator work will be portable across vendors genericly. > > > > > and aggragator may be just one of such examples that 1:1 matching does not > > fit. > for openstack nova i dont see us support anything beyond the 1:1 case where the mdev type does not change. > hi Sean, I understand it's hard for openstack. but 1:N is always meaningful. e.g. if source device 1 has cap A, it is compatible to device 2: cap A, device 3: cap A+B, device 4: cap A+B+C .... to allow openstack to detect it correctly, in compatible list of device 2, we would say compatible cap is A; device 3, compatible cap is A or A+B; device 4, compatible cap is A or A+B, or A+B+C; then if openstack finds device A's self cap A is contained in compatible cap of device 2/3/4, it can migrate device 1 to device 2,3,4. conversely, device 1's compatible cap is only A, so it is able to migrate device 2 to device 1, and it is not able to migrate device 3/4 to device 1. Thanks Yan > i woudl really prefer if there was just one mdev type that repsented the minimal allcatable unit and the > aggragaotr where used to create compostions of that. i.e instad of i915-GVTg_V5_2 beign half the device, > have 1 mdev type i915-GVTg and if the device support 8 of them then we can aggrate 4 of i915-GVTg > > if you want to have muplie mdev type to model the different amoutn of the resouce e.g. i915-GVTg_small i915-GVTg_large > that is totlaly fine too or even i915-GVTg_4 indcating it sis 4 of i915-GVTg > > failing that i would just expose an mdev type per composable resouce and allow us to compose them a the user level with > some other construct mudeling a attament to the device. e.g. create composed mdev or somethig that is an aggreateion of > multiple sub resouces each of which is an mdev. so kind of like how bond port work. we would create an mdev for each of > the sub resouces and then create a bond or aggrated mdev by reference the other mdevs by uuid then attach only the > aggreated mdev to the instance. > > the current aggrator syntax and sematic however make me rather uncofrotable when i think about orchestating vms on top > of it even to boot them let alone migrate them. > > > > So, we explicitly list out self/compatible attributes, and management > > tools only need to check if self attributes is contained compatible > > attributes. > > > > or do you mean only compatible list is enough, and the management tools > > need to find out self list by themselves? > > But I think provide a self list is easier for management tools. > > > > Thanks > > Yan > > >
next prev parent reply other threads:[~2020-08-20 4:17 UTC|newest] Thread overview: 227+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-13 23:29 device compatibility interface for live migration with assigned devices Yan Zhao 2020-07-13 23:29 ` Yan Zhao 2020-07-14 10:21 ` Daniel P. Berrangé 2020-07-14 10:21 ` Daniel P. Berrangé 2020-07-14 12:33 ` Sean Mooney 2020-07-14 12:33 ` Sean Mooney [not found] ` <20200714110148.0471c03c@x1.home> [not found] ` <eb705c72cdc8b6b8959b6ebaeeac6069a718d524.camel@redhat.com> 2020-07-14 21:15 ` Sean Mooney 2020-07-14 21:15 ` Sean Mooney 2020-07-14 16:16 ` Alex Williamson 2020-07-14 16:16 ` Alex Williamson 2020-07-14 16:47 ` Daniel P. Berrangé 2020-07-14 16:47 ` Daniel P. Berrangé 2020-07-14 20:47 ` Alex Williamson 2020-07-14 20:47 ` Alex Williamson 2020-07-15 9:16 ` Daniel P. Berrangé 2020-07-15 9:16 ` Daniel P. Berrangé 2020-07-14 17:19 ` Dr. David Alan Gilbert 2020-07-14 17:19 ` Dr. David Alan Gilbert 2020-07-14 20:59 ` Alex Williamson 2020-07-14 20:59 ` Alex Williamson 2020-07-15 7:37 ` Alex Xu 2020-07-17 15:18 ` Alex Williamson 2020-07-17 15:18 ` Alex Williamson 2020-07-15 8:20 ` Yan Zhao 2020-07-15 8:20 ` Yan Zhao 2020-07-15 8:49 ` Feng, Shaohe 2020-07-15 8:49 ` Feng, Shaohe 2020-07-15 9:21 ` Alex Xu 2020-07-17 14:59 ` Alex Williamson 2020-07-17 14:59 ` Alex Williamson 2020-07-17 18:03 ` Dr. David Alan Gilbert 2020-07-17 18:03 ` Dr. David Alan Gilbert 2020-07-17 18:30 ` Alex Williamson 2020-07-17 18:30 ` Alex Williamson 2020-07-15 8:23 ` Dr. David Alan Gilbert 2020-07-15 8:23 ` Dr. David Alan Gilbert 2020-07-15 7:23 ` Alex Xu 2020-07-16 4:16 ` Jason Wang 2020-07-16 4:16 ` Jason Wang 2020-07-16 8:32 ` Yan Zhao 2020-07-16 8:32 ` Yan Zhao 2020-07-16 9:30 ` Jason Wang 2020-07-17 16:12 ` Alex Williamson 2020-07-17 16:12 ` Alex Williamson 2020-07-20 3:41 ` Jason Wang 2020-07-20 3:41 ` Jason Wang 2020-07-20 10:39 ` Sean Mooney 2020-07-20 10:39 ` Sean Mooney 2020-07-21 2:11 ` Jason Wang 2020-07-21 2:11 ` Jason Wang 2020-07-21 0:51 ` Yan Zhao 2020-07-21 0:51 ` Yan Zhao 2020-07-27 7:24 ` Yan Zhao 2020-07-27 22:23 ` Alex Williamson 2020-07-29 8:05 ` Yan Zhao 2020-07-29 11:28 ` Sean Mooney 2020-07-29 11:28 ` Sean Mooney 2020-07-29 19:12 ` Alex Williamson 2020-07-29 19:12 ` Alex Williamson 2020-07-30 3:41 ` Yan Zhao 2020-07-30 3:41 ` Yan Zhao 2020-07-30 13:24 ` Sean Mooney 2020-07-30 13:24 ` Sean Mooney 2020-07-30 17:29 ` Alex Williamson 2020-07-30 17:29 ` Alex Williamson 2020-08-04 8:37 ` Yan Zhao 2020-08-04 8:37 ` Yan Zhao 2020-08-05 9:44 ` Dr. David Alan Gilbert 2020-08-05 9:44 ` Dr. David Alan Gilbert 2020-07-30 1:56 ` Yan Zhao 2020-07-30 1:56 ` Yan Zhao 2020-07-30 13:14 ` Sean Mooney 2020-07-30 13:14 ` Sean Mooney 2020-08-04 16:35 ` Cornelia Huck 2020-08-04 16:35 ` Cornelia Huck 2020-08-05 2:22 ` Jason Wang 2020-08-05 2:22 ` Jason Wang 2020-08-05 2:16 ` Yan Zhao 2020-08-05 2:16 ` Yan Zhao 2020-08-05 2:41 ` Jason Wang 2020-08-05 2:41 ` Jason Wang 2020-08-05 7:56 ` Jiri Pirko 2020-08-05 7:56 ` Jiri Pirko 2020-08-05 8:02 ` Jason Wang 2020-08-05 8:02 ` Jason Wang 2020-08-05 9:33 ` Yan Zhao 2020-08-05 9:33 ` Yan Zhao 2020-08-05 10:53 ` Jiri Pirko 2020-08-05 10:53 ` Jiri Pirko 2020-08-05 11:35 ` Sean Mooney 2020-08-05 11:35 ` Sean Mooney 2020-08-07 11:59 ` Cornelia Huck 2020-08-07 11:59 ` Cornelia Huck 2020-08-13 15:33 ` Cornelia Huck 2020-08-13 15:33 ` Cornelia Huck 2020-08-13 19:02 ` Eric Farman 2020-08-13 19:02 ` Eric Farman 2020-08-17 6:38 ` Cornelia Huck 2020-08-17 6:38 ` Cornelia Huck 2020-08-10 7:46 ` Yan Zhao 2020-08-10 7:46 ` Yan Zhao 2020-08-13 4:24 ` Jason Wang 2020-08-13 4:24 ` Jason Wang 2020-08-14 5:16 ` Yan Zhao 2020-08-14 5:16 ` Yan Zhao 2020-08-14 12:30 ` Sean Mooney 2020-08-14 12:30 ` Sean Mooney 2020-08-17 1:52 ` Yan Zhao 2020-08-17 1:52 ` Yan Zhao 2020-08-18 3:24 ` Jason Wang 2020-08-18 3:24 ` Jason Wang 2020-08-18 8:55 ` Daniel P. Berrangé 2020-08-18 8:55 ` Daniel P. Berrangé 2020-08-18 9:06 ` Cornelia Huck 2020-08-18 9:06 ` Cornelia Huck 2020-08-18 9:24 ` Daniel P. Berrangé 2020-08-18 9:24 ` Daniel P. Berrangé 2020-08-18 9:38 ` Cornelia Huck 2020-08-18 9:38 ` Cornelia Huck [not found] ` <3a073222-dcfe-c02d-198b-29f6a507b2e1@redhat.com> 2020-08-18 9:16 ` Daniel P. Berrangé 2020-08-18 9:16 ` Daniel P. Berrangé 2020-08-18 9:36 ` Cornelia Huck 2020-08-18 9:36 ` Cornelia Huck 2020-08-18 9:39 ` Parav Pandit 2020-08-18 9:39 ` Parav Pandit 2020-08-19 3:30 ` Yan Zhao 2020-08-19 3:30 ` Yan Zhao 2020-08-19 5:58 ` Parav Pandit 2020-08-19 5:58 ` Parav Pandit 2020-08-19 9:41 ` Jason Wang 2020-08-19 9:41 ` Jason Wang 2020-08-19 6:57 ` [ovirt-devel] " Jason Wang 2020-08-19 6:57 ` Jason Wang 2020-08-19 6:59 ` Yan Zhao 2020-08-19 6:59 ` Yan Zhao 2020-08-19 7:39 ` Jason Wang 2020-08-19 7:39 ` Jason Wang 2020-08-19 8:13 ` Yan Zhao 2020-08-19 8:13 ` Yan Zhao 2020-08-19 9:28 ` Jason Wang 2020-08-19 9:28 ` Jason Wang 2020-08-20 12:27 ` Cornelia Huck 2020-08-20 12:27 ` Cornelia Huck 2020-08-21 3:14 ` Jason Wang 2020-08-21 3:14 ` Jason Wang 2020-08-21 14:52 ` Cornelia Huck 2020-08-21 14:52 ` Cornelia Huck 2020-08-31 3:07 ` Jason Wang 2020-08-31 3:07 ` Jason Wang 2020-08-19 17:50 ` Alex Williamson 2020-08-19 17:50 ` Alex Williamson 2020-08-20 0:18 ` Yan Zhao 2020-08-20 0:18 ` Yan Zhao 2020-08-20 3:13 ` Alex Williamson 2020-08-20 3:13 ` Alex Williamson 2020-08-20 3:09 ` Yan Zhao 2020-08-20 3:09 ` Yan Zhao 2020-08-19 2:54 ` Jason Wang 2020-08-19 2:54 ` Jason Wang 2020-08-20 0:39 ` Yan Zhao 2020-08-20 0:39 ` Yan Zhao 2020-08-20 1:29 ` Sean Mooney 2020-08-20 1:29 ` Sean Mooney 2020-08-20 4:01 ` Yan Zhao [this message] 2020-08-20 4:01 ` Yan Zhao 2020-08-20 5:16 ` Sean Mooney 2020-08-20 5:16 ` Sean Mooney 2020-08-20 6:27 ` Yan Zhao 2020-08-20 6:27 ` Yan Zhao 2020-08-20 13:24 ` Sean Mooney 2020-08-20 13:24 ` Sean Mooney 2020-08-26 8:54 ` Yan Zhao 2020-08-26 8:54 ` Yan Zhao 2020-08-20 3:22 ` Alex Williamson 2020-08-20 3:22 ` Alex Williamson 2020-08-20 3:16 ` Yan Zhao 2020-08-20 3:16 ` Yan Zhao 2020-08-25 14:39 ` Cornelia Huck 2020-08-25 14:39 ` Cornelia Huck 2020-08-26 6:41 ` Yan Zhao 2020-08-26 6:41 ` Yan Zhao 2020-08-28 13:47 ` Cornelia Huck 2020-08-28 13:47 ` Cornelia Huck 2020-08-28 14:04 ` Sean Mooney 2020-08-28 14:04 ` Sean Mooney 2020-08-31 4:43 ` Yan Zhao 2020-08-31 4:43 ` Yan Zhao 2020-09-08 14:41 ` Cornelia Huck 2020-09-08 14:41 ` Cornelia Huck 2020-09-09 2:13 ` Yan Zhao 2020-09-09 2:13 ` Yan Zhao 2020-09-10 12:38 ` Cornelia Huck 2020-09-10 12:38 ` Cornelia Huck 2020-09-10 12:50 ` Sean Mooney 2020-09-10 12:50 ` Sean Mooney 2020-09-10 18:02 ` Alex Williamson 2020-09-10 18:02 ` Alex Williamson 2020-09-11 0:56 ` Yan Zhao 2020-09-11 0:56 ` Yan Zhao 2020-09-11 10:08 ` Cornelia Huck 2020-09-11 10:08 ` Cornelia Huck 2020-09-11 10:18 ` Tian, Kevin 2020-09-11 10:18 ` Tian, Kevin 2020-09-11 16:51 ` Alex Williamson 2020-09-11 16:51 ` Alex Williamson 2020-09-14 13:48 ` Zeng, Xin 2020-09-14 13:48 ` Zeng, Xin 2020-09-14 14:44 ` Alex Williamson 2020-09-14 14:44 ` Alex Williamson 2020-09-15 7:46 ` Zeng, Xin 2020-09-09 5:37 ` Yan Zhao 2020-09-09 5:37 ` Yan Zhao 2020-08-31 2:23 ` Yan Zhao 2020-08-19 2:38 ` Jason Wang 2020-08-19 2:38 ` Jason Wang 2020-08-18 9:32 ` Parav Pandit 2020-08-18 9:32 ` Parav Pandit 2020-08-19 2:45 ` Jason Wang 2020-08-19 2:45 ` Jason Wang 2020-08-19 5:26 ` Parav Pandit 2020-08-19 5:26 ` Parav Pandit 2020-08-19 6:48 ` Jason Wang 2020-08-19 6:48 ` Jason Wang 2020-08-19 6:53 ` Parav Pandit 2020-08-19 6:53 ` Parav Pandit 2020-07-29 19:05 ` Dr. David Alan Gilbert 2020-07-29 19:05 ` Dr. David Alan Gilbert
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=20200820040116.GB24121@joy-OptiPlex-7040 \ --to=yan.y.zhao@intel.com \ --cc=alex.williamson@redhat.com \ --cc=bao.yumeng@zte.com.cn \ --cc=berrange@redhat.com \ --cc=cohuck@redhat.com \ --cc=corbet@lwn.net \ --cc=devel@ovirt.org \ --cc=dgilbert@redhat.com \ --cc=dinechin@redhat.com \ --cc=eauger@redhat.com \ --cc=eskultet@redhat.com \ --cc=hejie.xu@intel.com \ --cc=intel-gvt-dev@lists.freedesktop.org \ --cc=jasowang@redhat.com \ --cc=jian-feng.ding@intel.com \ --cc=jiri@mellanox.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=libvir-list@redhat.com \ --cc=openstack-discuss@lists.openstack.org \ --cc=parav@mellanox.com \ --cc=qemu-devel@nongnu.org \ --cc=shaohe.feng@intel.com \ --cc=smooney@redhat.com \ --cc=xin-ran.wang@intel.com \ --cc=zhenyuw@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: 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.