RE: [PATCH v5 4/6] kvm: irqchip: extract kvm_irqchip_add_deferred_msi_route

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, November 12, 2021 5:32 PM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > ; alex.william...@redhat.com > Cc: qemu-devel@nongnu.org; k...@vger.kernel.

RE: [PATCH v5 4/6] kvm: irqchip: extract kvm_irqchip_add_deferred_msi_route

Hi Paolo, Ping... Do you have any suggestions about this change ? It seems Alex has no objection on this series now, but we need your ACK, thanks. > -Original Message- > From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > Sent: Wednesday, November 3, 202

RE: [PATCH v4 6/6] vfio: defer to commit kvm irq routing when enable msi/msix

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, October 22, 2021 4:51 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > > Cc: pbonz...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.or

RE: [PATCH v3 8/9] Revert "vfio: Avoid disabling and enabling vectors repeatedly in VFIO migration"

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, October 2, 2021 7:04 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > > Cc: phi...@redhat.com; pbonz...@redhat.com; marcel.apfelb...@gmail.com;

RE: [PATCH v3 7/9] vfio: add infrastructure to commit the deferred kvm routing

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, October 2, 2021 7:05 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > > Cc: phi...@redhat.com; pbonz...@redhat.com; marcel.apfelb...@gmail.com;

RE: [PATCH v3 4/9] msix: simplify the conditional in msix_set/unset_vector_notifiers

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, October 2, 2021 7:04 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > > Cc: phi...@redhat.com; pbonz...@redhat.com; marcel.apfelb...@gmail.com;

RE: [PATCH v3 9/9] vfio: defer to commit kvm irq routing when enable msi/msix

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Saturday, October 2, 2021 7:05 AM > To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > > Cc: phi...@redhat.com; pbonz...@redhat.com; marcel.apfelb...@gmail.com;

Re: [PATCH v2 0/9] optimize the downtime for vfio migration

Hi guys, Ping... I just sent out V3, please review on V3, thanks! 在 2021/9/9 14:06, Longpeng(Mike) 写道: > Hi guys, > > In vfio migration resume phase, the cost would increase if the > vfio device has more unmasked vectors. We try to optimize it in > this series. > > You can see the commit

Re: [PATCH 5/5] vfio: defer to commit kvm route in migraiton resume phase

在 2021/9/4 5:57, Alex Williamson 写道: > On Wed, 25 Aug 2021 15:56:20 +0800 > "Longpeng(Mike)" wrote: > >> In migration resume phase, all unmasked msix vectors need to be >> setup when load the VF state. However, the setup operation would >> takes longer if the VF has more unmasked vectors. >>

Re: [PATCH 4/5] kvm: irqchip: support defer to commit the route

在 2021/9/4 5:57, Alex Williamson 写道: > On Wed, 25 Aug 2021 15:56:19 +0800 > "Longpeng(Mike)" wrote: > >> The kvm_irqchip_commit_routes() is relatively expensive, so >> provide the users a choice to commit the route immediately >> or not when they add msi/msix route. >> >> Signed-off-by:

Re: [PATCH 3/5] vfio: defer to enable msix in migration resume phase

在 2021/9/4 5:56, Alex Williamson 写道: > On Wed, 25 Aug 2021 15:56:18 +0800 > "Longpeng(Mike)" wrote: > >> The vf's unmasked msix vectors will be enable one by one in >> migraiton resume phase, VFIO_DEVICE_SET_IRQS will be called >> for each vector, it's a bit expensive if the vf has more >>

Re: [PATCH 1/5] vfio: use helper to simplfy the failure path in vfio_msi_enable

在 2021/9/4 5:55, Alex Williamson 写道: > On Wed, 25 Aug 2021 15:56:16 +0800 > "Longpeng(Mike)" wrote: > >> The main difference of the failure path in vfio_msi_enable and >> vfio_msi_disable_common is enable INTX or not. >> >> Extend the vfio_msi_disable_common to provide a arg to decide > >

Re: [PATCH 0/5] optimize the downtime for vfio migration

Hi maintainers, Ping... 在 2021/8/25 15:56, Longpeng(Mike) 写道: > In vfio migration resume phase, the cost would increase if the > vfio device has more unmasked vectors. We try to optimize it in > this series. > > Patch 1 & 2 are simple code cleanups. > Patch 3 defers to set irqs to vfio core. >

Re: [PATCH 0/5] optimize the downtime for vfio migration

在 2021/8/25 18:05, Philippe Mathieu-Daudé 写道: > Cc'ing David/Juan for migration big picture (just in case). > > On 8/25/21 9:56 AM, Longpeng(Mike) wrote: >> In vfio migration resume phase, the cost would increase if the >> vfio device has more unmasked vectors. We try to optimize it in >> this

Re: [PATCH 3/5] vfio: defer to enable msix in migration resume phase

在 2021/8/25 17:57, Philippe Mathieu-Daudé 写道: > On 8/25/21 9:56 AM, Longpeng(Mike) wrote: >> The vf's unmasked msix vectors will be enable one by one in >> migraiton resume phase, VFIO_DEVICE_SET_IRQS will be called > > Typo "migration" > Ok. >> for each vector, it's a bit expensive if the

Re: [PATCH 2/5] msix: simplfy the conditional in msix_set/unset_vector_notifiers

在 2021/8/25 17:52, Philippe Mathieu-Daudé 写道: > On 8/25/21 9:56 AM, Longpeng(Mike) wrote: >> 'msix_function_masked' is kept pace with the device's config, >> we can use it to replace the complex conditional in >> msix_set/unset_vector_notifiers. > > Typo 'simplfy' -> 'simplify' in

Re: [RFC] vfio/migration: reduce the msix virq setup cost in resume phase

在 2021/8/18 11:50, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) 写道: > > > 在 2021/8/18 4:26, Alex Williamson 写道: >> On Fri, 13 Aug 2021 12:06:14 +0800 >> "Longpeng(Mike)" wrote: >> >>> In migration resume phase, all unmasked msix

Re: [RFC] vfio/migration: reduce the msix virq setup cost in resume phase

在 2021/8/18 4:26, Alex Williamson 写道: > On Fri, 13 Aug 2021 12:06:14 +0800 > "Longpeng(Mike)" wrote: > >> In migration resume phase, all unmasked msix vectors need to be >> setup when load the VF state. However, the setup operation would >> takes longer if the VF has more unmasked vectors. >>

Re: [Question] Reduce the msix_load cost for VFIO device

Hi Alex, 在 2021/8/3 22:19, Alex Williamson 写道: > On Tue, 3 Aug 2021 16:43:07 +0800 > "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" > wrote: > >> Hi Alex, >> >> We found that the msix_load() will cost 40~50ms if the VF has 60+ interru

Re: [Question] Reduce the msix_load cost for VFIO device

在 2021/8/3 22:19, Alex Williamson 写道: > On Tue, 3 Aug 2021 16:43:07 +0800 > "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" > wrote: > >> Hi Alex, >> >> We found that the msix_load() will cost 40~50ms if the VF has 60+ interrupts, >

[Question] Reduce the msix_load cost for VFIO device

Hi Alex, We found that the msix_load() will cost 40~50ms if the VF has 60+ interrupts, the following code cost too much for each interrupt: msix_load: for (vector = 0; vector < 60; vector++) msix_handle_mask_update vfio_msix_vector_do_use vfio_add_kvm_msi_virq

Re: A bug of Monitor Chardev ?

在 2021/6/8 23:37, Daniel P. Berrangé 写道: > On Tue, Jun 08, 2021 at 04:07:30PM +0200, Markus Armbruster wrote: >> "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" >> writes: >> >>> We find a race during QEMU starting, which w

Re: A bug of Monitor Chardev ?

Hi Marc, 在 2021/5/22 0:59, Marc-André Lureau 写道: > Hi > > On Fri, May 21, 2021 at 8:56 PM Daniel P. Berrangé > wrote: > > On Fri, May 21, 2021 at 05:33:46PM +0100, Daniel P. Berrangé wrote: > > On Fri, May 21, 2021 at 10:43:36AM -0400, Peter Xu wrote: >

A bug of Monitor Chardev ?

We find a race during QEMU starting, which would case the QEMU process coredump. | | [1] create MON chardev | qemu_create_early_backends | chardev_init_func |

Re: [PATCH 2/2] migration: add vsock as data channel support

在 2020/8/12 17:52, Dr. David Alan Gilbert 写道: * Longpeng(Mike) (longpe...@huawei.com) wrote: The vsock channel is more widely use in some new features, for example, the Nitro/Enclave. It can also be used as the migration channel. Signed-off-by: Longpeng(Mike) OK; it might be worth adding

Re: [PATCH v16 QEMU 04/16] vfio: Add save and load functions for VFIO PCI devices

On 2020/3/25 5:09, Kirti Wankhede wrote: > These functions save and restore PCI device specific data - config > space of PCI device. > Tested save and restore with MSI and MSIX type. > > Signed-off-by: Kirti Wankhede > Reviewed-by: Neo Jia > --- > hw/vfio/pci.c | 163 >

Re: [RFC] cpus: avoid get stuck in pause_all_vcpus

On 2020/3/13 17:22, Paolo Bonzini wrote: > On 13/03/20 09:36, Longpeng (Mike, Cloud Infrastructure Service Product > Dept.) wrote: >>> You're right, do_vm_stop sets the runstate after pause_all_vcpus. We >>> can move that before and it should fix your case too. >>

Re: [RFC] cpus: avoid get stuck in pause_all_vcpus

On 2020/3/13 15:09, Paolo Bonzini wrote: > On 13/03/20 02:43, Longpeng (Mike, Cloud Infrastructure Service Product > Dept.) wrote: >>> diff --git a/cpus.c b/cpus.c >>> index b4f8b84b61..1eb7533a91 100644 >>> --- a/cpus.c >>> +++ b/cpus.c >>>

Re: [RFC] cpus: avoid get stuck in pause_all_vcpus

On 2020/3/12 23:28, Paolo Bonzini wrote: > On 10/03/20 10:14, Longpeng(Mike) wrote: >> From: Longpeng >> >> We find an issue when repeat reboot in guest during migration, it cause the >> migration thread never be waken up again. >> >> | >>

Re: [PATCH] vfio/pci: Use defined memcpy() behavior

On 2020/3/11 1:15, Alex Williamson wrote: > vfio_rom_read() relies on memcpy() doing the logically correct thing, > ie. safely copying zero bytes from a NULL pointer when rom_size is > zero, rather than the spec definition, which is undefined when the > source or target pointers are NULL.

Re: [PATCH RESEND 2/3] vhost: fix a null pointer reference of vhost_log

On 2020/3/10 13:57, Michael S. Tsirkin wrote: > On Mon, Feb 24, 2020 at 02:42:18PM +0800, Longpeng(Mike) wrote: >> From: Longpeng >> >> vhost_log_alloc() may fails and returned pointer of log is null. >> However there're two places derefernce the return pointer without >> check. >> >>

Re: [PATCH RESEND 2/3] vhost: fix a null pointer reference of vhost_log

Hi Michael, ping... On 2020/2/24 14:42, Longpeng(Mike) wrote: > From: Longpeng > > vhost_log_alloc() may fails and returned pointer of log is null. > However there're two places derefernce the return pointer without > check. > > Signed-off-by: Longpeng > --- > hw/virtio/vhost.c | 19

[Question] An issue when repeat reboot in guest during migration

Hi guys, We find an issue when repeat reboot in guest during migration, it cause the migration thread never be waken up again. | | main_loop_should_exit [BQL LOCK] | pause_all_vcpus | 1. set all cpus ->stop=true

Re: [PATCH RESEND 1/3] vfio/pci: fix a null pointer reference in vfio_rom_read

On 2020/2/25 0:04, Alex Williamson wrote: > On Mon, 24 Feb 2020 14:42:17 +0800 > "Longpeng(Mike)" wrote: > >> From: Longpeng >> >> vfio_pci_load_rom() maybe failed and then the vdev->rom is NULL in >> some situation (though I've not encountered yet), maybe we should >> avoid the VM abort. >>