Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

On Tue, Jan 5, 2016 at 1:40 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Jan 04, 2016 at 07:11:25PM -0800, Alexander Duyck wrote: >> >> The two mechanisms referenced above would likely require coordination with >> >> QEMU and as such are open to

Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

On Mon, Jan 4, 2016 at 12:41 PM, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: > On Sun, Dec 13, 2015 at 01:28:09PM -0800, Alexander Duyck wrote: >> This patch set is meant to be the guest side code for a proof of concept >> involving leaving pass-through device

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin wrote: > On Tue, Dec 29, 2015 at 01:42:14AM +0800, Lan, Tianyu wrote: >> >> >> On 12/25/2015 8:11 PM, Michael S. Tsirkin wrote: >> >As long as you keep up this vague talk about performance during >> >migration, without even

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Tue, Dec 29, 2015 at 9:15 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Dec 29, 2015 at 09:04:51AM -0800, Alexander Duyck wrote: >> On Tue, Dec 29, 2015 at 8:46 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Dec 29, 2015 at 01:42

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Sun, Dec 27, 2015 at 1:21 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Fri, Dec 25, 2015 at 02:31:14PM -0800, Alexander Duyck wrote: >> The PCI hot-plug specification calls out that the OS can optionally >> implement a "pause" mechanism which is meant to b

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Sun, Dec 27, 2015 at 7:20 PM, Dong, Eddie wrote: >> > >> > Even if the device driver doesn't support migration, you still want to >> > migrate VM? That maybe risk and we should add the "bad path" for the >> > driver at least. >> >> At a minimum we should have support for

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Thu, Dec 24, 2015 at 11:03 PM, Lan Tianyu <tianyu@intel.com> wrote: > Merry Christmas. > Sorry for later response due to personal affair. > > On 2015年12月14日 03:30, Alexander Duyck wrote: >>> > These sounds we need to add a faked bridge for migration and addi

Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest

On Mon, Dec 14, 2015 at 6:00 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, Dec 13, 2015 at 01:28:31PM -0800, Alexander Duyck wrote: >> This patch is meant to provide the guest with a way of flagging DMA pages >> as being dirty to the host when using a direct

Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest

On Mon, Dec 14, 2015 at 9:20 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Dec 14, 2015 at 08:34:00AM -0800, Alexander Duyck wrote: >> > This way distro can use a guest agent to disable >> > dirtying until before migration starts. >> >> Right. F

Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest

On Mon, Dec 14, 2015 at 12:52 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Dec 14, 2015 at 09:59:13AM -0800, Alexander Duyck wrote: >> On Mon, Dec 14, 2015 at 9:20 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Mon, Dec 14, 2015 at 08:34:00A

Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang <yang.zhang...@gmail.com> wrote: > On 2015/12/14 5:28, Alexander Duyck wrote: >> >> This patch set is meant to be the guest side code for a proof of concept >> involving leaving pass-through devices in the guest during the war

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Sun, Dec 13, 2015 at 7:47 AM, Lan, Tianyu <tianyu@intel.com> wrote: > > > On 12/11/2015 1:16 AM, Alexander Duyck wrote: >> >> On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu <tianyu@intel.com> wrote: >>> >>> >>

[RFC PATCH 2/3] xen/swiotlb: Fold static unmap and sync calls into calling functions

the if statement instead of using a return in the case of sync and unmap. By doing this we make it so that we can also add a dma_mark_dirty function later. Signed-off-by: Alexander Duyck <adu...@mirantis.com> --- drivers/xen/swiotlb-xen.c | 90 ++--- 1 file c

[RFC PATCH 1/3] swiotlb: Fold static unmap and sync calls into calling functions

the if statement instead of using a return in the case of sync and unmap. By doing this we make it so that we can also add a dma_mark_dirty function later. Signed-off-by: Alexander Duyck <adu...@mirantis.com> --- lib/swiotlb.c | 81 +++-- 1 file c

[RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

"SWIOTLB page dirtying" from the "Processor type and features" menu. --- Alexander Duyck (3): swiotlb: Fold static unmap and sync calls into calling functions xen/swiotlb: Fold static unmap and sync calls into calling functions x86: Create dma_mark_dirty to dirt

[RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest

to modify current migration approaches so that instead of having to hot-remove the device before starting the migration this can instead be delayed until the period before the final stop and copy. Signed-off-by: Alexander Duyck <adu...@mirantis.com> --- arch/arm/include/asm/dma-map

Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

On Sun, Dec 13, 2015 at 9:22 PM, Yang Zhang <yang.zhang...@gmail.com> wrote: > On 2015/12/14 12:54, Alexander Duyck wrote: >> >> On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang <yang.zhang...@gmail.com> >> wrote: >>> >>> On 2015/12/14 5:28, Alexander

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Thu, Dec 10, 2015 at 8:11 AM, Michael S. Tsirkin wrote: > On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote: >> >> >> On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: >> >>Ideally, it is able to leave guest driver unmodified but it requires the >> >>>hypervisor

Re: [Qemu-devel] live migration vs device assignment (motivation)

On Thu, Dec 10, 2015 at 6:38 AM, Lan, Tianyu wrote: > > > On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: >>> >>> Ideally, it is able to leave guest driver unmodified but it requires the >>> >hypervisor or qemu to aware the device which means we may need a driver >>> >

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Dec 9, 2015 at 1:28 AM, Lan, Tianyu <tianyu@intel.com> wrote: > > > On 12/8/2015 1:12 AM, Alexander Duyck wrote: >> >> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu <tianyu@intel.com> wrote: >>> >>> On 12/5/2015 1:07 AM, Alexander

Re: live migration vs device assignment (motivation)

On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu wrote: > For other kind of devices, it's hard to work. > We are also adding migration support for QAT(QuickAssist Technology) device. > > QAT device user case introduction. > Server, networking, big data, and storage applications

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu <tianyu@intel.com> wrote: > On 12/5/2015 1:07 AM, Alexander Duyck wrote: >>> >>> >>> We still need to support Windows guest for migration and this is why our >>> patches keep all changes in the drive

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Mon, Dec 7, 2015 at 9:39 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote: >> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu <tianyu@intel.com> wrote: >> > On 12/5/2015 1:07 AM, Alexander Duyck wro

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/04/2015 08:32 AM, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor

Re: [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC

On Wed, Dec 2, 2015 at 6:08 AM, Lan, Tianyu wrote: > On 12/1/2015 11:02 PM, Michael S. Tsirkin wrote: >>> >>> But >>> it requires guest OS to do specific configurations inside and rely on >>> bonding driver which blocks it work on Windows. >>> From performance side, >>>

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote: >> >> >> On 12/1/2015 12:07 AM, Alexander Duyck wrote: >> >They can only be corrected if the underlying assumptions ar

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Tue, Dec 1, 2015 at 9:37 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote: >> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > There are several components t

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Sun, Nov 29, 2015 at 10:53 PM, Lan, Tianyu <tianyu@intel.com> wrote: > On 11/26/2015 11:56 AM, Alexander Duyck wrote: >> >> > I am not saying you cannot modify the drivers, however what you are >> doing is far too invasive. Do you seriously plan on modi

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu <tianyu@intel.com> wrote: > On 2015年11月25日 13:30, Alexander Duyck wrote: >> No, what I am getting at is that you can't go around and modify the >> configuration space for every possible device out there. This >> solu

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 8:02 AM, Lan, Tianyu wrote: > On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: >> >> Frankly, I don't really see what this short term hack buys us, >> and if it goes in, we'll have to maintain it forever. >> > > The framework of how to notify VF about

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Wed, Nov 25, 2015 at 8:39 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Nov 25, 2015 at 08:24:38AM -0800, Alexander Duyck wrote: >> >> Also, assuming you just want to do ifdown/ifup for some reason, it's >> >> easy enough to do using a guest a

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Wed, Nov 25, 2015 at 7:15 PM, Dong, Eddie <eddie.d...@intel.com> wrote: >> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu <tianyu@intel.com> wrote: >> > On 2015年11月25日 13:30, Alexander Duyck wrote: >> >> No, what I am getting at is that you can't go ar

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On Tue, Nov 24, 2015 at 7:18 PM, Lan Tianyu <tianyu@intel.com> wrote: > On 2015年11月24日 22:20, Alexander Duyck wrote: >> I'm still not a fan of this approach. I really feel like this is >> something that should be resolved by extending the existing PCI hot-plug

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin wrote: > On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote: >> This patch is to add migration support for ixgbevf driver. Using >> faked PCI migration capability table communicates with Qemu to >> share migration status

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 11/24/2015 05:38 AM, Lan Tianyu wrote: This patchset is to propose a solution of adding live migration support for SRIOV NIC. During migration, Qemu needs to let VF driver in the VM to know migration start and end. Qemu adds faked PCI migration capability to help to sync status between two

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/29/2015 07:41 PM, Lan Tianyu wrote: On 2015年10月30日 00:17, Alexander Duyck wrote: On 10/29/2015 01:33 AM, Lan Tianyu wrote: On 2015年10月29日 14:58, Alexander Duyck wrote: Your code was having to do a bunch of shuffling in order to get things set up so that you could bring the interface

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/29/2015 01:33 AM, Lan Tianyu wrote: On 2015年10月29日 14:58, Alexander Duyck wrote: Your code was having to do a bunch of shuffling in order to get things set up so that you could bring the interface back up. I would argue that it may actually be faster at least on the bring-up to just drop

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/28/2015 11:12 PM, Lan Tianyu wrote: On 2015年10月26日 23:03, Alexander Duyck wrote: No. I think you are missing the fact that there are 256 descriptors per page. As such if you dirty just 1 you will be pulling in 255 more, of which you may or may not have pulled in the receive buffer

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/25/2015 10:36 PM, Lan Tianyu wrote: On 2015年10月24日 02:36, Alexander Duyck wrote: I was thinking about it and I am pretty sure the dummy write approach is problematic at best. Specifically the issue is that while you are performing a dummy write you risk pulling in descriptors for data

Re: [RFC Patch 05/12] IXGBE: Add new sysfs interface of "notify_vf"

On 10/24/2015 08:43 AM, Lan, Tianyu wrote: On 10/22/2015 4:52 AM, Alexander Duyck wrote: Also have you even considered the MSI-X configuration on the VF? I haven't seen anything anywhere that would have migrated the VF's MSI-X configuration from BAR 3 on one system to the new system. MSI-X

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/21/2015 09:37 AM, Lan Tianyu wrote: This patchset is to propose a new solution to add live migration support for 82599 SRIOV network card. Im our solution, we prefer to put all device specific operation into VF and PF driver and make code in the Qemu more general. VF status migration

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/23/2015 12:05 PM, Alex Williamson wrote: On Fri, 2015-10-23 at 11:36 -0700, Alexander Duyck wrote: On 10/21/2015 09:37 AM, Lan Tianyu wrote: This patchset is to propose a new solution to add live migration support for 82599 SRIOV network card. Im our solution, we prefer to put all

Re: [Qemu-devel] [RFC Patch 06/12] IXGBEVF: Add self emulation layer

On 10/22/2015 05:50 AM, Michael S. Tsirkin wrote: On Wed, Oct 21, 2015 at 01:58:19PM -0700, Alexander Duyck wrote: On 10/21/2015 09:37 AM, Lan Tianyu wrote: In order to restore VF function after migration, add self emulation layer to record regs' values during accessing regs. Signed-off

Re: [RFC Patch 01/12] PCI: Add virtfn_index for struct pci_device

On 10/21/2015 09:37 AM, Lan Tianyu wrote: Add "virtfn_index" member in the struct pci_device to record VF sequence of PF. This will be used in the VF sysfs node handle. Signed-off-by: Lan Tianyu --- drivers/pci/iov.c | 1 + include/linux/pci.h | 1 + 2 files

Re: [RFC Patch 03/12] IXGBE: Add sysfs interface for Qemu to migrate VF status in the PF driver

On 10/21/2015 09:37 AM, Lan Tianyu wrote: This patch is to add sysfs interface state_in_pf under sysfs directory of VF PCI device for Qemu to get and put VF status in the PF driver during migration. Signed-off-by: Lan Tianyu ---

Re: [RFC Patch 05/12] IXGBE: Add new sysfs interface of "notify_vf"

On 10/21/2015 09:37 AM, Lan Tianyu wrote: This patch is to add new sysfs interface of "notify_vf" under sysfs directory of VF PCI device for Qemu to notify VF when migration status is changed. Signed-off-by: Lan Tianyu --- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c

Re: [RFC Patch 06/12] IXGBEVF: Add self emulation layer

On 10/21/2015 09:37 AM, Lan Tianyu wrote: In order to restore VF function after migration, add self emulation layer to record regs' values during accessing regs. Signed-off-by: Lan Tianyu --- drivers/net/ethernet/intel/ixgbevf/Makefile| 3 ++-

Re: [RFC Patch 02/12] IXGBE: Add new mail box event to restore VF status in the PF driver

On 10/21/2015 09:37 AM, Lan Tianyu wrote: This patch is to restore VF status in the PF driver when get event from VF. Signed-off-by: Lan Tianyu --- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 1 +

Re: [RFC Patch 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

On 10/21/2015 09:37 AM, Lan Tianyu wrote: When transmit a package, the end transmit desc of package indicates whether package is sent already. Current code records the end desc's pointer in the next_to_watch of struct tx buffer. This code will be broken if shifting desc ring after migration. The

Re: [RFC Patch 09/12] IXGBEVF: Add live migration support for VF driver

On 10/21/2015 09:37 AM, Lan Tianyu wrote: To let VF driver in the guest to know migration status, Qemu will fake PCI configure reg 0xF0 and 0xF1 to show migrate status and get ack from VF driver. When migration starts, Qemu will set reg "0xF0" to 1, notify VF driver via triggering mail box msg

Re: [RFC Patch 10/12] IXGBEVF: Add lock to protect tx/rx ring operation

On 10/21/2015 09:37 AM, Lan Tianyu wrote: Ring shifting during restoring VF function maybe race with original ring operation(transmit/receive package). This patch is to add tx/rx lock to protect ring related data. Signed-off-by: Lan Tianyu ---

Re: [RFC Patch 00/12] IXGBE: Add live migration support for SRIOV NIC

On 10/21/2015 12:20 PM, Alex Williamson wrote: On Wed, 2015-10-21 at 21:45 +0300, Or Gerlitz wrote: On Wed, Oct 21, 2015 at 7:37 PM, Lan Tianyu wrote: This patchset is to propose a new solution to add live migration support for 82599 SRIOV network card. In our

Re: [PATCH 1/4] PCI: introduce helper functions for device flag operation

On 07/28/2014 07:43 PM, ethan zhao wrote: On 2014/7/29 10:31, Alex Williamson wrote: On Tue, 2014-07-29 at 09:53 +0800, ethan zhao wrote: On 2014/7/29 5:00, Alex Williamson wrote: On Wed, 2014-07-23 at 00:19 +0800, Ethan Zhao wrote: This patch introduced three helper functions to hide

Re: [PATCH 1/2 V3] PCI: introduce device assignment interface and refactory related code

On 07/11/2014 05:30 AM, Ethan Zhao wrote: This patch introduces two new device assignment functions pci_iov_assign_device(), pci_iov_deassign_device() along with the existed one pci_vfs_assigned() They construct the VFs assignment management interface, used to assign/ deassign

Re: [net-next PATCH 1/2] igbvf: add new driver to support 82576 virtual functions

Andrew Morton wrote: On Tue, 17 Mar 2009 17:12:48 -0700 Alexander Duyck alexander.h.du...@intel.com wrote: Thanks for all the comments. I tried to incorporate most of them into the igbvf driver and also ended up porting some over to our other drivers, specifically igb since the igbvf driver

Re: [net-next PATCH 1/2] igbvf: add new driver to support 82576 virtual functions

, 10 Mar 2009 19:09:28 -0700 Jeff Kirsher jeffrey.t.kirs...@intel.com wrote: From: Alexander Duyck alexander.h.du...@intel.com This adds an igbvf driver to handle virtual functions provided by the igb driver. The drive-by reader is now wondering what a virtual function is. ... +#define