diff options
Diffstat (limited to 'results/classifier/014/permissions')
| -rw-r--r-- | results/classifier/014/permissions/12360755 | 323 | ||||
| -rw-r--r-- | results/classifier/014/permissions/31349848 | 181 | ||||
| -rw-r--r-- | results/classifier/014/permissions/35170175 | 548 | ||||
| -rw-r--r-- | results/classifier/014/permissions/50773216 | 137 | ||||
| -rw-r--r-- | results/classifier/014/permissions/57231878 | 269 | ||||
| -rw-r--r-- | results/classifier/014/permissions/67821138 | 226 | ||||
| -rw-r--r-- | results/classifier/014/permissions/99674399 | 175 |
7 files changed, 0 insertions, 1859 deletions
diff --git a/results/classifier/014/permissions/12360755 b/results/classifier/014/permissions/12360755 deleted file mode 100644 index 02ac9dea6..000000000 --- a/results/classifier/014/permissions/12360755 +++ /dev/null @@ -1,323 +0,0 @@ -permissions: 0.930 -debug: 0.922 -user-level: 0.920 -semantic: 0.911 -device: 0.902 -register: 0.901 -graphic: 0.899 -performance: 0.895 -assembly: 0.893 -operating system: 0.890 -architecture: 0.885 -PID: 0.876 -arm: 0.875 -virtual: 0.870 -risc-v: 0.868 -peripherals: 0.857 -files: 0.851 -mistranslation: 0.844 -VMM: 0.842 -ppc: 0.840 -kernel: 0.830 -hypervisor: 0.829 -boot: 0.818 -vnc: 0.810 -socket: 0.805 -i386: 0.772 -KVM: 0.770 -network: 0.738 -TCG: 0.735 -alpha: 0.717 -x86: 0.656 - -[Qemu-devel] [BUG] virtio-net linux driver fails to probe on MIPS Malta since 'hw/virtio-pci: fix virtio behaviour' - -Hi, - -I've bisected the following failure of the virtio_net linux v4.10 driver -to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: - -virtio_net virtio0: virtio: device uses modern interface but does not have -VIRTIO_F_VERSION_1 -virtio_net: probe of virtio0 failed with error -22 - -To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). - -It appears that adding ",disable-modern=on,disable-legacy=off" to the -virtio-net -device makes it work again. - -I presume this should really just work out of the box. Any ideas why it -isn't? - -Cheers -James -signature.asc -Description: -Digital signature - -On 03/17/2017 11:57 PM, James Hogan wrote: -Hi, - -I've bisected the following failure of the virtio_net linux v4.10 driver -to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: - -virtio_net virtio0: virtio: device uses modern interface but does not have -VIRTIO_F_VERSION_1 -virtio_net: probe of virtio0 failed with error -22 - -To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). - -It appears that adding ",disable-modern=on,disable-legacy=off" to the -virtio-net -device makes it work again. - -I presume this should really just work out of the box. Any ideas why it -isn't? -Hi, - - -This is strange. This commit changes virtio devices from legacy to virtio -"transitional". -(your command line changes it to legacy) -Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU -side -there is nothing new. - -Michael, do you have any idea? - -Thanks, -Marcel -Cheers -James - -On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: -> -On 03/17/2017 11:57 PM, James Hogan wrote: -> -> Hi, -> -> -> -> I've bisected the following failure of the virtio_net linux v4.10 driver -> -> to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: -> -> -> -> virtio_net virtio0: virtio: device uses modern interface but does not have -> -> VIRTIO_F_VERSION_1 -> -> virtio_net: probe of virtio0 failed with error -22 -> -> -> -> To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). -> -> -> -> It appears that adding ",disable-modern=on,disable-legacy=off" to the -> -> virtio-net -device makes it work again. -> -> -> -> I presume this should really just work out of the box. Any ideas why it -> -> isn't? -> -> -> -> -Hi, -> -> -> -This is strange. This commit changes virtio devices from legacy to virtio -> -"transitional". -> -(your command line changes it to legacy) -> -Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU -> -side -> -there is nothing new. -> -> -Michael, do you have any idea? -> -> -Thanks, -> -Marcel -My guess would be firmware mishandling 64 bit BARs - we saw such -a case on sparc previously. As a result you are probably reading -all zeroes from features register or something like that. -Marcel, could you send a patch making the bar 32 bit? -If that helps we know what the issue is. - -> -> Cheers -> -> James -> -> - -On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote: -On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: -On 03/17/2017 11:57 PM, James Hogan wrote: -Hi, - -I've bisected the following failure of the virtio_net linux v4.10 driver -to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: - -virtio_net virtio0: virtio: device uses modern interface but does not have -VIRTIO_F_VERSION_1 -virtio_net: probe of virtio0 failed with error -22 - -To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). - -It appears that adding ",disable-modern=on,disable-legacy=off" to the -virtio-net -device makes it work again. - -I presume this should really just work out of the box. Any ideas why it -isn't? -Hi, - - -This is strange. This commit changes virtio devices from legacy to virtio -"transitional". -(your command line changes it to legacy) -Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU -side -there is nothing new. - -Michael, do you have any idea? - -Thanks, -Marcel -My guess would be firmware mishandling 64 bit BARs - we saw such -a case on sparc previously. As a result you are probably reading -all zeroes from features register or something like that. -Marcel, could you send a patch making the bar 32 bit? -If that helps we know what the issue is. -Sure, - -Thanks, -Marcel -Cheers -James - -On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote: -On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: -On 03/17/2017 11:57 PM, James Hogan wrote: -Hi, - -I've bisected the following failure of the virtio_net linux v4.10 driver -to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: - -virtio_net virtio0: virtio: device uses modern interface but does not have -VIRTIO_F_VERSION_1 -virtio_net: probe of virtio0 failed with error -22 - -To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). - -It appears that adding ",disable-modern=on,disable-legacy=off" to the -virtio-net -device makes it work again. - -I presume this should really just work out of the box. Any ideas why it -isn't? -Hi, - - -This is strange. This commit changes virtio devices from legacy to virtio -"transitional". -(your command line changes it to legacy) -Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU -side -there is nothing new. - -Michael, do you have any idea? - -Thanks, -Marcel -My guess would be firmware mishandling 64 bit BARs - we saw such -a case on sparc previously. As a result you are probably reading -all zeroes from features register or something like that. -Marcel, could you send a patch making the bar 32 bit? -If that helps we know what the issue is. -Hi James, - -Can you please check if the below patch fixes the problem? -Please note it is not a solution. - -diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c -index f9b7244..5b4d429 100644 ---- a/hw/virtio/virtio-pci.c -+++ b/hw/virtio/virtio-pci.c -@@ -1671,9 +1671,7 @@ static void virtio_pci_device_plugged(DeviceState *d, -Error **errp) - } - - pci_register_bar(&proxy->pci_dev, proxy->modern_mem_bar_idx, -- PCI_BASE_ADDRESS_SPACE_MEMORY | -- PCI_BASE_ADDRESS_MEM_PREFETCH | -- PCI_BASE_ADDRESS_MEM_TYPE_64, -+ PCI_BASE_ADDRESS_SPACE_MEMORY, - &proxy->modern_bar); - - proxy->config_cap = virtio_pci_add_mem_cap(proxy, &cfg.cap); - - -Thanks, -Marcel - -Hi Marcel, - -On Tue, Mar 21, 2017 at 04:16:58PM +0200, Marcel Apfelbaum wrote: -> -Can you please check if the below patch fixes the problem? -> -Please note it is not a solution. -> -> -diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c -> -index f9b7244..5b4d429 100644 -> ---- a/hw/virtio/virtio-pci.c -> -+++ b/hw/virtio/virtio-pci.c -> -@@ -1671,9 +1671,7 @@ static void virtio_pci_device_plugged(DeviceState *d, -> -Error **errp) -> -} -> -> -pci_register_bar(&proxy->pci_dev, proxy->modern_mem_bar_idx, -> -- PCI_BASE_ADDRESS_SPACE_MEMORY | -> -- PCI_BASE_ADDRESS_MEM_PREFETCH | -> -- PCI_BASE_ADDRESS_MEM_TYPE_64, -> -+ PCI_BASE_ADDRESS_SPACE_MEMORY, -> -&proxy->modern_bar); -> -> -proxy->config_cap = virtio_pci_add_mem_cap(proxy, &cfg.cap); -Sorry for the delay trying this, I was away last week. - -No, it doesn't seem to make any difference. - -Thanks -James -signature.asc -Description: -Digital signature - diff --git a/results/classifier/014/permissions/31349848 b/results/classifier/014/permissions/31349848 deleted file mode 100644 index 760572b3c..000000000 --- a/results/classifier/014/permissions/31349848 +++ /dev/null @@ -1,181 +0,0 @@ -permissions: 0.908 -PID: 0.903 -device: 0.881 -graphic: 0.876 -register: 0.870 -virtual: 0.869 -risc-v: 0.865 -performance: 0.864 -assembly: 0.855 -vnc: 0.854 -arm: 0.852 -semantic: 0.846 -socket: 0.846 -user-level: 0.845 -architecture: 0.845 -alpha: 0.837 -operating system: 0.830 -TCG: 0.828 -KVM: 0.827 -debug: 0.826 -files: 0.820 -boot: 0.815 -hypervisor: 0.815 -x86: 0.815 -kernel: 0.809 -VMM: 0.801 -ppc: 0.792 -i386: 0.782 -mistranslation: 0.781 -peripherals: 0.770 -network: 0.769 - -[Qemu-devel] [BUG] qemu stuck when detach host-usb device - -Description of problem: -The guest has a host-usb device(Kingston Technology DataTraveler 100 G3/G4/SE9 -G2), which is attached -to xhci controller(on host). Qemu will stuck if I detach it from guest. - -How reproducible: -100% - -Steps to Reproduce: -1. Use usb stick to copy files in guest , make it busy working. -2. virsh detach-device vm_name usb.xml - -Then qemu will stuck for 20s, I found this is because libusb_release_interface -block for 20s. -Dmesg prints: - -[35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. -[35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. -[35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. -[35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. - -Is this a hardware error or software's bug? - -On Tue, Nov 27, 2018 at 01:26:24AM +0000, linzhecheng wrote: -> -Description of problem: -> -The guest has a host-usb device(Kingston Technology DataTraveler 100 -> -G3/G4/SE9 G2), which is attached -> -to xhci controller(on host). Qemu will stuck if I detach it from guest. -> -> -How reproducible: -> -100% -> -> -Steps to Reproduce: -> -1. Use usb stick to copy files in guest , make it busy working. -> -2. virsh detach-device vm_name usb.xml -> -> -Then qemu will stuck for 20s, I found this is because -> -libusb_release_interface block for 20s. -> -Dmesg prints: -> -> -[35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. -> -[35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. -> -[35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. -> -[35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. -> -> -Is this a hardware error or software's bug? -I'd guess software error, could be is libusb or (host) linux kernel. -Cc'ing libusb-devel. - -cheers, - Gerd - -> ------Original Message----- -> -From: Gerd Hoffmann [ -mailto:address@hidden -> -Sent: Tuesday, November 27, 2018 2:09 PM -> -To: linzhecheng <address@hidden> -> -Cc: address@hidden; wangxin (U) <address@hidden>; -> -Zhoujian (jay) <address@hidden>; address@hidden -> -Subject: Re: [Qemu-devel] [BUG] qemu stuck when detach host-usb device -> -> -On Tue, Nov 27, 2018 at 01:26:24AM +0000, linzhecheng wrote: -> -> Description of problem: -> -> The guest has a host-usb device(Kingston Technology DataTraveler 100 -> -> G3/G4/SE9 G2), which is attached to xhci controller(on host). Qemu will -> -> stuck -> -if I detach it from guest. -> -> -> -> How reproducible: -> -> 100% -> -> -> -> Steps to Reproduce: -> -> 1. Use usb stick to copy files in guest , make it busy working. -> -> 2. virsh detach-device vm_name usb.xml -> -> -> -> Then qemu will stuck for 20s, I found this is because -> -> libusb_release_interface -> -block for 20s. -> -> Dmesg prints: -> -> -> -> [35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. -> -> [35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. -> -> [35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. -> -> [35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. -> -> -> -> Is this a hardware error or software's bug? -> -> -I'd guess software error, could be is libusb or (host) linux kernel. -> -Cc'ing libusb-devel. -Perhaps it's usb driver's bug. Could you also reproduce it? -> -> -cheers, -> -Gerd - diff --git a/results/classifier/014/permissions/35170175 b/results/classifier/014/permissions/35170175 deleted file mode 100644 index 569f640c9..000000000 --- a/results/classifier/014/permissions/35170175 +++ /dev/null @@ -1,548 +0,0 @@ -permissions: 0.870 -graphic: 0.844 -debug: 0.830 -virtual: 0.820 -performance: 0.818 -register: 0.808 -semantic: 0.798 -device: 0.787 -architecture: 0.783 -assembly: 0.767 -arm: 0.754 -operating system: 0.738 -boot: 0.719 -KVM: 0.709 -files: 0.706 -PID: 0.699 -x86: 0.698 -alpha: 0.685 -peripherals: 0.685 -socket: 0.681 -kernel: 0.679 -risc-v: 0.678 -user-level: 0.671 -network: 0.666 -hypervisor: 0.656 -mistranslation: 0.641 -vnc: 0.633 -TCG: 0.624 -VMM: 0.618 -ppc: 0.585 -i386: 0.545 - -[Qemu-devel] [BUG] QEMU crashes with dpdk virtio pmd - -Qemu crashes, with pre-condition: -vm xml config with multiqueue, and the vm's driver virtio-net support -multi-queue - -reproduce steps: -i. start dpdk testpmd in VM with the virtio nic -ii. stop testpmd -iii. reboot the VM - -This commit "f9d6dbf0 remove virtio queues if the guest doesn't support -multiqueue" is introduced. - -Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) -VM DPDK version: DPDK-1.6.1 - -Call Trace: -#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 -#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 -#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 -#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 -#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 -#5 0x00007f6088fea32c in iter_remove_or_steal () from -/usr/lib64/libglib-2.0.so.0 -#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at -qom/object.c:410 -#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 -#8 object_unref (address@hidden) at qom/object.c:903 -#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at -git/qemu/exec.c:1154 -#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 -#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 -#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 - -Call Trace: -#0 0x00007fdccaeb9790 in ?? () -#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at -qom/object.c:405 -#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 -#3 object_unref (address@hidden) at qom/object.c:903 -#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at -git/qemu/exec.c:1154 -#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 -#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 -#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 - -The q->tx_bh will free in virtio_net_del_queue() function, when remove virtio -queues -if the guest doesn't support multiqueue. But it might be still referenced by -others (eg . virtio_net_set_status()), -which need so set NULL. - -diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c -index 7d091c9..98bd683 100644 ---- a/hw/net/virtio-net.c -+++ b/hw/net/virtio-net.c -@@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, int index) - if (q->tx_timer) { - timer_del(q->tx_timer); - timer_free(q->tx_timer); -+ q->tx_timer = NULL; - } else { - qemu_bh_delete(q->tx_bh); -+ q->tx_bh = NULL; - } -+ q->tx_waiting = 0; - virtio_del_queue(vdev, index * 2 + 1); - } - -From: wangyunjian -Sent: Monday, April 24, 2017 6:10 PM -To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason Wang' -<address@hidden> -Cc: wangyunjian <address@hidden>; caihe <address@hidden> -Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd - -Qemu crashes, with pre-condition: -vm xml config with multiqueue, and the vm's driver virtio-net support -multi-queue - -reproduce steps: -i. start dpdk testpmd in VM with the virtio nic -ii. stop testpmd -iii. reboot the VM - -This commit "f9d6dbf0 remove virtio queues if the guest doesn't support -multiqueue" is introduced. - -Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) -VM DPDK version:  DPDK-1.6.1 - -Call Trace: -#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 -#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 -#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 -#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 -#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 -#5 0x00007f6088fea32c in iter_remove_or_steal () from -/usr/lib64/libglib-2.0.so.0 -#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at -qom/object.c:410 -#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 -#8 object_unref (address@hidden) at qom/object.c:903 -#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at -git/qemu/exec.c:1154 -#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 -#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 -#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 - -Call Trace: -#0 0x00007fdccaeb9790 in ?? () -#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at -qom/object.c:405 -#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 -#3 object_unref (address@hidden) at qom/object.c:903 -#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at -git/qemu/exec.c:1154 -#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 -#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 -#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 - -On 2017å¹´04æ25æ¥ 19:37, wangyunjian wrote: -The q->tx_bh will free in virtio_net_del_queue() function, when remove virtio -queues -if the guest doesn't support multiqueue. But it might be still referenced by -others (eg . virtio_net_set_status()), -which need so set NULL. - -diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c -index 7d091c9..98bd683 100644 ---- a/hw/net/virtio-net.c -+++ b/hw/net/virtio-net.c -@@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, int index) - if (q->tx_timer) { - timer_del(q->tx_timer); - timer_free(q->tx_timer); -+ q->tx_timer = NULL; - } else { - qemu_bh_delete(q->tx_bh); -+ q->tx_bh = NULL; - } -+ q->tx_waiting = 0; - virtio_del_queue(vdev, index * 2 + 1); - } -Thanks a lot for the fix. - -Two questions: -- If virtio_net_set_status() is the only function that may access tx_bh, -it looks like setting tx_waiting to zero is sufficient? -- Can you post a formal patch for this? - -Thanks -From: wangyunjian -Sent: Monday, April 24, 2017 6:10 PM -To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason Wang' -<address@hidden> -Cc: wangyunjian <address@hidden>; caihe <address@hidden> -Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd - -Qemu crashes, with pre-condition: -vm xml config with multiqueue, and the vm's driver virtio-net support -multi-queue - -reproduce steps: -i. start dpdk testpmd in VM with the virtio nic -ii. stop testpmd -iii. reboot the VM - -This commit "f9d6dbf0 remove virtio queues if the guest doesn't support -multiqueue" is introduced. - -Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) -VM DPDK version: DPDK-1.6.1 - -Call Trace: -#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 -#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 -#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 -#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 -#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 -#5 0x00007f6088fea32c in iter_remove_or_steal () from -/usr/lib64/libglib-2.0.so.0 -#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at -qom/object.c:410 -#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 -#8 object_unref (address@hidden) at qom/object.c:903 -#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at -git/qemu/exec.c:1154 -#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 -#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 -#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 - -Call Trace: -#0 0x00007fdccaeb9790 in ?? () -#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at -qom/object.c:405 -#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 -#3 object_unref (address@hidden) at qom/object.c:903 -#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at -git/qemu/exec.c:1154 -#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 -#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 -#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at -util/rcu.c:272 -#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 - -CCing Paolo and Stefan, since it has a relationship with bh in Qemu. - -> ------Original Message----- -> -From: Jason Wang [ -mailto:address@hidden -> -> -> -On 2017å¹´04æ25æ¥ 19:37, wangyunjian wrote: -> -> The q->tx_bh will free in virtio_net_del_queue() function, when remove -> -> virtio -> -queues -> -> if the guest doesn't support multiqueue. But it might be still referenced by -> -others (eg . virtio_net_set_status()), -> -> which need so set NULL. -> -> -> -> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c -> -> index 7d091c9..98bd683 100644 -> -> --- a/hw/net/virtio-net.c -> -> +++ b/hw/net/virtio-net.c -> -> @@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, -> -int index) -> -> if (q->tx_timer) { -> -> timer_del(q->tx_timer); -> -> timer_free(q->tx_timer); -> -> + q->tx_timer = NULL; -> -> } else { -> -> qemu_bh_delete(q->tx_bh); -> -> + q->tx_bh = NULL; -> -> } -> -> + q->tx_waiting = 0; -> -> virtio_del_queue(vdev, index * 2 + 1); -> -> } -> -> -Thanks a lot for the fix. -> -> -Two questions: -> -> -- If virtio_net_set_status() is the only function that may access tx_bh, -> -it looks like setting tx_waiting to zero is sufficient? -Currently yes, but we don't assure that it works for all scenarios, so -we set the tx_bh and tx_timer to NULL to avoid to possibly access wild pointer, -which is the common method for usage of bh in Qemu. - -I have another question about the root cause of this issure. - -This below trace is the path of setting tx_waiting to one in -virtio_net_handle_tx_bh() : - -Breakpoint 1, virtio_net_handle_tx_bh (vdev=0x0, vq=0x7f335ad13900) at -/data/wyj/git/qemu/hw/net/virtio-net.c:1398 -1398 { -(gdb) bt -#0 virtio_net_handle_tx_bh (vdev=0x0, vq=0x7f335ad13900) at -/data/wyj/git/qemu/hw/net/virtio-net.c:1398 -#1 0x00007f3357bddf9c in virtio_bus_set_host_notifier (bus=<optimized out>, -address@hidden, address@hidden) at hw/virtio/virtio-bus.c:297 -#2 0x00007f3357a0055d in vhost_dev_disable_notifiers (address@hidden, -address@hidden) at /data/wyj/git/qemu/hw/virtio/vhost.c:1422 -#3 0x00007f33579e3373 in vhost_net_stop_one (net=0x7f335ad84dc0, -dev=0x7f335c6f5f90) at /data/wyj/git/qemu/hw/net/vhost_net.c:289 -#4 0x00007f33579e385b in vhost_net_stop (address@hidden, ncs=<optimized out>, -address@hidden) at /data/wyj/git/qemu/hw/net/vhost_net.c:367 -#5 0x00007f33579e15de in virtio_net_vhost_status (status=<optimized out>, -n=0x7f335c6f5f90) at /data/wyj/git/qemu/hw/net/virtio-net.c:176 -#6 virtio_net_set_status (vdev=0x7f335c6f5f90, status=0 '\000') at -/data/wyj/git/qemu/hw/net/virtio-net.c:250 -#7 0x00007f33579f8dc6 in virtio_set_status (address@hidden, address@hidden -'\000') at /data/wyj/git/qemu/hw/virtio/virtio.c:1146 -#8 0x00007f3357bdd3cc in virtio_ioport_write (val=0, addr=18, -opaque=0x7f335c6eda80) at hw/virtio/virtio-pci.c:387 -#9 virtio_pci_config_write (opaque=0x7f335c6eda80, addr=18, val=0, -size=<optimized out>) at hw/virtio/virtio-pci.c:511 -#10 0x00007f33579b2155 in memory_region_write_accessor (mr=0x7f335c6ee470, -addr=18, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized -out>, attrs=...) at /data/wyj/git/qemu/memory.c:526 -#11 0x00007f33579af2e9 in access_with_adjusted_size (address@hidden, -address@hidden, address@hidden, access_size_min=<optimized out>, -access_size_max=<optimized out>, address@hidden - 0x7f33579b20f0 <memory_region_write_accessor>, address@hidden, -address@hidden) at /data/wyj/git/qemu/memory.c:592 -#12 0x00007f33579b2e15 in memory_region_dispatch_write (address@hidden, -address@hidden, data=0, address@hidden, address@hidden) at -/data/wyj/git/qemu/memory.c:1319 -#13 0x00007f335796cd93 in address_space_write_continue (mr=0x7f335c6ee470, l=1, -addr1=18, len=1, buf=0x7f335773d000 "", attrs=..., addr=49170, -as=0x7f3358317060 <address_space_io>) at /data/wyj/git/qemu/exec.c:2834 -#14 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., -buf=<optimized out>, len=<optimized out>) at /data/wyj/git/qemu/exec.c:2879 -#15 0x00007f335796d3ad in address_space_rw (as=<optimized out>, address@hidden, -attrs=..., address@hidden, buf=<optimized out>, address@hidden, address@hidden) -at /data/wyj/git/qemu/exec.c:2981 -#16 0x00007f33579ae226 in kvm_handle_io (count=1, size=1, direction=<optimized -out>, data=<optimized out>, attrs=..., port=49170) at -/data/wyj/git/qemu/kvm-all.c:1803 -#17 kvm_cpu_exec (address@hidden) at /data/wyj/git/qemu/kvm-all.c:2032 -#18 0x00007f335799b632 in qemu_kvm_cpu_thread_fn (arg=0x7f335ae82070) at -/data/wyj/git/qemu/cpus.c:1118 -#19 0x00007f3352983dc5 in start_thread () from /usr/lib64/libpthread.so.0 -#20 0x00007f335113571d in clone () from /usr/lib64/libc.so.6 - -It calls qemu_bh_schedule(q->tx_bh) at the bottom of virtio_net_handle_tx_bh(), -I don't know why virtio_net_tx_bh() doesn't be invoked, so that the -q->tx_waiting is not zero. -[ps: we added logs in virtio_net_tx_bh() to verify that] - -Some other information: - -It won't crash if we don't use vhost-net. - - -Thanks, --Gonglei - -> -- Can you post a formal patch for this? -> -> -Thanks -> -> -> From: wangyunjian -> -> Sent: Monday, April 24, 2017 6:10 PM -> -> To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason -> -Wang' <address@hidden> -> -> Cc: wangyunjian <address@hidden>; caihe <address@hidden> -> -> Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd -> -> -> -> Qemu crashes, with pre-condition: -> -> vm xml config with multiqueue, and the vm's driver virtio-net support -> -multi-queue -> -> -> -> reproduce steps: -> -> i. start dpdk testpmd in VM with the virtio nic -> -> ii. stop testpmd -> -> iii. reboot the VM -> -> -> -> This commit "f9d6dbf0 remove virtio queues if the guest doesn't support -> -multiqueue" is introduced. -> -> -> -> Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) -> -> VM DPDK version: DPDK-1.6.1 -> -> -> -> Call Trace: -> -> #0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 -> -> #1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 -> -> #2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 -> -> #3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 -> -> #4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 -> -> #5 0x00007f6088fea32c in iter_remove_or_steal () from -> -/usr/lib64/libglib-2.0.so.0 -> -> #6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) -> -at qom/object.c:410 -> -> #7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 -> -> #8 object_unref (address@hidden) at qom/object.c:903 -> -> #9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at -> -git/qemu/exec.c:1154 -> -> #10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 -> -> #11 address_space_dispatch_free (d=0x7f6090b72b90) at -> -git/qemu/exec.c:2514 -> -> #12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at -> -util/rcu.c:272 -> -> #13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -> -> #14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 -> -> -> -> Call Trace: -> -> #0 0x00007fdccaeb9790 in ?? () -> -> #1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at -> -qom/object.c:405 -> -> #2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 -> -> #3 object_unref (address@hidden) at qom/object.c:903 -> -> #4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at -> -git/qemu/exec.c:1154 -> -> #5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 -> -> #6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at -> -git/qemu/exec.c:2514 -> -> #7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at -> -util/rcu.c:272 -> -> #8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 -> -> #9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 -> -> -> -> - -On 25/04/2017 14:02, Jason Wang wrote: -> -> -Thanks a lot for the fix. -> -> -Two questions: -> -> -- If virtio_net_set_status() is the only function that may access tx_bh, -> -it looks like setting tx_waiting to zero is sufficient? -I think clearing tx_bh is better anyway, as leaving a dangling pointer -is not very hygienic. - -Paolo - -> -- Can you post a formal patch for this? - diff --git a/results/classifier/014/permissions/50773216 b/results/classifier/014/permissions/50773216 deleted file mode 100644 index b771cad5b..000000000 --- a/results/classifier/014/permissions/50773216 +++ /dev/null @@ -1,137 +0,0 @@ -permissions: 0.813 -risc-v: 0.813 -operating system: 0.806 -kernel: 0.791 -architecture: 0.788 -hypervisor: 0.768 -device: 0.764 -ppc: 0.760 -arm: 0.758 -register: 0.751 -peripherals: 0.729 -graphic: 0.723 -user-level: 0.713 -semantic: 0.669 -files: 0.666 -debug: 0.659 -vnc: 0.656 -socket: 0.652 -mistranslation: 0.652 -boot: 0.637 -PID: 0.636 -VMM: 0.633 -performance: 0.628 -assembly: 0.623 -alpha: 0.618 -network: 0.606 -KVM: 0.601 -TCG: 0.571 -virtual: 0.560 -i386: 0.546 -x86: 0.510 - -[Qemu-devel] Can I have someone's feedback on [bug 1809075] Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel - -Hi everyone. -Can I please have someone's feedback on this bug? -https://bugs.launchpad.net/qemu/+bug/1809075 -Briefly, guest OS loses characters sent to it via vnc. And I spot the -bug in relation to ps2 driver. -I'm thinking of possible fixes and I might want to use a memory barrier. -But I would really like to have some suggestion from a qemu developer -first. For example, can we brutally drop capslock LED key events in ps2 -queue? -It is actually relevant to openQA, an automated QA tool for openSUSE. -And this bug blocks a few test cases for us. -Thank you in advance! - -Kind regards, -Gao Zhiyuan - -Cc'ing Marc-André & Gerd. - -On 12/19/18 10:31 AM, Gao Zhiyuan wrote: -> -Hi everyone. -> -> -Can I please have someone's feedback on this bug? -> -https://bugs.launchpad.net/qemu/+bug/1809075 -> -Briefly, guest OS loses characters sent to it via vnc. And I spot the -> -bug in relation to ps2 driver. -> -> -I'm thinking of possible fixes and I might want to use a memory barrier. -> -But I would really like to have some suggestion from a qemu developer -> -first. For example, can we brutally drop capslock LED key events in ps2 -> -queue? -> -> -It is actually relevant to openQA, an automated QA tool for openSUSE. -> -And this bug blocks a few test cases for us. -> -> -Thank you in advance! -> -> -Kind regards, -> -Gao Zhiyuan -> - -On Thu, Jan 03, 2019 at 12:05:54PM +0100, Philippe Mathieu-Daudé wrote: -> -Cc'ing Marc-André & Gerd. -> -> -On 12/19/18 10:31 AM, Gao Zhiyuan wrote: -> -> Hi everyone. -> -> -> -> Can I please have someone's feedback on this bug? -> -> -https://bugs.launchpad.net/qemu/+bug/1809075 -> -> Briefly, guest OS loses characters sent to it via vnc. And I spot the -> -> bug in relation to ps2 driver. -> -> -> -> I'm thinking of possible fixes and I might want to use a memory barrier. -> -> But I would really like to have some suggestion from a qemu developer -> -> first. For example, can we brutally drop capslock LED key events in ps2 -> -> queue? -There is no "capslock LED key event". 0xfa is KBD_REPLY_ACK, and the -device queues it in response to guest port writes. Yes, the ack can -race with actual key events. But IMO that isn't a bug in qemu. - -Probably the linux kernel just throws away everything until it got the -ack for the port write, and that way the key event gets lost. On -physical hardware you will not notice because it is next to impossible -to type fast enough to hit the race window. - -So, go fix the kernel. - -Alternatively fix vncdotool to send uppercase letters properly with -shift key pressed. Then qemu wouldn't generate capslock key events -(that happens because qemu thinks guest and host capslock state is out -of sync) and the guests's capslock led update request wouldn't get into -the way. - -cheers, - Gerd - diff --git a/results/classifier/014/permissions/57231878 b/results/classifier/014/permissions/57231878 deleted file mode 100644 index deded8acc..000000000 --- a/results/classifier/014/permissions/57231878 +++ /dev/null @@ -1,269 +0,0 @@ -permissions: 0.856 -virtual: 0.832 -device: 0.818 -operating system: 0.786 -register: 0.783 -semantic: 0.774 -graphic: 0.751 -assembly: 0.745 -debug: 0.732 -kernel: 0.725 -mistranslation: 0.719 -arm: 0.713 -x86: 0.713 -KVM: 0.708 -user-level: 0.707 -hypervisor: 0.691 -TCG: 0.689 -ppc: 0.684 -PID: 0.684 -architecture: 0.678 -network: 0.659 -performance: 0.644 -vnc: 0.640 -peripherals: 0.624 -socket: 0.624 -VMM: 0.613 -risc-v: 0.611 -boot: 0.609 -files: 0.587 -alpha: 0.523 -i386: 0.318 - -[Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. - -Hello all, -I wanted to submit a bug report in the tracker, but it seem to require -an Ubuntu One account, which I'm having trouble with, so I'll just -give it here and hopefully somebody can make use of it. The issue -seems to be in an experimental format, so it's likely not very -consequential anyway. - -For the sake of anyone else simply googling for a workaround, I'll -just paste in the (cleaned up) brief IRC conversation about my issue -from the official channel: -<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux, -Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine -(FreeBSD-11.1). The VM always aborts at the same point in the -installation (downloading 'ports.tgz') with the following error -message: -"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197: -qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. -zsh: abort (core dumped) qemu-system-x86_64 -smp 2 -m 4096 --enable-kvm -hda freebsd/freebsd.qed -devic" -The commands I ran to create the machine are as follows: -"qemu-img create -f qed freebsd/freebsd.qed 16G" -"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda -freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0 --cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d" -I tried adding logging options with the -d flag, but I didn't get -anything that seemed relevant, since I'm not sure what to look for. -<stsquad> ohh what's a qed device? -<stsquad> quy: it might be a workaround to use a qcow2 image for now -<stsquad> ahh the wiki has a statement "It is not recommended to use -QED for any new images. " -<danpb> 'qed' was an experimental disk image format created by IBM -before qcow2 v3 came along -<danpb> honestly nothing should ever use QED these days -<danpb> the good ideas from QED became qcow2v3 -<stsquad> danpb: sounds like we should put a warning on the option to -remind users of that fact -<danpb> quy: sounds like qed driver is simply broken - please do file -a bug against qemu bug tracker -<danpb> quy: but you should also really switch to qcow2 -<quy> I see; some people need to update their wikis then. I don't -remember where which guide I read when I first learned what little -QEMU I know, but I remember it specifically remember it saying QED was -the newest and most optimal format. -<stsquad> quy: we can only be responsible for our own wiki I'm afraid... -<danpb> if you remember where you saw that please let us know so we -can try to get it fixed -<quy> Thank you very much for the info; I will switch to QCOW. -Unfortunately, I'm not sure if I will be able to file any bug reports -in the tracker as I can't seem to log Launchpad, which it seems to -require. -<danpb> quy: an email to the mailing list would suffice too if you -can't deal with launchpad -<danpb> kwolf: ^^^ in case you're interested in possible QED -assertions from 2.12 - -If any more info is needed, feel free to email me; I'm not actually -subscribed to this list though. -Thank you, -Quytelda Kahja - -CC Qemu Block; looks like QED is a bit busted. - -On 06/27/2018 10:25 AM, Quytelda Kahja wrote: -> -Hello all, -> -I wanted to submit a bug report in the tracker, but it seem to require -> -an Ubuntu One account, which I'm having trouble with, so I'll just -> -give it here and hopefully somebody can make use of it. The issue -> -seems to be in an experimental format, so it's likely not very -> -consequential anyway. -> -> -For the sake of anyone else simply googling for a workaround, I'll -> -just paste in the (cleaned up) brief IRC conversation about my issue -> -from the official channel: -> -<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux, -> -Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine -> -(FreeBSD-11.1). The VM always aborts at the same point in the -> -installation (downloading 'ports.tgz') with the following error -> -message: -> -"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197: -> -qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. -> -zsh: abort (core dumped) qemu-system-x86_64 -smp 2 -m 4096 -> --enable-kvm -hda freebsd/freebsd.qed -devic" -> -The commands I ran to create the machine are as follows: -> -"qemu-img create -f qed freebsd/freebsd.qed 16G" -> -"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda -> -freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0 -> --cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d" -> -I tried adding logging options with the -d flag, but I didn't get -> -anything that seemed relevant, since I'm not sure what to look for. -> -<stsquad> ohh what's a qed device? -> -<stsquad> quy: it might be a workaround to use a qcow2 image for now -> -<stsquad> ahh the wiki has a statement "It is not recommended to use -> -QED for any new images. " -> -<danpb> 'qed' was an experimental disk image format created by IBM -> -before qcow2 v3 came along -> -<danpb> honestly nothing should ever use QED these days -> -<danpb> the good ideas from QED became qcow2v3 -> -<stsquad> danpb: sounds like we should put a warning on the option to -> -remind users of that fact -> -<danpb> quy: sounds like qed driver is simply broken - please do file -> -a bug against qemu bug tracker -> -<danpb> quy: but you should also really switch to qcow2 -> -<quy> I see; some people need to update their wikis then. I don't -> -remember where which guide I read when I first learned what little -> -QEMU I know, but I remember it specifically remember it saying QED was -> -the newest and most optimal format. -> -<stsquad> quy: we can only be responsible for our own wiki I'm afraid... -> -<danpb> if you remember where you saw that please let us know so we -> -can try to get it fixed -> -<quy> Thank you very much for the info; I will switch to QCOW. -> -Unfortunately, I'm not sure if I will be able to file any bug reports -> -in the tracker as I can't seem to log Launchpad, which it seems to -> -require. -> -<danpb> quy: an email to the mailing list would suffice too if you -> -can't deal with launchpad -> -<danpb> kwolf: ^^^ in case you're interested in possible QED -> -assertions from 2.12 -> -> -If any more info is needed, feel free to email me; I'm not actually -> -subscribed to this list though. -> -Thank you, -> -Quytelda Kahja -> - -On 06/29/2018 03:07 PM, John Snow wrote: -CC Qemu Block; looks like QED is a bit busted. - -On 06/27/2018 10:25 AM, Quytelda Kahja wrote: -Hello all, -I wanted to submit a bug report in the tracker, but it seem to require -an Ubuntu One account, which I'm having trouble with, so I'll just -give it here and hopefully somebody can make use of it. The issue -seems to be in an experimental format, so it's likely not very -consequential anyway. -Analysis in another thread may be relevant: -https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08963.html --- -Eric Blake, Principal Software Engineer -Red Hat, Inc. +1-919-301-3266 -Virtualization: qemu.org | libvirt.org - -Am 29.06.2018 um 22:16 hat Eric Blake geschrieben: -> -On 06/29/2018 03:07 PM, John Snow wrote: -> -> CC Qemu Block; looks like QED is a bit busted. -> -> -> -> On 06/27/2018 10:25 AM, Quytelda Kahja wrote: -> -> > Hello all, -> -> > I wanted to submit a bug report in the tracker, but it seem to require -> -> > an Ubuntu One account, which I'm having trouble with, so I'll just -> -> > give it here and hopefully somebody can make use of it. The issue -> -> > seems to be in an experimental format, so it's likely not very -> -> > consequential anyway. -> -> -Analysis in another thread may be relevant: -> -> -https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08963.html -The assertion there was: - -qemu-system-x86_64: block.c:3434: bdrv_replace_node: Assertion -`!atomic_read(&to->in_flight)' failed. - -Which quite clearly pointed to a drain bug. This one, however, doesn't -seem to be related to drain, so I think it's probably a different bug. - -Kevin - diff --git a/results/classifier/014/permissions/67821138 b/results/classifier/014/permissions/67821138 deleted file mode 100644 index 01eec2a10..000000000 --- a/results/classifier/014/permissions/67821138 +++ /dev/null @@ -1,226 +0,0 @@ -architecture: 0.939 -permissions: 0.935 -user-level: 0.917 -device: 0.916 -assembly: 0.915 -risc-v: 0.914 -PID: 0.909 -register: 0.891 -boot: 0.881 -arm: 0.872 -debug: 0.870 -kernel: 0.865 -performance: 0.845 -semantic: 0.843 -alpha: 0.838 -peripherals: 0.836 -graphic: 0.826 -files: 0.824 -KVM: 0.822 -virtual: 0.799 -mistranslation: 0.768 -ppc: 0.745 -vnc: 0.734 -network: 0.718 -hypervisor: 0.702 -socket: 0.699 -operating system: 0.687 -x86: 0.540 -TCG: 0.498 -i386: 0.432 -VMM: 0.407 - -[BUG, RFC] Base node is in RW after making external snapshot - -Hi everyone, - -When making an external snapshot, we end up in a situation when 2 block -graph nodes related to the same image file (format and storage nodes) -have different RO flags set on them. - -E.g. - -# ls -la /proc/PID/fd -lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd - -# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' ---pretty | egrep '"node-name"|"ro"' - "ro": false, - "node-name": "libvirt-1-format", - "ro": false, - "node-name": "libvirt-1-storage", - -# virsh snapshot-create-as VM --name snap --disk-only -Domain snapshot snap created - -# ls -la /proc/PID/fd -lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd -lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap - -# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' ---pretty | egrep '"node-name"|"ro"' - "ro": false, - "node-name": "libvirt-2-format", - "ro": false, - "node-name": "libvirt-2-storage", - "ro": true, - "node-name": "libvirt-1-format", - "ro": false, <-------------- - "node-name": "libvirt-1-storage", - -File descriptor has been reopened in RO, but "libvirt-1-storage" node -still has RW permissions set. - -I'm wondering it this a bug or this is intended? Looks like a bug to -me, although I see that some iotests (e.g. 273) expect 2 nodes related -to the same image file to have different RO flags. - -bdrv_reopen_set_read_only() - bdrv_reopen() - bdrv_reopen_queue() - bdrv_reopen_queue_child() - bdrv_reopen_multiple() - bdrv_list_refresh_perms() - bdrv_topological_dfs() - bdrv_do_refresh_perms() - bdrv_reopen_commit() - -In the stack above bdrv_reopen_set_read_only() is only being called for -the parent (libvirt-1-format) node. There're 2 lists: BDSs from -refresh_list are used by bdrv_drv_set_perm and this leads to actual -reopen with RO of the file descriptor. And then there's reopen queue -bs_queue -- BDSs from this queue get their parameters updated. While -refresh_list ends up having the whole subtree (including children, this -is done in bdrv_topological_dfs()) bs_queue only has the parent. And -that is because storage (child) node's (bs->inherits_from == NULL), so -bdrv_reopen_queue_child() never adds it to the queue. Could it be the -source of this bug? - -Anyway, would greatly appreciate a clarification. - -Andrey - -On 4/24/24 21:00, Andrey Drobyshev wrote: -> -Hi everyone, -> -> -When making an external snapshot, we end up in a situation when 2 block -> -graph nodes related to the same image file (format and storage nodes) -> -have different RO flags set on them. -> -> -E.g. -> -> -# ls -la /proc/PID/fd -> -lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd -> -> -# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' -> ---pretty | egrep '"node-name"|"ro"' -> -"ro": false, -> -"node-name": "libvirt-1-format", -> -"ro": false, -> -"node-name": "libvirt-1-storage", -> -> -# virsh snapshot-create-as VM --name snap --disk-only -> -Domain snapshot snap created -> -> -# ls -la /proc/PID/fd -> -lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd -> -lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap -> -> -# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' -> ---pretty | egrep '"node-name"|"ro"' -> -"ro": false, -> -"node-name": "libvirt-2-format", -> -"ro": false, -> -"node-name": "libvirt-2-storage", -> -"ro": true, -> -"node-name": "libvirt-1-format", -> -"ro": false, <-------------- -> -"node-name": "libvirt-1-storage", -> -> -File descriptor has been reopened in RO, but "libvirt-1-storage" node -> -still has RW permissions set. -> -> -I'm wondering it this a bug or this is intended? Looks like a bug to -> -me, although I see that some iotests (e.g. 273) expect 2 nodes related -> -to the same image file to have different RO flags. -> -> -bdrv_reopen_set_read_only() -> -bdrv_reopen() -> -bdrv_reopen_queue() -> -bdrv_reopen_queue_child() -> -bdrv_reopen_multiple() -> -bdrv_list_refresh_perms() -> -bdrv_topological_dfs() -> -bdrv_do_refresh_perms() -> -bdrv_reopen_commit() -> -> -In the stack above bdrv_reopen_set_read_only() is only being called for -> -the parent (libvirt-1-format) node. There're 2 lists: BDSs from -> -refresh_list are used by bdrv_drv_set_perm and this leads to actual -> -reopen with RO of the file descriptor. And then there's reopen queue -> -bs_queue -- BDSs from this queue get their parameters updated. While -> -refresh_list ends up having the whole subtree (including children, this -> -is done in bdrv_topological_dfs()) bs_queue only has the parent. And -> -that is because storage (child) node's (bs->inherits_from == NULL), so -> -bdrv_reopen_queue_child() never adds it to the queue. Could it be the -> -source of this bug? -> -> -Anyway, would greatly appreciate a clarification. -> -> -Andrey -Friendly ping. Could somebody confirm that it is a bug indeed? - diff --git a/results/classifier/014/permissions/99674399 b/results/classifier/014/permissions/99674399 deleted file mode 100644 index 05a52f719..000000000 --- a/results/classifier/014/permissions/99674399 +++ /dev/null @@ -1,175 +0,0 @@ -permissions: 0.896 -device: 0.886 -debug: 0.857 -virtual: 0.848 -performance: 0.845 -mistranslation: 0.843 -assembly: 0.843 -user-level: 0.841 -register: 0.841 -architecture: 0.834 -arm: 0.829 -kernel: 0.824 -semantic: 0.822 -boot: 0.822 -PID: 0.812 -alpha: 0.804 -risc-v: 0.800 -graphic: 0.794 -files: 0.787 -operating system: 0.747 -socket: 0.747 -ppc: 0.731 -x86: 0.731 -VMM: 0.726 -network: 0.711 -peripherals: 0.705 -KVM: 0.698 -TCG: 0.686 -vnc: 0.673 -i386: 0.670 -hypervisor: 0.592 - -[BUG] qemu crashes on assertion in cpu_asidx_from_attrs when cpu is in smm mode - -Hi all! - -First, I see this issue: -https://gitlab.com/qemu-project/qemu/-/issues/1198 -. -where some kvm/hardware failure leads to guest crash, and finally to this -assertion: - - cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. - -But in the ticket the talk is about the guest crash and fixing the kernel, not -about the final QEMU assertion (which definitely show that something should be -fixed in QEMU code too). - - -We've faced same stack one time: - -(gdb) bt -#0 raise () from /lib/x86_64-linux-gnu/libc.so.6 -#1 abort () from /lib/x86_64-linux-gnu/libc.so.6 -#2 ?? () from /lib/x86_64-linux-gnu/libc.so.6 -#3 __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 -#4 cpu_asidx_from_attrs at ../hw/core/cpu-sysemu.c:76 -#5 cpu_memory_rw_debug at ../softmmu/physmem.c:3529 -#6 x86_cpu_dump_state at ../target/i386/cpu-dump.c:560 -#7 kvm_cpu_exec at ../accel/kvm/kvm-all.c:3000 -#8 kvm_vcpu_thread_fn at ../accel/kvm/kvm-accel-ops.c:51 -#9 qemu_thread_start at ../util/qemu-thread-posix.c:505 -#10 start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 -#11 clone () from /lib/x86_64-linux-gnu/libc.so.6 - - -And what I see: - -static inline int x86_asidx_from_attrs(CPUState *cs, MemTxAttrs attrs) -{ - return !!attrs.secure; -} - -int cpu_asidx_from_attrs(CPUState *cpu, MemTxAttrs attrs) -{ - int ret = 0; - - if (cpu->cc->sysemu_ops->asidx_from_attrs) { - ret = cpu->cc->sysemu_ops->asidx_from_attrs(cpu, attrs); - assert(ret < cpu->num_ases && ret >= 0); <<<<<<<<<<<<<<<<< - } - return ret; -} - -(gdb) p cpu->num_ases -$3 = 1 - -(gdb) fr 5 -#5 0x00005578c8814ba3 in cpu_memory_rw_debug (cpu=c... -(gdb) p attrs -$6 = {unspecified = 0, secure = 1, user = 0, memory = 0, requester_id = 0, -byte_swap = 0, target_tlb_bit0 = 0, target_tlb_bit1 = 0, target_tlb_bit2 = 0} - -so .secure is 1, therefore ret is 1, in the same time num_ases is 1 too and -assertion fails. - - - -Where is .secure from? - -static inline MemTxAttrs cpu_get_mem_attrs(CPUX86State *env) -{ - return ((MemTxAttrs) { .secure = (env->hflags & HF_SMM_MASK) != 0 }); -} - -Ok, it means we in SMM mode. - - - -On the other hand, it seems that num_ases seems to be always 1 for x86: - -vsementsov@vsementsov-lin:~/work/src/qemu/yc-7.2$ git grep 'num_ases = ' -cpu.c: cpu->num_ases = 0; -softmmu/cpus.c: cpu->num_ases = 1; -target/arm/cpu.c: cs->num_ases = 3 + has_secure; -target/arm/cpu.c: cs->num_ases = 1 + has_secure; -target/i386/tcg/sysemu/tcg-cpu.c: cs->num_ases = 2; - - -So, something is wrong around cpu->num_ases and x86_asidx_from_attrs() which -may return more in SMM mode. - - -The stack starts in -//7 0x00005578c882f539 in kvm_cpu_exec (cpu=cpu@entry=0x5578ca2eb340) at -../accel/kvm/kvm-all.c:3000 - if (ret < 0) { - cpu_dump_state(cpu, stderr, CPU_DUMP_CODE); - vm_stop(RUN_STATE_INTERNAL_ERROR); - } - -So that was some kvm error, and we decided to call cpu_dump_state(). And it -crashes. cpu_dump_state() is also called from hmp_info_registers, so I can -reproduce the crash with a tiny patch to master (as only CPU_DUMP_CODE path -calls cpu_memory_rw_debug(), as it is in kvm_cpu_exec()): - -diff --git a/monitor/hmp-cmds-target.c b/monitor/hmp-cmds-target.c -index ff01cf9d8d..dcf0189048 100644 ---- a/monitor/hmp-cmds-target.c -+++ b/monitor/hmp-cmds-target.c -@@ -116,7 +116,7 @@ void hmp_info_registers(Monitor *mon, const QDict *qdict) - } - - monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index); -- cpu_dump_state(cs, NULL, CPU_DUMP_FPU); -+ cpu_dump_state(cs, NULL, CPU_DUMP_CODE); - } - } - - -Than run - -yes "info registers" | ./build/qemu-system-x86_64 -accel kvm -monitor stdio \ - -global driver=cfi.pflash01,property=secure,value=on \ - -blockdev "{'driver': 'file', 'filename': -'/usr/share/OVMF/OVMF_CODE_4M.secboot.fd', 'node-name': 'ovmf-code', 'read-only': -true}" \ - -blockdev "{'driver': 'file', 'filename': '/usr/share/OVMF/OVMF_VARS_4M.fd', -'node-name': 'ovmf-vars', 'read-only': true}" \ - -machine q35,smm=on,pflash0=ovmf-code,pflash1=ovmf-vars -m 2G -nodefaults - -And after some time (less than 20 seconds for me) it leads to - -qemu-system-x86_64: ../hw/core/cpu-sysemu.c:76: cpu_asidx_from_attrs: Assertion `ret < -cpu->num_ases && ret >= 0' failed. -Aborted (core dumped) - - -I've no idea how to correctly fix this bug, but I hope that my reproducer and -investigation will help a bit. - --- -Best regards, -Vladimir - |