> -Original Message-
> From: kvm-ow...@vger.kernel.org On Behalf
> Of Alex Williamson
> Sent: Tuesday, March 31, 2020 10:38 AM
> To: Zhao, Yan Y
> Cc: Kirti Wankhede ; c...@nvidia.com; Tian, Kevin
> ; Yang, Ziye ; Liu, Changpeng
> ; Liu, Yi L ;
>
On Sat, Mar 30, 2019 at 10:14:07PM +0800, Alex Williamson wrote:
> On Fri, 29 Mar 2019 19:10:50 -0400
> Zhao Yan wrote:
>
> > On Fri, Mar 29, 2019 at 10:26:39PM +0800, Alex Williamson wrote:
> > > On Thu, 28 Mar 2019 22:47:04 -0400
> > > Zhao Yan wrote:
> &g
On Fri, Mar 29, 2019 at 10:26:39PM +0800, Alex Williamson wrote:
> On Thu, 28 Mar 2019 22:47:04 -0400
> Zhao Yan wrote:
>
> > On Fri, Mar 29, 2019 at 12:04:31AM +0800, Alex Williamson wrote:
> > > On Thu, 28 Mar 2019 10:21:38 +0100
> > > Erik Skultety wrote
On Fri, Mar 29, 2019 at 12:04:31AM +0800, Alex Williamson wrote:
> On Thu, 28 Mar 2019 10:21:38 +0100
> Erik Skultety wrote:
>
> > On Thu, Mar 28, 2019 at 04:36:03AM -0400, Zhao Yan wrote:
> > > hi Alex and Dave,
> > > Thanks for your replies.
> > > Ple
hi Alex and Dave,
Thanks for your replies.
Please see my comments inline.
On Thu, Mar 28, 2019 at 06:10:20AM +0800, Alex Williamson wrote:
> On Wed, 27 Mar 2019 20:18:54 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Zhao Yan (yan.y.z...@intel.com) wrote:
> >
On Wed, Feb 20, 2019 at 07:42:42PM +0800, Cornelia Huck wrote:
> > > > > b) How do we detect if we're migrating from/to the wrong device or
> > > > > version of device? Or say to a device with older firmware or perhaps
> > > > > a device that has less device memory ?
> > > > Actually it's stil
On Mon, Mar 18, 2019 at 11:09:04AM +0800, Alex Williamson wrote:
> On Sun, 17 Mar 2019 22:51:27 -0400
> Zhao Yan wrote:
>
> > On Fri, Mar 15, 2019 at 10:24:02AM +0800, Alex Williamson wrote:
> > > On Thu, 14 Mar 2019 19:05:06 -0400
> > > Zhao Yan wrote:
> &g
On Fri, Mar 15, 2019 at 10:24:02AM +0800, Alex Williamson wrote:
> On Thu, 14 Mar 2019 19:05:06 -0400
> Zhao Yan wrote:
>
> > On Fri, Mar 15, 2019 at 06:44:58AM +0800, Alex Williamson wrote:
> > > On Wed, 13 Mar 2019 21:12:22 -0400
> > > Zhao Yan wrote:
> &g
On Fri, Mar 15, 2019 at 06:44:58AM +0800, Alex Williamson wrote:
> On Wed, 13 Mar 2019 21:12:22 -0400
> Zhao Yan wrote:
>
> > On Thu, Mar 14, 2019 at 03:14:54AM +0800, Alex Williamson wrote:
> > > On Tue, 12 Mar 2019 21:13:01 -0400
> > > Zhao Yan wrote:
>
On Thu, Mar 14, 2019 at 03:14:54AM +0800, Alex Williamson wrote:
> On Tue, 12 Mar 2019 21:13:01 -0400
> Zhao Yan wrote:
>
> > hi Alex
> > Any comments to the sequence below?
> >
> > Actaully we have some concerns and suggestions to userspace-opaque migration
are four states: running, stopped, migrate-in, migrate-out.
migrate-out is for source side when migration starts. together with
state running and stopped, it can substitute state logging.
migrate-in is for target side.
Thanks
Yan
On Tue, Mar 12, 2019 at 10:57:47AM +0800, Zhao Yan wrote
hi Alex
thanks for your reply.
So, if we choose migration data to be userspace opaque, do you think below
sequence is the right behavior for vendor driver to follow:
1. initially LOGGING state is not set. If userspace calls GET_BUFFER to
vendor driver, vendor driver should reject and return 0.
hi Alex
we still have some opens as below. could you kindly help review on that? :)
Thanks
Yan
On Mon, Feb 25, 2019 at 10:22:56AM +0800, Zhao Yan wrote:
> On Thu, Feb 21, 2019 at 01:40:51PM -0700, Alex Williamson wrote:
> > Hi Yan,
> >
> > Thanks for working on this!
&g
On Thu, Feb 21, 2019 at 01:40:51PM -0700, Alex Williamson wrote:
> Hi Yan,
>
> Thanks for working on this!
>
> On Tue, 19 Feb 2019 16:50:54 +0800
> Yan Zhao wrote:
>
> > This patchset enables VFIO devices to have live migration capability.
> > Currently it does not support post-copy phase.
> >
On Thu, Feb 21, 2019 at 03:16:45AM +, Gonglei (Arei) wrote:
>
>
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 10:05 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.co
On Thu, Feb 21, 2019 at 03:33:24AM +, Gonglei (Arei) wrote:
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 9:59 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.com; qem
> >
> > > 5) About log sync, why not register log_global_start/stop in
> > vfio_memory_listener?
> > >
> > >
> > seems log_global_start/stop cannot be iterately called in pre-copy phase?
> > for dirty pages in system memory, it's better to transfer dirty data
> > iteratively to reduce down time, r
On Thu, Feb 21, 2019 at 01:35:43AM +, Gonglei (Arei) wrote:
>
>
> > -Original Message-
> > From: Zhao Yan [mailto:yan.y.z...@intel.com]
> > Sent: Thursday, February 21, 2019 8:25 AM
> > To: Gonglei (Arei)
> > Cc: alex.william...@redhat.com;
On Wed, Feb 20, 2019 at 06:08:13PM +0100, Cornelia Huck wrote:
> On Wed, 20 Feb 2019 02:36:36 -0500
> Zhao Yan wrote:
>
> > On Tue, Feb 19, 2019 at 02:09:18PM +0100, Cornelia Huck wrote:
> > > On Tue, 19 Feb 2019 16:52:14 +0800
> > > Yan Zhao wrote:
> (...)
On Wed, Feb 20, 2019 at 11:01:43AM +, Dr. David Alan Gilbert wrote:
> * Zhao Yan (yan.y.z...@intel.com) wrote:
> > On Tue, Feb 19, 2019 at 11:32:13AM +, Dr. David Alan Gilbert wrote:
> > > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > > This patchset ena
On Wed, Feb 20, 2019 at 11:56:01AM +, Gonglei (Arei) wrote:
> Hi yan,
>
> Thanks for your work.
>
> I have some suggestions or questions:
>
> 1) Would you add msix mode support,? if not, pls add a check in
> vfio_pci_save_config(), likes Nvidia's solution.
ok.
> 2) We should start vfio dev
On Wed, Feb 20, 2019 at 11:14:24AM +0100, Christophe de Dinechin wrote:
>
>
> > On 20 Feb 2019, at 08:58, Zhao Yan wrote:
> >
> > On Tue, Feb 19, 2019 at 03:42:36PM +0100, Christophe de Dinechin wrote:
> >>
> >>
> >>> On 19 Feb 2019, a
On Tue, Feb 19, 2019 at 03:37:24PM +0100, Cornelia Huck wrote:
> On Tue, 19 Feb 2019 16:52:27 +0800
> Yan Zhao wrote:
>
> > Device config is the default data that every device should have. so
> > device config capability is by default on, no need to set.
> >
> > - Currently two type of resources
On Tue, Feb 19, 2019 at 03:42:36PM +0100, Christophe de Dinechin wrote:
>
>
> > On 19 Feb 2019, at 09:53, Yan Zhao wrote:
> >
> > If a device has device memory capability, save/load data from device memory
> > in pre-copy and stop-and-copy phases.
> >
> > LOGGING state is set for device memory
On Tue, Feb 19, 2019 at 02:09:18PM +0100, Cornelia Huck wrote:
> On Tue, 19 Feb 2019 16:52:14 +0800
> Yan Zhao wrote:
>
> > - defined 4 device states regions: one control region and 3 data regions
> > - defined layout of control region in struct vfio_device_state_ctl
> > - defined 4 device states
On Tue, Feb 19, 2019 at 11:32:13AM +, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > This patchset enables VFIO devices to have live migration capability.
> > Currently it does not support post-copy phase.
> >
> > It follows Alex's comments on last version of VFIO
On Tue, Feb 19, 2019 at 11:25:43AM +, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > If a device has device memory capability, save/load data from device memory
> > in pre-copy and stop-and-copy phases.
> >
> > LOGGING state is set for device memory for dirty page
On Tue, Feb 19, 2019 at 11:01:45AM +, Dr. David Alan Gilbert wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > Device config is the default data that every device should have. so
> > device config capability is by default on, no need to set.
> >
> > - Currently two type of resources are sa
On Tue, Jan 08, 2019 at 10:09:11AM -0700, Alex Williamson wrote:
> On Tue, 8 Jan 2019 01:03:48 -0500
> Zhao Yan wrote:
>
> > if multiple regions in vfio are mmaped, their corresponding ramblocks
> > are like below, i.e. their idstrs are "".
> >
> >
qemu parameter
-device
vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/
882cc4da-dede-11e7-9180-078a62063ab1,vfioid=igd
and in target vm, use qemu paramter
-device
vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/
5ac1fb20-2bbf-4842-bb7e-36c58c3be9cd,vfioid=igd
Signed-off-by: Zha
qemu parameter
-device
vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/
882cc4da-dede-11e7-9180-078a62063ab1,vfioid=igd
and in target vm, use qemu paramter
-device
vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/
5ac1fb20-2bbf-4842-bb7e-36c58c3be9cd,vfioid=igd
Signed-off-by: Zha
right, a capabilities field in struct vfio_device_migration_info can avoid
populating iteration APIs and migration states into every vendor drivers
who actually may not requires those APIs and simply do nothing or return
value 0 in response to those APIs.
struct vfio_device_migration_info {
Monné
Signed-off-by: Zhao Yan
---
v2: fix some coding style issue
v3:
1. let subject be more descriptive (roger)
2. disable INTx assertion if machine irq is 0.(roger)
3. in xen_pt_irqpin_reg_init(), drop the else branch as the default
value for *data is 0. (roger)
v4:
drop setting machin
On Tue, Dec 04, 2018 at 10:30:18AM +0100, Roger Pau Monné wrote:
> On Tue, Dec 04, 2018 at 02:50:49AM -0500, Zhao Yan wrote:
> > For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> > doesn't support INTx mode, so its machine irq read from host sysfs is
For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Cc: Roger Pau Monné
Cc: Jan Beulich
Signed-off-by: Zhao Yan
-
se as PCI_INTERRUPT_PIN is 0 and report to guest
the right value (0) of PCI_INTERRUPT_PIN.
Then in guest, it's able to use msi mode and function normally.
On Mon, Dec 03, 2018 at 02:12:58PM +, Andrew Cooper wrote:
> On 03/12/2018 05:04, Zhao Yan wrote:
> > For some pci device, even its P
upt pin" or something similar.
right, thanks for your suggestion. I'll change the subject to this one.
>
> On Mon, Dec 03, 2018 at 12:04:38AM -0500, Zhao Yan wrote:
> > For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> > doesn't support INTx mode, s
ulich
Signed-off-by: Zhao Yan
---
hw/xen/xen_pt.c | 5 +
hw/xen/xen_pt_config_init.c | 8 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index f1f3a3727c..d601c9979c 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -
For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Cc: Roger Pau Monné
Cc: Jan Beulich
Signed-off-by: Zhao Yan
--
On Wed, Nov 21, 2018 at 04:39:41AM +0800, Kirti Wankhede wrote:
> - Migration function are implemented for VFIO_DEVICE_TYPE_PCI device.
> - Added SaveVMHandlers and implemented all basic functions required for live
> migration.
> - Added VM state change handler to know running or stopped state of
my reply below.
>
> I agree, fwiw.
>
> Jan
>
> > On Fri, Nov 23, 2018 at 12:04:51AM -0500, Zhao Yan wrote:
> >> On Thu, Nov 22, 2018 at 03:18:05PM +0100, Roger Pau Monné wrote:
> >> > On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> &g
On Wed, Nov 21, 2018 at 04:39:39AM +0800, Kirti Wankhede wrote:
> - Defined MIGRATION region type and sub-type.
> - Defined VFIO device states during migration process.
> - Defined vfio_device_migration_info structure which will be placed at 0th
> offset of migration region to get/set VFIO device
On Fri, Nov 23, 2018 at 02:51:39AM +0530, Kirti Wankhede wrote:
>
>
> On 11/21/2018 1:09 PM, Zhao, Yan Y wrote:
> >
> >
> >> -Original Message-
> >> From: Qemu-devel [mailto:qemu-devel-
> >> bounces+yan.y.zhao=intel@nongnu.org]
On Thu, Nov 22, 2018 at 03:18:05PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> > On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> > > On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > > >
On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> On Thu, Oct 18, 2018 at 08:22:41AM +0000, Zhao, Yan Y wrote:
> > Hi
> > The background for this patch is that: for some pci device, even it's
> > PCI_INTERRUPT_PIN is not 0, it actually does no
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+yan.y.zhao=intel@nongnu.org] On Behalf Of Kirti Wankhede
> Sent: Wednesday, November 21, 2018 4:40 AM
> To: alex.william...@redhat.com; c...@nvidia.com
> Cc: zhengxiao...@alibaba-inc.com; Tian, Kevin ; Liu, Yi
> L
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+yan.y.zhao=intel@nongnu.org] On Behalf Of Kirti Wankhede
> Sent: Wednesday, November 21, 2018 4:40 AM
> To: alex.william...@redhat.com; c...@nvidia.com
> Cc: zhengxiao...@alibaba-inc.com; Tian, Kevin ; Liu, Yi
> L
le to
destroy guest
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 2:Destruction of
domain failed
After partially revert 5a11d0f7, the device can be passed through into domU and
running quite well using msi mode.
> -Original Message-
> From: Zhao, Yan Y
> Sent: Tuesd
Commit 5a11d0f7 mistakenly converted a log message into an error
condition when irq map is failed for the pci device being
passed through. Revert that part of the commit.
Signed-off-by: Zhao Yan
---
hw/xen/xen_pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xen
49 matches
Mail list logo
