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

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 migration is done by Hypervisor(Qemu).

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

On 10/22/2015 5:14 AM, Alexander Duyck wrote: Where is i being initialized? It was here but you removed it. Are you using i without initializing it? Sorry, the initialization was put into patch 10 by mistake. "i" is assigned with "tx_ring->next_to_clean".

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

On 10/22/2015 2:07 AM, Alexander Duyck wrote: 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 <tianyu@intel.com> --- d

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

On 10/22/2015 8:58 PM, Michael S. Tsirkin wrote: Do you really need to play the shifting games? Can't you just reset everything and re-initialize the rings? It's slower but way less intrusive. Also removes the need to track writes into rings. Shift ring is to avoid losing those packets in

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

On 10/22/2015 4:45 AM, Alexander Duyck wrote: +/* Record states hold by PF */ +memcpy(>vf_data, >vfinfo[vfn], sizeof(struct vf_data_storage)); + +vf_shift = vfn % 32; +reg_offset = vfn / 32; + +reg = IXGBE_READ_REG(hw, IXGBE_VFTE(reg_offset)); +reg &= ~(1 << vf_shift);

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

On 10/25/2015 2:03 PM, Alexander Duyck wrote: 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

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

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 <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 ++ drive

[Qemu-devel] [RFC Patch 11/12] IXGBEVF: Migrate VF statistic data

erface is up or open. Call existed function to update base and saved_reset data to keep statistic data continual during migration. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/

[Qemu-devel] [RFC Patch 04/12] IXGBE: Add ixgbe_ping_vf() to notify a specified VF via mailbox msg.

This patch is to add ixgbe_ping_vf() to notify a specified VF. When migration status is changed, it's necessary to notify VF the change. VF driver will check the migrate status when it gets mailbox msg. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel

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

In order to restore VF function after migration, add self emulation layer to record regs' values during accessing regs. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/Makefile| 3 ++- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

[Qemu-devel] [RFC Patch 12/12] IXGBEVF: Track dma dirty pages

and write it back) during receive and transmit data. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/d

[Qemu-devel] [RFC Patch 01/12] PCI: Add virtfn_index for struct pci_device

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 <tianyu@intel.com> --- drivers/pci/iov.c | 1 + include/linux/pci.h | 1 + 2 files changed, 2 insertions(+) diff --g

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

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 <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 156 -

[Qemu-devel] [RFC PATCH 3/3] Qemu: Introduce pci-sriov device type to support VF live migration

iver tells Qemu it's ready for migration via writing 1 to reg "0xF1". Qemu notifies VF driver about migration status change via new sysfs node notify_vf to send mailbox msg to VF driver. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/i386/kvm/Makefile.objs | 2 +- hw/i386

[Qemu-devel] [RFC PATCH 2/3] Qemu: Add post_load_state() to run after restoring CPU state

-by: Lan Tianyu <tianyu@intel.com> --- include/migration/vmstate.h | 2 ++ migration/savevm.c | 15 +++ 2 files changed, 17 insertions(+) diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h index 0695d7c..dc681a6 100644 --- a/include/migration/vmstate.h

[Qemu-devel] [RFC PATCH 0/3] Qemu/IXGBE: Add live migration support for SRIOV NIC

This patchset is Qemu part for live migration support for SRIOV NIC. kernel part patch information is in the following link. http://marc.info/?l=kvm=144544635330193=2 Lan Tianyu (3): Qemu: Add pci-assign.h to share functions and struct definition with new file Qemu: Add post_load_state

[Qemu-devel] [RFC PATCH 1/3] Qemu: Add pci-assign.h to share functions and struct definition with new file

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/i386/kvm/pci-assign.c | 111 ++- hw/i386/kvm/pci-assign.h | 109 ++ 2 files changed, 112 insertions(+), 108 deletions(-) create mode 100644 hw/i3

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

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 <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 30 +++

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

This patch is to restore VF status in the PF driver when get event from VF. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.

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

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 that > hasn't been dummy written to yet.

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

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 for. > > So for example if you have the

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

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 the > old rings and start over

Re: [Qemu-devel] [RFC PATCH 0/3] Qemu/IXGBE: Add live migration support for SRIOV NIC

On 2015年10月22日 02:39, Alex Williamson wrote: > On Thu, 2015-10-22 at 00:52 +0800, Lan Tianyu wrote: >> This patchset is Qemu part for live migration support for SRIOV NIC. >> kernel part patch information is in the following link. >> http://marc.info/?l=kvm=144544635330193=2 &

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

of the ring and then enable tx/rx rings. VF restarts to receive and transmit from original head desc. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/defines.h | 6 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 +- drivers/ne

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

=== So far, the patchset isn't perfect. VF net interface can't be open, closed, down and up during migration. Will prevent such operation during migration in the future job. Very appreciate for your comments. Lan Tianyu (12): PCI: Add virtfn_index for struct pci_device IXGBE: Add new mail

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

is to replace recording pointer with recording the desc number of the package and find the end decs via the first desc and desc number. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.

[Qemu-devel] [RFC Patch 07/12] IXGBEVF: Add new mail box event for migration

VF status in the PF driver needs to be restored after migration and reset VF hardware. This patch is to add a new event for VF driver to notify PF driver to restore status. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/mbx.h | 3 +++ drive

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

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 interf

[Qemu-devel] [PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

_child_property() will access msix->mmio's obj. But the whole msix struct has already been freed by xen_pt_msix_delete. This will cause segment fault when msix->mmio has been overwritten. This patch is to fix the issue. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/xen/xen_pt.c

Re: [Qemu-devel] [Fix PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

On 10/6/2015 9:49 PM, Stefano Stabellini wrote: On Tue, 6 Oct 2015, Paolo Bonzini wrote: On 05/10/2015 18:53, Stefano Stabellini wrote: This patch is to fix the issue via moving MSIX MMIO memory region into struct XenPCIPassthroughState and free it together with pt device's obj. Given that

[Qemu-devel] [Fix PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

deleting pt device's properties, this will cause segment fault. Reproduce the bug via hotplugging device frequently. This patch is to fix the issue via moving MSIX MMIO memory region into struct XenPCIPassthroughState and free it together with pt device's obj. Signed-off-by: Lan Tianyu <tia

[Qemu-devel] [Resend Fix PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

deleting pt device's properties, this will cause segment fault. Reproduce the bug via hotplugging device frequently. This patch is to fix the issue via moving MSIX MMIO memory region into struct XenPCIPassthroughState and free it together with pt device's obj. Signed-off-by: Lan Tianyu <tia

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

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 driver since it's impossible to change Windows kernel. That is a poor argument. I highly doubt Microsoft is interested in having to modify all

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

On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote: >We hope >to find a better way to make SRIOV NIC work in these cases and this is >worth to do since SRIOV NIC provides better network performance compared >with PV NIC. If this is a performance optimization as the above implies, you need to

Re: [Qemu-devel] [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

On 12/3/2015 6:25 AM, Alex Williamson wrote: On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote: This patch is to add SRIOV VF migration support. Create new device type "vfio-sriov" and add faked PCI migration capability to the type device. The purpose of the new capabili

Re: [Qemu-devel] [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition

On 12/3/2015 6:25 AM, Alex Williamson wrote: I didn't seen a matching kernel patch series for this, but why is the kernel more capable of doing this than userspace is already? The following link is the kernel patch. http://marc.info/?l=kvm=144837328920989=2 These seem like pointless ioctls,

Re: [Qemu-devel] [RFC PATCH V2 06/10] Qemu/PCI: Add macros for faked PCI migration capability

On 12/3/2015 6:25 AM, Alex Williamson wrote: This will of course break if the PCI SIG defines that capability index. Couldn't this be done within a vendor defined capability? Thanks, Yes, it should work and thanks for suggestion.

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

On 12/4/2015 4:05 PM, Michael S. Tsirkin wrote: I haven't read it, but I would like to note you can't rely on research papers. If you propose a patch to be merged you need to measure what is its actual effect on modern linux at the end of 2015. Sure. Will do that.

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

On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote: >We hope >to find a better way to make SRIOV NIC work in these cases and this is >worth to do since SRIOV NIC provides better network performance compared >with PV NIC. If this is a performance optimization as the above implies, you need to

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

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. Following is my idea to do DMA tracking. Inject event to VF

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

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 Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver sinc

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

On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. It's nice that it's appreciated, but you then go on and ignore all that I have written here: https://www.

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

On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote: I remember reading that it's possible to implement a bus driver on windows if required. But basically I don't see how windows can be relevant to discussing guest driver patches. That discussion probably belongs on the qemu maling list, not on

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

On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: I thought about what this is doing at the high level, and I do have some value in what you are trying to do, but I also think we need to clarify the motivation a bit more. What you are saying is not really what the patches are doing. And with

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

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, putting VF and virtio NIC under bonded interface will affect their performance even when not do

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

On 12/10/2015 1:14 AM, Alexander Duyck wrote: On Wed, Dec 9, 2015 at 8:26 AM, Lan, Tianyu <tianyu@intel.com> 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.

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

On 12/10/2015 4:07 AM, Michael S. Tsirkin wrote: On Thu, Dec 10, 2015 at 12:26:25AM +0800, Lan, Tianyu wrote: On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: I thought about what this is doing at the high level, and I do have some value in what you are trying to do, but I also think we need

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

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: 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

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

On 12/11/2015 12: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 or qemu to aware the device which means

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

On 12/10/2015 4:38 PM, Michael S. Tsirkin wrote: Let's assume you do save state and do have a way to detect whether state matches a given hardware. For example, driver could store firmware and hardware versions in the state, and then on destination, retrieve them and compare. It will be pretty

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

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 in >hypervisor or qemu to handle the device on behalf of guest driver. Can you answer the

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

On 2015年12月30日 00:46, Michael S. Tsirkin wrote: > Interesting. So you sare saying merely ifdown/ifup is 100ms? > This does not sound reasonable. > Is there a chance you are e.g. getting IP from dhcp? > > If so that is wrong - clearly should reconfigure the old IP > back without playing with dhcp.

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

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 adding a >> > driver in the guest for it. It also needs to extend PCI bus/hotplug >> > driver to do pause/resume other

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

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 bothering with any measurements, this patchset will keep going nowhere. I measured network service downtime for "keep device alive"(RFC patch V1

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

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 > rather than trying to instrument this per driver. Then you will get the > goodness for multiple drivers and

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

On 2015年11月25日 05:20, Michael S. Tsirkin wrote: > I have to say, I was much more interested in the idea > of tracking dirty memory. I have some thoughts about > that one - did you give up on it then? No, our finial target is to keep VF active before doing migration and tracking dirty memory is

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

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 migration status won't be changed regardless of stopping VF or not before doing

Re: [Qemu-devel] [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

On 11/25/2015 5:03 AM, Michael S. Tsirkin wrote: >+void vfio_migration_cap_handle(PCIDevice *pdev, uint32_t addr, >+ uint32_t val, int len) >+{ >+VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev); >+ >+if (addr == vdev->migration_cap +

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

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 > solution won't scale. PCI config space regs are emulation by Qemu and so We can find the free PCI config space

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

On 11/30/2015 4:01 PM, Michael S. Tsirkin wrote: It is still not very clear what it is you are trying to achieve, and whether your patchset achieves it. You merely say "adding live migration" but it seems pretty clear this isn't about being able to migrate a guest transparently, since you are

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

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 modifying all of the PCI device drivers out there in order to allow any device that might be direct assigned to a port to

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

On 12/1/2015 12:07 AM, Alexander Duyck wrote: They can only be corrected if the underlying assumptions are correct and they aren't. Your solution would have never worked correctly. The problem is you assume you can keep the device running when you are migrating and you simply cannot. At some

[Qemu-devel] [RFC PATCH V2 01/10] Qemu/VFIO: Create head file pci.h to share data struct.

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/pci.c | 137 +- hw/vfio/pci.h | 158 ++ 2 files changed, 159 insertions(+), 136 deletions(-) create mode 100644 hw/vfio/pci.h

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

before migration and put up again on the target machine. Lan Tianyu (10): Qemu/VFIO: Create head file pci.h to share data struct. Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition Qemu/VFIO: Rework vfio_std_cap_max_size() function Qemu/VFIO: Add vfio_find_free_cfg_reg() to find

[Qemu-devel] [RFC PATCH V2 04/10] Qemu/VFIO: Add vfio_find_free_cfg_reg() to find free PCI config space regs

This patch is to add ioctl wrap to find free PCI config sapce regs. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/pci.c | 19 +++ hw/vfio/pci.h | 2 ++ 2 files changed, 21 insertions(+) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 29845e3..d0354a0

[Qemu-devel] [RFC PATCH V2 1/3] VFIO: Add new ioctl cmd VFIO_GET_PCI_CAP_INFO

This patch is to add new ioctl cmd VFIO_GET_PCI_CAP_INFO to get PCI cap table size and get free PCI config space regs according pos and size. Qemu will add faked PCI capability for migration and need such info. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/vfio/pci/vfio

[Qemu-devel] [RFC PATCH V2 2/3] PCI: Add macros for faked PCI migration capability

migration status in the reg *PCI_VF_MIGRATION_VF_STATUS VF driver tells Qemu ready for migration *PCI_VF_MIGRATION_IRQ VF driver stores mailbox interrupt vector in the reg for Qemu to trigger during migration. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- include/uapi/linux/pci_regs.

[Qemu-devel] [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

_VF_STATUS in the new cap table to tell Qemu. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/Makefile.objs | 2 +- hw/vfio/pci.c | 6 ++ hw/vfio/pci.h | 4 ++ hw/vfio/sriov.c | 178 ++ 4 files changed, 189

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

before migration and put up again on the target machine. Lan Tianyu (3): VFIO: Add new ioctl cmd VFIO_GET_PCI_CAP_INFO PCI: Add macros for faked PCI migration capability Ixgbevf: Add migration support for ixgbevf driver drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 ++ drivers/net

[Qemu-devel] [RFC PATCH V2 03/10] Qemu/VFIO: Rework vfio_std_cap_max_size() function

capability and occupy some free PCI config space regs. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/pci.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 5c3f8a7..29845e3 100644 --- a/hw/vfio/pci.c ++

[Qemu-devel] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

irq won't be triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP reg. These case will be resolved later. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 5 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

[Qemu-devel] [RFC PATCH V2 07/10] Qemu: Add post_load_state() to run after restoring CPU state

-by: Lan Tianyu <tianyu@intel.com> --- include/migration/vmstate.h | 2 ++ migration/savevm.c | 15 +++ 2 files changed, 17 insertions(+) diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h index 0695d7c..dc681a6 100644 --- a/include/migration/vmstate.h

[Qemu-devel] [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- linux-headers/linux/vfio.h | 16 1 file changed, 16 insertions(+) diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h index 0508d0b..732b0bd 100644 --- a/linux-headers/linux/vfio.h +++ b/linux-headers

[Qemu-devel] [RFC PATCH V2 05/10] Qemu/VFIO: Expose PCI config space read/write and msix functions

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/pci.c | 6 +++--- hw/vfio/pci.h | 4 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index d0354a0..7c43fc1 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -613,7 +613,7 @@ stati

[Qemu-devel] [RFC PATCH V2 06/10] Qemu/PCI: Add macros for faked PCI migration capability

migration status in the reg *PCI_VF_MIGRATION_VF_STATUS VF driver tells Qemu ready for migration *PCI_VF_MIGRATION_IRQ VF driver stores mailbox interrupt vector in the reg for Qemu to trigger during migration. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- include/hw/pci/pci_regs.

[Qemu-devel] [RFC PATCH V2 08/10] Qemu: Add save_before_stop callback to run just before stopping VCPU during migration

This patch is to add a callback which is called just before stopping VCPU. It's for VF migration to trigger mailbox irq as later as possible to decrease service downtime. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- include/migration/vmstate.h | 3 +++ include/sysemu/sysemu.h

[Qemu-devel] [RFC PATCH V2 10/10] Qemu/VFIO: Misc change for enable migration with VFIO

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/pci.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index e7583b5..404a5cd 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -3625,11 +3625,6 @@ static Property vfio_pci_dev_prop

Re: [Qemu-devel] [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off

On 2016年02月27日 03:54, Eduardo Habkost wrote: > On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote: >> x2apic feature is in the kvm_default_props and automatically added to all >> CPU models when KVM is enabled. But userspace devices don't support x2apic >> which can

Re: [Qemu-devel] kvm: "warning: host doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]"

2016-02-25 16:39 GMT+08:00 Jan Kiszka <jan.kis...@web.de>: > On 2016-02-25 09:33, Lan Tianyu wrote: >> 2016-02-20 17:00 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>: >>> >>> >>> - Original Message - >>>> From: "

Re: [Qemu-devel] kvm: "warning: host doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]"

t;> (ie. also MSR vmexiting to there), or should we otherwise avoid it? > > I think it's a bug, x2apic should be auto-suppressed with kernel_irqchip=off. > The patch is to fix the issue. ->8 >From 58f2a3a94c8e7bf9f3474bcafb6c59cc4f8b

[Qemu-devel] [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off

[bit 21]" when kernel_irqchip is off. This patch is to fix it via removing x2apic feature when kernel_irqchip is off. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- target-i386/cpu.c | 4 1 file changed, 4 insertions(+) diff --git a/target-i386/cpu.c b/target-i386/cpu

Re: [Qemu-devel] [PATCH] Qemu/KVM: Remove x2apic feature from CPU model when kernel_irqchip is off

On 3/1/2016 10:00 PM, Eduardo Habkost wrote: On Mon, Feb 29, 2016 at 10:56:04AM +0800, Lan Tianyu wrote: On 2016年02月27日 03:54, Eduardo Habkost wrote: On Thu, Feb 25, 2016 at 11:15:12PM +0800, Lan Tianyu wrote: x2apic feature is in the kvm_default_props and automatically added to all CPU

[Qemu-devel] [Resend RFC PATCH 4/4] VFIO: Read IOMMU fault info from kernel space when get fault event

This patch is to implement fault event handler with new vfio cmd to get fault info and notify vIOMMU device model. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/common.c | 51 ++ linux-headers/linux/vfio.

[Qemu-devel] [Resend RFC PATCH 1/4] VFIO: Set eventfd for IOMMU fault event via new vfio cmd

This patch is to assign an event fd to VFIO IOMMU type1 driver in order to get notification when IOMMU driver reports fault event. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/vfio/common.c | 37 + include/hw/vfio/vfio-common.

[Qemu-devel] [Resend RFC PATCH 3/4] Intel iommu: Add Intel IOMMU fault event callback

This patch is to deal with fault event reported from IOMMU driver. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/i386/intel_iommu.c | 25 + 1 file changed, 25 insertions(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 9b1ba1b..79507d2

[Qemu-devel] [Resend RFC PATCH 0/4] VT-d: Inject fault event from IOMMU hardware

is to confirm interface between Qemu and VFIO kernel driver is on the right way. Very appreciate for comments. Lan Tianyu (4): VFIO: Set eventfd for IOMMU fault event via new vfio cmd Memory: Introduce IOMMU fault event callback Intel iommu: Add Intel IOMMU fault event callback VFIO: Read IOMMU

Re: [Qemu-devel] [PATCH for-2.8 00/18] pc: q35: x2APIC support in kvm_apic mode

On 2016年09月23日 13:26, Peter Xu wrote: > On Thu, Sep 22, 2016 at 12:34:36PM +0800, Chao Gao wrote: >> Hi, we had 3 problems left here. >> 1. IRQremapping can't work with x2apic_cluster mode. >> 2. apic_id > 255 can't receive devices interrupts. >> 3. windows crash when present IRQremapping

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月06日 18:59, Peter Xu wrote: > On Tue, Dec 06, 2016 at 04:27:39PM +0800, Lan Tianyu wrote: > > [...] > >>> >>>> User space driver(E.G DPDK) also can enable/disable >>>> IOVA for device dynamically. >>> >>> Could you provide

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月07日 14:43, Peter Xu wrote: On Wed, Dec 07, 2016 at 02:09:16PM +0800, Lan Tianyu wrote: On 2016年12月06日 18:59, Peter Xu wrote: On Tue, Dec 06, 2016 at 04:27:39PM +0800, Lan Tianyu wrote: [...] User space driver(E.G DPDK) also can enable/disable IOVA for device dynamically

Re: [Qemu-devel] [RFC PATCH 11/13] intel_iommu: provide its own replay() callback

On 2016年12月06日 18:36, Peter Xu wrote: > +/** > + * vtd_page_walk - walk specific IOVA range, and call the hook > + * > + * @ce: context entry to walk upon > + * @start: IOVA address to start the walk > + * @end: size of the IOVA range to walk over

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 12/3/2016 1:30 AM, Alex Williamson wrote: > On Fri, 2 Dec 2016 14:08:59 +0800 > Peter Xu <pet...@redhat.com> wrote: > >> On Thu, Dec 01, 2016 at 04:27:52PM +0800, Lan Tianyu wrote: >>> On 2016年11月30日 17:23, Peter Xu wrote: >>>> On Mon, Nov 28

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月06日 15:22, Peter Xu wrote: > On Tue, Dec 06, 2016 at 03:06:20PM +0800, Lan Tianyu wrote: >> On 2016年12月06日 14:51, Peter Xu wrote: >>> On Tue, Dec 06, 2016 at 02:30:24PM +0800, Lan Tianyu wrote: >>> >>> [...] >>> >>>>>> 2.

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月02日 14:52, Peter Xu wrote: > On Thu, Dec 01, 2016 at 02:44:14PM +0800, Lan Tianyu wrote: > > [...] > >> Hi: >> I think there are still other gaps to enable passthough device with >> vIOMMU's DMA translation support. >> >> 1. Since this

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月06日 14:51, Peter Xu wrote: > On Tue, Dec 06, 2016 at 02:30:24PM +0800, Lan Tianyu wrote: > > [...] > >>>> 2. How to restore GPA->HPA mapping when IOVA is disabled by guest. >>>> When guest enables IOVA for device, vIOMMU will invalidate all pr

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年11月28日 23:51, Aviv B.D wrote: > From: "Aviv Ben-David" > > * Advertize Cache Mode capability in iommu cap register. > This capability is controlled by "cache-mode" property of intel-iommu > device. > To enable this option call QEMU with "-device

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年11月30日 17:23, Peter Xu wrote: > On Mon, Nov 28, 2016 at 05:51:50PM +0200, Aviv B.D wrote: >> * intel_iommu's replay op is not implemented yet (May come in different >> patch >> set). >> The replay function is required for hotplug vfio device and to move >> devices >> between

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月01日 12:21, Tian, Kevin wrote: >> I am thinking about this replay thing recently and now I start to >> > doubt whether the whole vt-d vIOMMU framework suites this... >> > >> > Generally speaking, current work is throwing away the IOMMU "domain" >> > layer here. We maintain the mapping

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

On 2016年12月08日 10:39, Peter Xu wrote: > Btw, do you have time to help review my RFC series for "vt-d replay"? > :) I'd like to receive any further review comments besides the issues > mentioned above since IMHO they can be seperated from current series, > I have noted them down in my pending list.

Re: [Qemu-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 2017年03月17日 22:48, Paolo Bonzini wrote: > > > On 17/03/2017 12:29, Lan Tianyu wrote: >> This patchset is to add Xen vIOMMU device model and handle >> irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor >> and the new device module in Qemu

Re: [Qemu-devel] [RFC PATCH 1/4] I440: Allow adding sysbus devices with -device on I440

Hi Eduardo: Thanks for your review. On 2017年03月21日 03:49, Eduardo Habkost wrote: > On Fri, Mar 17, 2017 at 07:29:14PM +0800, Lan Tianyu wrote: >> From: Chao Gao <chao@intel.com> >> >> xen-viommu will be a sysbus device and the device model will >> b

  1   2   >