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
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
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
---
v2
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 machine_irq
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, so its mach
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 PCI_INTE
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
---
hw
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
@@ -847,6
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 0.
&
eply 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:
> >>
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 not sup
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 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 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
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 "".
> >
> >
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: Zhao Yan
---
hw/vfio/pci.c
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: Zhao Yan
---
hw/vfio/pci.c
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 {
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:
>
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
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 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.
&g
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
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:
> (...)
> >
> > > 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,
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 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 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
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.
> >
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 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
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 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
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 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:
>
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:
>
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.
there 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
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 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
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
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
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
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
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 migrat
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: Tuesday, O
> -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
>
> -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
>
> -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 ;
>
49 matches
Mail list logo
