From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Duan, Zhenzhong" <zhenzhong.duan@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>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"lulu@redhat.com" <lulu@redhat.com>,
"Jiang, Yanting" <yanting.jiang@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"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>,
"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: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
Date: Fri, 21 Apr 2023 19:35:50 -0300 [thread overview]
Message-ID: <ZEMPxoT+fSBh23Nj@nvidia.com> (raw)
In-Reply-To: <20230420080839.652732dc.alex.williamson@redhat.com>
On Thu, Apr 20, 2023 at 08:08:39AM -0600, Alex Williamson wrote:
> > Hide this device in the list looks fine to me. But the calling user should
> > not do any new device open before finishing hot-reset. Otherwise, user may
> > miss a device that needs to do pre/post reset. I think this requirement is
> > acceptable. Is it?
>
> I think Kevin and Jason are leaning towards reporting the entire
> dev-set. The INFO ioctl has always been a point-in-time reading, no
> guarantees are made if the host or user configuration is changed.
> Nothing changes in that respect.
Yeah, I think your point about qemu community formus suggest we should
err toward having qemu provide some fully detailed debug report.
> > > Whereas dev-id < 0
> > > (== -1) is an affected device which prevents hot-reset, ex. an un-owned
> > > device, device configured within a different iommufd_ctx, or device
> > > opened outside of the vfio cdev API." Is that about right? Thanks,
> >
> > Do you mean to have separate err-code for the three possibilities? As
> > the devid is generated by iommufd and it is u32. I'm not sure if we can
> > have such err-code definition without reserving some ids in iommufd.
>
> Yes, if we're going to report the full dev-set, I think we need at
> least two unique error codes or else the user has no way to determine
> the subset of invalid dev-ids which block the reset.
If you think this is important to report we should report 0 and -1,
and adjust the iommufd xarray allocator to reserve -1
It depends what you want to show for the debugging.
eg if we have debugging where qemu dumps this table:
BDF In VM iommu_group Has VFIO driver Has Kernel Driver
By also doing various sysfs probes based on the BDF, then the admin
action to remedy the situation is:
Make "Has VFIO driver = y" or "Has Kernel Driver = n" for every row in
the table to make the reset work.
And we don't need the distinction. Adding the 0/-1 lets you make a
useful table without doing any sysfs work.
> I think Jason is proposing the set of valid dev-ids are >0, a dev-id
> of zero indicates some form of non-blocking, while <0 (or maybe
> specifically -1) indicates a blocking device.
Yes, 0 and -1 would be fine with those definitions. The only use of
the data is to add a 'blocking use of reset' colum to the table
above..
Thanks,
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"intel-gvt-dev@lists.freedesktop.org"
<intel-gvt-dev@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>,
"Xu, Terrence" <terrence.xu@intel.com>,
"Jiang, Yanting" <yanting.jiang@intel.com>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>
Subject: Re: [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
Date: Fri, 21 Apr 2023 19:35:50 -0300 [thread overview]
Message-ID: <ZEMPxoT+fSBh23Nj@nvidia.com> (raw)
In-Reply-To: <20230420080839.652732dc.alex.williamson@redhat.com>
On Thu, Apr 20, 2023 at 08:08:39AM -0600, Alex Williamson wrote:
> > Hide this device in the list looks fine to me. But the calling user should
> > not do any new device open before finishing hot-reset. Otherwise, user may
> > miss a device that needs to do pre/post reset. I think this requirement is
> > acceptable. Is it?
>
> I think Kevin and Jason are leaning towards reporting the entire
> dev-set. The INFO ioctl has always been a point-in-time reading, no
> guarantees are made if the host or user configuration is changed.
> Nothing changes in that respect.
Yeah, I think your point about qemu community formus suggest we should
err toward having qemu provide some fully detailed debug report.
> > > Whereas dev-id < 0
> > > (== -1) is an affected device which prevents hot-reset, ex. an un-owned
> > > device, device configured within a different iommufd_ctx, or device
> > > opened outside of the vfio cdev API." Is that about right? Thanks,
> >
> > Do you mean to have separate err-code for the three possibilities? As
> > the devid is generated by iommufd and it is u32. I'm not sure if we can
> > have such err-code definition without reserving some ids in iommufd.
>
> Yes, if we're going to report the full dev-set, I think we need at
> least two unique error codes or else the user has no way to determine
> the subset of invalid dev-ids which block the reset.
If you think this is important to report we should report 0 and -1,
and adjust the iommufd xarray allocator to reserve -1
It depends what you want to show for the debugging.
eg if we have debugging where qemu dumps this table:
BDF In VM iommu_group Has VFIO driver Has Kernel Driver
By also doing various sysfs probes based on the BDF, then the admin
action to remedy the situation is:
Make "Has VFIO driver = y" or "Has Kernel Driver = n" for every row in
the table to make the reset work.
And we don't need the distinction. Adding the 0/-1 lets you make a
useful table without doing any sysfs work.
> I think Jason is proposing the set of valid dev-ids are >0, a dev-id
> of zero indicates some form of non-blocking, while <0 (or maybe
> specifically -1) indicates a blocking device.
Yes, 0 and -1 would be fine with those definitions. The only use of
the data is to add a 'blocking use of reset' colum to the table
above..
Thanks,
Jason
next prev parent reply other threads:[~2023-04-21 22:35 UTC|newest]
Thread overview: 287+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-01 14:44 [Intel-gfx] [PATCH v3 00/12] Introduce new methods for verifying ownership in vfio PCI hot reset Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 01/12] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset() Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 13:59 ` [Intel-gfx] " Eric Auger
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:37 ` [Intel-gfx] " Liu, Yi L
2023-04-04 14:37 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 02/12] vfio/pci: Only check ownership of opened devices in hot reset Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 13:59 ` [Intel-gfx] " Eric Auger
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:37 ` [Intel-gfx] " Liu, Yi L
2023-04-04 14:37 ` Liu, Yi L
2023-04-04 15:18 ` [Intel-gfx] " Eric Auger
2023-04-04 15:18 ` Eric Auger
2023-04-04 15:29 ` [Intel-gfx] " Liu, Yi L
2023-04-04 15:29 ` Liu, Yi L
2023-04-04 15:59 ` [Intel-gfx] " Eric Auger
2023-04-04 15:59 ` Eric Auger
2023-04-05 11:41 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 11:41 ` Jason Gunthorpe
2023-04-05 15:14 ` [Intel-gfx] " Eric Auger
2023-04-05 15:14 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 03/12] vfio/pci: Move the existing hot reset logic to be a helper Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 13:59 ` [Intel-gfx] " Eric Auger
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:24 ` [Intel-gfx] " Liu, Yi L
2023-04-04 14:24 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 04/12] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 15:28 ` [Intel-gfx] " Eric Auger
2023-04-04 15:28 ` Eric Auger
2023-04-04 21:48 ` [Intel-gfx] " Alex Williamson
2023-04-04 21:48 ` Alex Williamson
2023-04-21 7:11 ` [Intel-gfx] " Liu, Yi L
2023-04-21 7:11 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 05/12] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 16:54 ` [Intel-gfx] " Eric Auger
2023-04-04 16:54 ` Eric Auger
2023-04-04 20:18 ` [Intel-gfx] " Alex Williamson
2023-04-04 20:18 ` Alex Williamson
2023-04-05 7:55 ` [Intel-gfx] " Liu, Yi L
2023-04-05 7:55 ` Liu, Yi L
2023-04-05 8:01 ` [Intel-gfx] " Liu, Yi L
2023-04-05 8:01 ` Liu, Yi L
2023-04-05 15:36 ` [Intel-gfx] " Alex Williamson
2023-04-05 15:36 ` Alex Williamson
2023-04-05 16:46 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 16:46 ` Jason Gunthorpe
2023-04-05 8:02 ` [Intel-gfx] " Eric Auger
2023-04-05 8:02 ` Eric Auger
2023-04-05 8:09 ` [Intel-gfx] " Liu, Yi L
2023-04-05 8:09 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 06/12] vfio: Refine vfio file kAPIs for vfio PCI hot reset Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-05 8:27 ` [Intel-gfx] " Eric Auger
2023-04-05 8:27 ` Eric Auger
2023-04-05 9:23 ` [Intel-gfx] " Liu, Yi L
2023-04-05 9:23 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 07/12] vfio: Accpet device file from vfio PCI hot reset path Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 20:31 ` [Intel-gfx] " Alex Williamson
2023-04-04 20:31 ` Alex Williamson
2023-04-05 8:07 ` [Intel-gfx] " Eric Auger
2023-04-05 8:07 ` Eric Auger
2023-04-05 8:10 ` [Intel-gfx] " Liu, Yi L
2023-04-05 8:10 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 08/12] vfio/pci: Renaming for accepting device fd in " Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 21:23 ` [Intel-gfx] " Alex Williamson
2023-04-04 21:23 ` Alex Williamson
2023-04-05 9:32 ` [Intel-gfx] " Eric Auger
2023-04-05 9:32 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 09/12] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-05 9:36 ` [Intel-gfx] " Eric Auger
2023-04-05 9:36 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 10/12] vfio: Mark cdev usage in vfio_device Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-05 11:48 ` [Intel-gfx] " Eric Auger
2023-04-05 11:48 ` Eric Auger
2023-04-21 7:06 ` [Intel-gfx] " Liu, Yi L
2023-04-21 7:06 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 11/12] iommufd: Define IOMMUFD_INVALID_ID in uapi Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-04 21:00 ` [Intel-gfx] " Alex Williamson
2023-04-04 21:00 ` Alex Williamson
2023-04-05 9:31 ` [Intel-gfx] " Liu, Yi L
2023-04-05 9:31 ` Liu, Yi L
2023-04-05 15:13 ` [Intel-gfx] " Alex Williamson
2023-04-05 15:13 ` Alex Williamson
2023-04-05 15:17 ` [Intel-gfx] " Liu, Yi L
2023-04-05 15:17 ` Liu, Yi L
2023-04-05 11:46 ` [Intel-gfx] " Eric Auger
2023-04-05 11:46 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO Yi Liu
2023-04-01 14:44 ` Yi Liu
2023-04-03 9:25 ` [Intel-gfx] " Liu, Yi L
2023-04-03 9:25 ` Liu, Yi L
2023-04-03 15:01 ` [Intel-gfx] " Alex Williamson
2023-04-03 15:01 ` Alex Williamson
2023-04-03 15:22 ` [Intel-gfx] " Liu, Yi L
2023-04-03 15:22 ` Liu, Yi L
2023-04-03 15:32 ` [Intel-gfx] " Alex Williamson
2023-04-03 15:32 ` Alex Williamson
2023-04-03 16:12 ` [Intel-gfx] " Jason Gunthorpe
2023-04-03 16:12 ` Jason Gunthorpe
2023-04-07 10:09 ` [Intel-gfx] " Liu, Yi L
2023-04-07 10:09 ` Liu, Yi L
2023-04-07 12:03 ` [Intel-gfx] " Alex Williamson
2023-04-07 12:03 ` Alex Williamson
2023-04-07 13:24 ` [Intel-gfx] " Liu, Yi L
2023-04-07 13:24 ` Liu, Yi L
2023-04-07 13:51 ` [Intel-gfx] " Alex Williamson
2023-04-07 13:51 ` Alex Williamson
2023-04-07 14:04 ` [Intel-gfx] " Liu, Yi L
2023-04-07 14:04 ` Liu, Yi L
2023-04-07 15:14 ` [Intel-gfx] " Alex Williamson
2023-04-07 15:14 ` Alex Williamson
2023-04-07 15:47 ` [Intel-gfx] " Liu, Yi L
2023-04-07 15:47 ` Liu, Yi L
2023-04-07 21:07 ` [Intel-gfx] " Alex Williamson
2023-04-07 21:07 ` Alex Williamson
2023-04-08 5:07 ` [Intel-gfx] " Liu, Yi L
2023-04-08 5:07 ` Liu, Yi L
2023-04-08 14:20 ` [Intel-gfx] " Alex Williamson
2023-04-08 14:20 ` Alex Williamson
2023-04-09 11:58 ` [Intel-gfx] " Yi Liu
2023-04-09 11:58 ` Yi Liu
2023-04-09 13:29 ` [Intel-gfx] " Alex Williamson
2023-04-09 13:29 ` Alex Williamson
2023-04-10 8:48 ` [Intel-gfx] " Liu, Yi L
2023-04-10 8:48 ` Liu, Yi L
2023-04-10 14:41 ` [Intel-gfx] " Alex Williamson
2023-04-10 14:41 ` Alex Williamson
2023-04-10 15:18 ` [Intel-gfx] " Liu, Yi L
2023-04-10 15:18 ` Liu, Yi L
2023-04-10 15:23 ` [Intel-gfx] " Alex Williamson
2023-04-10 15:23 ` Alex Williamson
2023-04-11 13:34 ` [Intel-gfx] " Jason Gunthorpe
2023-04-11 13:34 ` Jason Gunthorpe
2023-04-11 13:33 ` [Intel-gfx] " Jason Gunthorpe
2023-04-11 13:33 ` Jason Gunthorpe
2023-04-11 6:16 ` [Intel-gfx] " Liu, Yi L
2023-04-11 6:16 ` Liu, Yi L
2023-04-04 22:20 ` [Intel-gfx] " Alex Williamson
2023-04-04 22:20 ` Alex Williamson
2023-04-05 12:19 ` [Intel-gfx] " Eric Auger
2023-04-05 12:19 ` Eric Auger
2023-04-05 14:04 ` [Intel-gfx] " Liu, Yi L
2023-04-05 14:04 ` Liu, Yi L
2023-04-05 16:25 ` [Intel-gfx] " Alex Williamson
2023-04-05 16:25 ` Alex Williamson
2023-04-05 16:37 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 16:37 ` Jason Gunthorpe
2023-04-05 16:52 ` [Intel-gfx] " Alex Williamson
2023-04-05 16:52 ` Alex Williamson
2023-04-05 17:23 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 17:23 ` Jason Gunthorpe
2023-04-05 18:56 ` [Intel-gfx] " Alex Williamson
2023-04-05 18:56 ` Alex Williamson
2023-04-05 19:18 ` [Intel-gfx] " Alex Williamson
2023-04-05 19:18 ` Alex Williamson
2023-04-05 19:21 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 19:21 ` Jason Gunthorpe
2023-04-05 19:49 ` [Intel-gfx] " Alex Williamson
2023-04-05 19:49 ` Alex Williamson
2023-04-05 23:22 ` [Intel-gfx] " Jason Gunthorpe
2023-04-05 23:22 ` Jason Gunthorpe
2023-04-06 10:02 ` [Intel-gfx] " Liu, Yi L
2023-04-06 10:02 ` Liu, Yi L
2023-04-06 17:53 ` [Intel-gfx] " Alex Williamson
2023-04-06 17:53 ` Alex Williamson
2023-04-07 10:09 ` [Intel-gfx] " Liu, Yi L
2023-04-07 10:09 ` Liu, Yi L
2023-04-11 13:24 ` [Intel-gfx] " Jason Gunthorpe
2023-04-11 13:24 ` Jason Gunthorpe
2023-04-11 15:54 ` [Intel-gfx] " Alex Williamson
2023-04-11 17:11 ` Alex Williamson
2023-04-11 18:40 ` Jason Gunthorpe
2023-04-11 18:40 ` Jason Gunthorpe
2023-04-11 21:58 ` [Intel-gfx] " Alex Williamson
2023-04-11 21:58 ` Alex Williamson
2023-04-12 0:01 ` [Intel-gfx] " Jason Gunthorpe
2023-04-12 0:01 ` Jason Gunthorpe
2023-04-12 7:27 ` [Intel-gfx] " Tian, Kevin
2023-04-12 7:27 ` Tian, Kevin
2023-04-12 15:05 ` [Intel-gfx] " Jason Gunthorpe
2023-04-12 15:05 ` Jason Gunthorpe
2023-04-12 17:01 ` [Intel-gfx] " Alex Williamson
2023-04-12 17:01 ` Alex Williamson
2023-04-13 2:57 ` [Intel-gfx] " Tian, Kevin
2023-04-13 2:57 ` Tian, Kevin
2023-04-12 10:09 ` [Intel-gfx] " Liu, Yi L
2023-04-12 10:09 ` Liu, Yi L
2023-04-12 16:54 ` [Intel-gfx] " Alex Williamson
2023-04-12 16:54 ` Alex Williamson
2023-04-12 16:50 ` [Intel-gfx] " Alex Williamson
2023-04-12 16:50 ` Alex Williamson
2023-04-12 20:06 ` [Intel-gfx] " Jason Gunthorpe
2023-04-12 20:06 ` Jason Gunthorpe
2023-04-13 8:25 ` [Intel-gfx] " Tian, Kevin
2023-04-13 8:25 ` Tian, Kevin
2023-04-13 11:50 ` [Intel-gfx] " Jason Gunthorpe
2023-04-13 11:50 ` Jason Gunthorpe
2023-04-13 14:35 ` [Intel-gfx] " Liu, Yi L
2023-04-13 14:35 ` Liu, Yi L
2023-04-13 14:41 ` [Intel-gfx] " Jason Gunthorpe
2023-04-13 14:41 ` Jason Gunthorpe
2023-04-13 18:07 ` [Intel-gfx] " Alex Williamson
2023-04-13 18:07 ` Alex Williamson
2023-04-14 9:11 ` [Intel-gfx] " Tian, Kevin
2023-04-14 9:11 ` Tian, Kevin
2023-04-14 11:38 ` [Intel-gfx] " Liu, Yi L
2023-04-14 11:38 ` Liu, Yi L
2023-04-14 17:10 ` [Intel-gfx] " Alex Williamson
2023-04-14 17:10 ` Alex Williamson
2023-04-17 4:20 ` [Intel-gfx] " Liu, Yi L
2023-04-17 4:20 ` Liu, Yi L
2023-04-17 19:01 ` [Intel-gfx] " Alex Williamson
2023-04-17 19:01 ` Alex Williamson
2023-04-17 19:31 ` [Intel-gfx] " Jason Gunthorpe
2023-04-17 19:31 ` Jason Gunthorpe
2023-04-17 20:06 ` [Intel-gfx] " Alex Williamson
2023-04-17 20:06 ` Alex Williamson
2023-04-18 3:24 ` [Intel-gfx] " Tian, Kevin
2023-04-18 3:24 ` Tian, Kevin
2023-04-18 4:10 ` [Intel-gfx] " Alex Williamson
2023-04-18 4:10 ` Alex Williamson
2023-04-18 5:02 ` [Intel-gfx] " Tian, Kevin
2023-04-18 5:02 ` Tian, Kevin
2023-04-18 12:59 ` [Intel-gfx] " Jason Gunthorpe
2023-04-18 12:59 ` Jason Gunthorpe
2023-04-18 16:44 ` [Intel-gfx] " Alex Williamson
2023-04-18 16:44 ` Alex Williamson
2023-04-18 10:34 ` [Intel-gfx] " Liu, Yi L
2023-04-18 10:34 ` Liu, Yi L
2023-04-18 16:49 ` [Intel-gfx] " Alex Williamson
2023-04-18 16:49 ` Alex Williamson
2023-04-18 12:57 ` [Intel-gfx] " Jason Gunthorpe
2023-04-18 12:57 ` Jason Gunthorpe
2023-04-18 18:39 ` [Intel-gfx] " Alex Williamson
2023-04-18 18:39 ` Alex Williamson
2023-04-20 12:10 ` [Intel-gfx] " Liu, Yi L
2023-04-20 12:10 ` Liu, Yi L
2023-04-20 14:08 ` [Intel-gfx] " Alex Williamson
2023-04-20 14:08 ` Alex Williamson
2023-04-21 22:35 ` Jason Gunthorpe [this message]
2023-04-21 22:35 ` Jason Gunthorpe
2023-04-23 14:46 ` [Intel-gfx] " Liu, Yi L
2023-04-23 14:46 ` Liu, Yi L
2023-04-26 7:22 ` [Intel-gfx] " Liu, Yi L
2023-04-26 7:22 ` Liu, Yi L
2023-04-26 13:20 ` [Intel-gfx] " Alex Williamson
2023-04-26 13:20 ` Alex Williamson
2023-04-26 15:08 ` [Intel-gfx] " Liu, Yi L
2023-04-26 15:08 ` Liu, Yi L
2023-04-14 16:34 ` [Intel-gfx] " Alex Williamson
2023-04-14 16:34 ` Alex Williamson
2023-04-17 13:39 ` [Intel-gfx] " Jason Gunthorpe
2023-04-17 13:39 ` Jason Gunthorpe
2023-04-18 1:28 ` [Intel-gfx] " Tian, Kevin
2023-04-18 1:28 ` Tian, Kevin
2023-04-18 10:23 ` [Intel-gfx] " Liu, Yi L
2023-04-18 10:23 ` Liu, Yi L
2023-04-18 13:02 ` [Intel-gfx] " Jason Gunthorpe
2023-04-18 13:02 ` Jason Gunthorpe
2023-04-23 10:28 ` [Intel-gfx] " Liu, Yi L
2023-04-23 10:28 ` Liu, Yi L
2023-04-24 17:38 ` [Intel-gfx] " Jason Gunthorpe
2023-04-24 17:38 ` Jason Gunthorpe
2023-04-17 14:05 ` [Intel-gfx] " Jason Gunthorpe
2023-04-17 14:05 ` Jason Gunthorpe
2023-04-12 7:14 ` [Intel-gfx] " Tian, Kevin
2023-04-12 7:14 ` Tian, Kevin
2023-04-06 6:34 ` [Intel-gfx] " Liu, Yi L
2023-04-06 6:34 ` Liu, Yi L
2023-04-06 17:07 ` [Intel-gfx] " Alex Williamson
2023-04-06 17:07 ` Alex Williamson
2023-04-05 17:58 ` [Intel-gfx] " Eric Auger
2023-04-05 17:58 ` Eric Auger
2023-04-06 5:31 ` [Intel-gfx] " Liu, Yi L
2023-04-06 5:31 ` Liu, Yi L
2023-04-01 14:47 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce new methods for verifying ownership in vfio PCI hot reset (rev4) 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=ZEMPxoT+fSBh23Nj@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.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=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.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=yanting.jiang@intel.com \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@linux.intel.com \
--cc=zhenzhong.duan@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.