Re: [libvirt] The results of lspci are inconsistent between vfio reset pci devices and reset devices by sysfs interafce

> > > Hi, > > > > > > I start a virtual machine with commandline: > > > /usr/libexec/qemu-kvm --enable-kvm -smp 8 -m 8192 -device > > > vfio-pci,host=:81:00.0 > > > > > > Then I pause the qemu process before executing the main_loop > > > function by > > gdb. > > > At this moment, lspci

Re: [libvirt] The results of lspci are inconsistent between vfio reset pci devices and reset devices by sysfs interafce

> > Hi, > > > > I start a virtual machine with commandline: > > /usr/libexec/qemu-kvm --enable-kvm -smp 8 -m 8192 -device > > vfio-pci,host=:81:00.0 > > > > Then I pause the qemu process before executing the main_loop function by > gdb. > > At this moment, lspci shows the regions are

[libvirt] The results of lspci are inconsistent between vfio reset pci devices and reset devices by sysfs interafce

Hi, I start a virtual machine with commandline: /usr/libexec/qemu-kvm --enable-kvm -smp 8 -m 8192 -device vfio-pci,host=:81:00.0 Then I pause the qemu process before executing the main_loop function by gdb. At this moment, lspci shows the regions are disabled like below: 81:00.0 3D

Re: [libvirt] [PATCH] virhostdev: Fix PCI devices are still attatched to stub driver bug

> $SUBJ: > > s/attatched/attached > > s/bug// > > On 08/31/2018 03:34 AM, Wu Zongyong wrote: > > So, first off - I believe there are two things going on in this one patch. > Even though there is "some relationship" between the issues, the libvirtd > restart is kind of a corner case, while the

Re: [libvirt] [Question]Libvirt doesn't care about qemu monitor event if fail to destroy qemu process

Thanks, Zongyong Wu > >> On 03/05/2018 12:43 PM, Cordius Wu wrote: > >>>>>> On 03/05/2018 03:20 AM, Wuzongyong (Euler Dept) wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> We

Re: [libvirt] [Question]Libvirt doesn't care about qemu monitor event if fail to destroy qemu process

> -Original Message- > From: Michal Privoznik [mailto:mpriv...@redhat.com] > Sent: Monday, March 05, 2018 5:27 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com>; libvir- > l...@redhat.com > Cc: Wanzongshun (Vincent) <wanzongs...@huawei.com>; weij

Re: [libvirt] [Question]Libvirt doesn't care about qemu monitor event if fail to destroy qemu process

Thanks, Zongyong Wu > -Original Message- > From: Michal Privoznik [mailto:mpriv...@redhat.com] > Sent: Monday, March 05, 2018 5:27 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com>; libvir- > l...@redhat.com > Cc: Wanzongshun (Vincent) <wanzong

[libvirt] [Question]Libvirt doesn't care about qemu monitor event if fail to destroy qemu process

Hi, We unregister qemu monitor after sending QEMU_PROCESS_EVENT_MONITOR_EOF to workerPool: static void qemuProcessHandleMonitorEOF(qemuMonitorPtr mon, virDomainObjPtr vm, void *opaque) { virQEMUDriverPtr driver = opaque;

[libvirt] [BUG]libvirt doesn't show the real state of vm

Hi, I notice that monitor.sock still exist when I send SIGKILL to qemu process by accident, and I can't find the qemu process through `ps -ef |grep qemu` command. Then I execute `virsh list --all`, libvirt just show that the vm still in running state. I can't find log "Received EOF on xxx"

Re: [libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

> On Thu, Feb 01, 2018 at 12:03:42PM +0000, Wuzongyong (Euler Dept) wrote: > > a mdev > > > > > > On Thu, Feb 01, 2018 at 09:08:59AM +0000, Wuzongyong (Euler Dept) > wrote: > > > > Hi, > > > > > > > > I solve this problem by sendin

Re: [libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

a mdev > > On Thu, Feb 01, 2018 at 09:08:59AM +, Wuzongyong (Euler Dept) wrote: > > Hi, > > > > I solve this problem by sending a CHANGE event to userspace after > creating the symbol link like sriov driver. > > > > diff --git a/drivers/vfio/m

Re: [libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

Could you please share what the commit id is ? Thanks, Zongyong Wu > -Original Message- > From: Erik Skultety [mailto:eskul...@redhat.com] > Sent: Thursday, February 01, 2018 4:09 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com> > Cc: Alex Williamson <al

Re: [libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

ot;); Is this patch ok? Thanks, Zongyong Wu > -Original Message- > From: Erik Skultety [mailto:eskul...@redhat.com] > Sent: Thursday, February 01, 2018 4:09 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com> > Cc: Alex Williamson <alex.william...@redhat.co

[libvirt] [Question] nodedev-list --cap return nothing after creating a mdev

Hi, I meet a problem that libvirt handle new mediated devices wrongly. Command `virsh nodedev-list -cap mdev` return none after I create a mdev, and the root cause I found is: // kernel code int mdev_device_create(struct kobject *kobj, struct device *dev, uuid_le uuid) { ... ret =

Re: [libvirt] [PATCH 07/15] nodedev: Introduce virNodeDeviceCapsListExport

> -Original Message- > From: libvir-list-boun...@redhat.com [mailto:libvir-list- > boun...@redhat.com] On Behalf Of Erik Skultety > Sent: Thursday, January 25, 2018 5:24 PM > To: libvir-list@redhat.com > Cc: Erik Skultety > Subject: [libvirt] [PATCH 07/15] nodedev:

Re: [libvirt] [PATCH 2/3] nodedev: update mdev_types caps before dumpxml

Would you push this two patches before release of 4.0.0? Thanks, Zongyong Wu > -Original Message- > From: Erik Skultety [mailto:eskul...@redhat.com] > Sent: Thursday, January 11, 2018 6:07 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com> > Cc: libvir-list@

Re: [libvirt] [PATCH 3/3] nodedev: update caps before invoking nodedev driver interfaces

anuary 11, 2018 6:16 PM > To: Wuzongyong (Euler Dept) <cordius...@huawei.com> > Cc: libvir-list@redhat.com; weijinfen <weijin...@huawei.com>; Wanzongshun > (Vincent) <wanzongs...@huawei.com> > Subject: Re: [PATCH 3/3] nodedev: update caps before invoking nodedev > d

[libvirt] [question]Why libvirt bind all devices with same vendor id and device id to vfio-pci driver, and only unbind devices used by VMs to original driver?

Hi, As the title says, I thought that it's a bit unreasonable and inconsistent to unbind devices assigned to VMs to original driver and leave other devices binding to vfio-pci driver. Why not to bind devices we need to vfio-pci driver instead of bind all devices with same type to vfio-pci

Re: [libvirt] Questions about function virPCIDeviceIsBehindSwitchLackingACS in virpci.c

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, September 21, 2017 10:57 AM > To: Laine Stump <la...@laine.org> > Cc: libvirt-l...@redhat.com; Wuzongyong (Euler Dept) > <cordius...@huawei.com>; Wan

Re: [libvirt] Questions about function virPCIDeviceIsBehindSwitchLackingACS in virpci.c

> -Original Message- > From: sendmail [mailto:justsendmailnothinge...@gmail.com] On Behalf Of > Laine Stump > Sent: Thursday, September 21, 2017 8:57 AM > To: libvirt-l...@redhat.com > Cc: Wuzongyong (Euler Dept) <cordius...@huawei.com>; Wanzongshun > (Vince

[libvirt] Questions about function virPCIDeviceIsBehindSwitchLackingACS in virpci.c

Hi, In function virPCIDeviceIsBehindSwitchLackingACS, I noticed that(line 8): 1if (virPCIDeviceGetParent(dev, ) < 0) 2return -1; 3if (!parent) { 4/* if we have no parent, and this is the root bus, ACS doesn't come 5 * into play since devices on the root bus can't

[libvirt] Questions about function virPCIDeviceIsBehindSwitchLackingACS in virpci.c

In function virPCIDeviceIsBehindSwitchLackingACS, I noticed that(line 8): 1if (virPCIDeviceGetParent(dev, ) < 0) 2return -1; 3if (!parent) { 4/* if we have no parent, and this is the root bus, ACS doesn't come 5 * into play since devices on the root bus can't P2P

[libvirt] Why not support additional machine args in XML such as max-ram-below-4g?

Since qemu support the arg -machine like that: -machine [type=]name[,prop[=value][,...]] So I'm inquisitive about why libvirt doesn't support specify the prop in xml ? So I can specify the qemu machine args like -max-raw-below-4g in xml, well, I mean not by specifying the -qemu-command-line in