restructure results

5 files changed, 0 insertions, 700 deletions

diff --git a/results/classifier/014/operating system/02572177 b/results/classifier/014/operating system/02572177
deleted file mode 100644
index a19ec856..00000000
--- a/results/classifier/014/operating system/02572177
+++ /dev/null
@@ -1,448 +0,0 @@
-operating system: 0.816
-permissions: 0.812
-device: 0.791
-architecture: 0.788
-performance: 0.781
-peripherals: 0.775
-virtual: 0.774
-semantic: 0.770
-register: 0.767
-risc-v: 0.761
-debug: 0.756
-assembly: 0.756
-ppc: 0.753
-arm: 0.749
-graphic: 0.747
-socket: 0.742
-user-level: 0.735
-PID: 0.731
-hypervisor: 0.723
-TCG: 0.722
-x86: 0.719
-network: 0.708
-vnc: 0.706
-mistranslation: 0.693
-VMM: 0.692
-kernel: 0.689
-alpha: 0.679
-KVM: 0.669
-boot: 0.658
-files: 0.640
-i386: 0.635
-
-[Qemu-devel] 答复: Re:  [BUG]COLO failover hang
-
-hi.
-
-
-I test the git qemu master have the same problem.
-
-
-(gdb) bt
-
-
-#0  qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, niov=1, 
-fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461
-
-
-#1  0x00007f658e4aa0c2 in qio_channel_read (address@hidden, address@hidden "", 
-address@hidden, address@hidden) at io/channel.c:114
-
-
-#2  0x00007f658e3ea990 in channel_get_buffer (opaque=＜optimized out＞, 
-buf=0x7f65907cb838 "", pos=＜optimized out＞, size=32768) at 
-migration/qemu-file-channel.c:78
-
-
-#3  0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at 
-migration/qemu-file.c:295
-
-
-#4  0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, address@hidden) at 
-migration/qemu-file.c:555
-
-
-#5  0x00007f658e3ea34b in qemu_get_byte (address@hidden) at 
-migration/qemu-file.c:568
-
-
-#6  0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at 
-migration/qemu-file.c:648
-
-
-#7  0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, 
-address@hidden) at migration/colo.c:244
-
-
-#8  0x00007f658e3e681e in colo_receive_check_message (f=＜optimized out＞, 
-address@hidden, address@hidden)
-
-
-    at migration/colo.c:264
-
-
-#9  0x00007f658e3e740e in colo_process_incoming_thread (opaque=0x7f658eb30360 
-＜mis_current.31286＞) at migration/colo.c:577
-
-
-#10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0
-
-
-#11 0x00007f65881983ed in clone () from /lib64/libc.so.6
-
-
-(gdb) p ioc-＞name
-
-
-$2 = 0x7f658ff7d5c0 "migration-socket-incoming"
-
-
-(gdb) p ioc-＞features          Do not support QIO_CHANNEL_FEATURE_SHUTDOWN
-
-
-$3 = 0
-
-
-
-
-
-(gdb) bt
-
-
-#0  socket_accept_incoming_migration (ioc=0x7fdcceeafa90, condition=G_IO_IN, 
-opaque=0x7fdcceeafa90) at migration/socket.c:137
-
-
-#1  0x00007fdcc6966350 in g_main_dispatch (context=＜optimized out＞) at 
-gmain.c:3054
-
-
-#2  g_main_context_dispatch (context=＜optimized out＞, address@hidden) at 
-gmain.c:3630
-
-
-#3  0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213
-
-
-#4  os_host_main_loop_wait (timeout=＜optimized out＞) at util/main-loop.c:258
-
-
-#5  main_loop_wait (address@hidden) at util/main-loop.c:506
-
-
-#6  0x00007fdccb526187 in main_loop () at vl.c:1898
-
-
-#7  main (argc=＜optimized out＞, argv=＜optimized out＞, envp=＜optimized out＞) at 
-vl.c:4709
-
-
-(gdb) p ioc-＞features
-
-
-$1 = 6
-
-
-(gdb) p ioc-＞name
-
-
-$2 = 0x7fdcce1b1ab0 "migration-socket-listener"
-
-
-
-
-
-May be socket_accept_incoming_migration should call 
-qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)??
-
-
-
-
-
-thank you.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-原始邮件
-
-
-
-发件人： address@hidden
-收件人：王广10165992 address@hidden
-抄送人： address@hidden address@hidden
-日 期 ：2017年03月16日 14:46
-主 题 ：Re: [Qemu-devel] COLO failover hang
-
-
-
-
-
-
-
-On 03/15/2017 05:06 PM, wangguang wrote:
-＞   am testing QEMU COLO feature described here [QEMU
-＞ Wiki](
-http://wiki.qemu-project.org/Features/COLO
-).
-＞
-＞ When the Primary Node panic,the Secondary Node qemu hang.
-＞ hang at recvmsg in qio_channel_socket_readv.
-＞ And  I run  { 'execute': 'nbd-server-stop' } and { "execute":
-＞ "x-colo-lost-heartbeat" } in Secondary VM's
-＞ monitor,the  Secondary Node qemu still hang at recvmsg .
-＞
-＞ I found that the colo in qemu is not complete yet.
-＞ Do the colo have any plan for development?
-
-Yes, We are developing. You can see some of patch we pushing.
-
-＞ Has anyone ever run it successfully? Any help is appreciated!
-
-In our internal version can run it successfully,
-The failover detail you can ask Zhanghailiang for help.
-Next time if you have some question about COLO,
-please cc me and zhanghailiang address@hidden
-
-
-Thanks
-Zhang Chen
-
-
-＞
-＞
-＞
-＞ centos7.2+qemu2.7.50
-＞ (gdb) bt
-＞ #0  0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0
-＞ #1  0x00007f3e0332b738 in qio_channel_socket_readv (ioc=＜optimized out＞,
-＞ iov=＜optimized out＞, niov=＜optimized out＞, fds=0x0, nfds=0x0, errp=0x0) at
-＞ io/channel-socket.c:497
-＞ #2  0x00007f3e03329472 in qio_channel_read (address@hidden,
-＞ address@hidden "", address@hidden,
-＞ address@hidden) at io/channel.c:97
-＞ #3  0x00007f3e032750e0 in channel_get_buffer (opaque=＜optimized out＞,
-＞ buf=0x7f3e05910f38 "", pos=＜optimized out＞, size=32768) at
-＞ migration/qemu-file-channel.c:78
-＞ #4  0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at
-＞ migration/qemu-file.c:257
-＞ #5  0x00007f3e03274a41 in qemu_peek_byte (address@hidden,
-＞ address@hidden) at migration/qemu-file.c:510
-＞ #6  0x00007f3e03274aab in qemu_get_byte (address@hidden) at
-＞ migration/qemu-file.c:523
-＞ #7  0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at
-＞ migration/qemu-file.c:603
-＞ #8  0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00,
-＞ address@hidden) at migration/colo.c:215
-＞ #9  0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48,
-＞ checkpoint_request=＜synthetic pointer＞, f=＜optimized out＞) at
-＞ migration/colo.c:546
-＞ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at
-＞ migration/colo.c:649
-＞ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0
-＞ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc.so.6
-＞
-＞
-＞
-＞
-＞
-＞ --
-＞ View this message in context:
-http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html
-＞ Sent from the Developer mailing list archive at Nabble.com.
-＞
-＞
-＞
-＞
-
--- 
-Thanks
-Zhang Chen
-
-Hi,Wang.
-
-You can test this branch:
-https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk
-and please follow wiki ensure your own configuration correctly.
-http://wiki.qemu-project.org/Features/COLO
-Thanks
-
-Zhang Chen
-
-
-On 03/21/2017 03:27 PM, address@hidden wrote:
-hi.
-
-I test the git qemu master have the same problem.
-
-(gdb) bt
-#0  qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880,
-niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461
-#1  0x00007f658e4aa0c2 in qio_channel_read
-(address@hidden, address@hidden "",
-address@hidden, address@hidden) at io/channel.c:114
-#2  0x00007f658e3ea990 in channel_get_buffer (opaque=＜optimized out＞,
-buf=0x7f65907cb838 "", pos=＜optimized out＞, size=32768) at
-migration/qemu-file-channel.c:78
-#3  0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at
-migration/qemu-file.c:295
-#4  0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden,
-address@hidden) at migration/qemu-file.c:555
-#5  0x00007f658e3ea34b in qemu_get_byte (address@hidden) at
-migration/qemu-file.c:568
-#6  0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at
-migration/qemu-file.c:648
-#7  0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800,
-address@hidden) at migration/colo.c:244
-#8  0x00007f658e3e681e in colo_receive_check_message (f=＜optimized
-out＞, address@hidden,
-address@hidden)
-at migration/colo.c:264
-#9  0x00007f658e3e740e in colo_process_incoming_thread
-(opaque=0x7f658eb30360 ＜mis_current.31286＞) at migration/colo.c:577
-#10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0
-
-#11 0x00007f65881983ed in clone () from /lib64/libc.so.6
-
-(gdb) p ioc-＞name
-
-$2 = 0x7f658ff7d5c0 "migration-socket-incoming"
-
-(gdb) p ioc-＞features        Do not support QIO_CHANNEL_FEATURE_SHUTDOWN
-
-$3 = 0
-
-
-(gdb) bt
-#0  socket_accept_incoming_migration (ioc=0x7fdcceeafa90,
-condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137
-#1  0x00007fdcc6966350 in g_main_dispatch (context=＜optimized out＞) at
-gmain.c:3054
-#2  g_main_context_dispatch (context=＜optimized out＞,
-address@hidden) at gmain.c:3630
-#3  0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213
-#4  os_host_main_loop_wait (timeout=＜optimized out＞) at
-util/main-loop.c:258
-#5  main_loop_wait (address@hidden) at
-util/main-loop.c:506
-#6  0x00007fdccb526187 in main_loop () at vl.c:1898
-#7  main (argc=＜optimized out＞, argv=＜optimized out＞, envp=＜optimized
-out＞) at vl.c:4709
-(gdb) p ioc-＞features
-
-$1 = 6
-
-(gdb) p ioc-＞name
-
-$2 = 0x7fdcce1b1ab0 "migration-socket-listener"
-May be socket_accept_incoming_migration should
-call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)??
-thank you.
-
-
-
-
-
-原始邮件
-address@hidden;
-*收件人：*王广10165992;address@hidden;
-address@hidden;address@hidden;
-*日 期 ：*2017年03月16日 14:46
-*主 题 ：**Re: [Qemu-devel] COLO failover hang*
-
-
-
-
-On 03/15/2017 05:06 PM, wangguang wrote:
-＞   am testing QEMU COLO feature described here [QEMU
-＞ Wiki](
-http://wiki.qemu-project.org/Features/COLO
-).
-＞
-＞ When the Primary Node panic,the Secondary Node qemu hang.
-＞ hang at recvmsg in qio_channel_socket_readv.
-＞ And  I run  { 'execute': 'nbd-server-stop' } and { "execute":
-＞ "x-colo-lost-heartbeat" } in Secondary VM's
-＞ monitor,the  Secondary Node qemu still hang at recvmsg .
-＞
-＞ I found that the colo in qemu is not complete yet.
-＞ Do the colo have any plan for development?
-
-Yes, We are developing. You can see some of patch we pushing.
-
-＞ Has anyone ever run it successfully? Any help is appreciated!
-
-In our internal version can run it successfully,
-The failover detail you can ask Zhanghailiang for help.
-Next time if you have some question about COLO,
-please cc me and zhanghailiang address@hidden
-
-
-Thanks
-Zhang Chen
-
-
-＞
-＞
-＞
-＞ centos7.2+qemu2.7.50
-＞ (gdb) bt
-＞ #0  0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0
-＞ #1  0x00007f3e0332b738 in qio_channel_socket_readv (ioc=＜optimized out＞,
-＞ iov=＜optimized out＞, niov=＜optimized out＞, fds=0x0, nfds=0x0, errp=0x0) at
-＞ io/channel-socket.c:497
-＞ #2  0x00007f3e03329472 in qio_channel_read (address@hidden,
-＞ address@hidden "", address@hidden,
-＞ address@hidden) at io/channel.c:97
-＞ #3  0x00007f3e032750e0 in channel_get_buffer (opaque=＜optimized out＞,
-＞ buf=0x7f3e05910f38 "", pos=＜optimized out＞, size=32768) at
-＞ migration/qemu-file-channel.c:78
-＞ #4  0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at
-＞ migration/qemu-file.c:257
-＞ #5  0x00007f3e03274a41 in qemu_peek_byte (address@hidden,
-＞ address@hidden) at migration/qemu-file.c:510
-＞ #6  0x00007f3e03274aab in qemu_get_byte (address@hidden) at
-＞ migration/qemu-file.c:523
-＞ #7  0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at
-＞ migration/qemu-file.c:603
-＞ #8  0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00,
-＞ address@hidden) at migration/colo.c:215
-＞ #9  0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48,
-＞ checkpoint_request=＜synthetic pointer＞, f=＜optimized out＞) at
-＞ migration/colo.c:546
-＞ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at
-＞ migration/colo.c:649
-＞ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0
-＞ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc.so.6
-＞
-＞
-＞
-＞
-＞
-＞ --
-＞ View this message in context:
-http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html
-＞ Sent from the Developer mailing list archive at Nabble.com.
-＞
-＞
-＞
-＞
-
---
-Thanks
-Zhang Chen
---
-Thanks
-Zhang Chen
-
diff --git a/results/classifier/014/operating system/24930826 b/results/classifier/014/operating system/24930826
deleted file mode 100644
index 9640f136..00000000
--- a/results/classifier/014/operating system/24930826
+++ /dev/null
@@ -1,60 +0,0 @@
-operating system: 0.922
-device: 0.709
-graphic: 0.667
-mistranslation: 0.637
-performance: 0.624
-user-level: 0.581
-PID: 0.532
-debug: 0.525
-network: 0.513
-ppc: 0.487
-semantic: 0.487
-virtual: 0.480
-vnc: 0.473
-architecture: 0.452
-socket: 0.447
-peripherals: 0.447
-permissions: 0.398
-risc-v: 0.397
-kernel: 0.391
-register: 0.384
-VMM: 0.382
-files: 0.338
-arm: 0.325
-i386: 0.263
-x86: 0.239
-boot: 0.218
-TCG: 0.214
-hypervisor: 0.213
-alpha: 0.201
-KVM: 0.172
-assembly: 0.142
-
-[Qemu-devel] [BUG] vhost-user: hot-unplug vhost-user nic for windows guest OS will fail with 100% reproduce rate
-
-Hi, guys
-
-I met a problem when hot-unplug vhost-user nic for Windows 2008 rc2 sp1 64 
-(Guest OS)
-
-The xml of nic is as followed:
-<interface type='vhostuser'>
-  <mac address='52:54:00:3b:83:aa'/>
-  <source type='unix' path='/var/run/vhost-user/port1' mode='client'/>
-  <target dev='port1'/>
-  <model type='virtio'/>
-  <driver queues='4'/>
-  <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
-</interface>
-
-Firstly, I use virsh attach-device win2008 vif.xml to hot-plug a nic for Guest 
-OS. This operation returns success.
-After guest OS discover nic successfully, I use virsh detach-device win2008 
-vif.xml to hot-unplug it. This operation will fail with 100% reproduce rate.
-
-However, if I hot-plug and hot-unplug virtio-net nic , it will not fail.
-
-I have analysis the process of qmp_device_del , I found that qemu have inject 
-interrupt to acpi to let it notice guest OS to remove nic.
-I guess there is something wrong in Windows when handle the interrupt.
-
diff --git a/results/classifier/014/operating system/62179944 b/results/classifier/014/operating system/62179944
deleted file mode 100644
index dcede9df..00000000
--- a/results/classifier/014/operating system/62179944
+++ /dev/null
@@ -1,58 +0,0 @@
-operating system: 0.980
-network: 0.966
-graphic: 0.907
-device: 0.818
-virtual: 0.784
-performance: 0.636
-socket: 0.608
-register: 0.601
-boot: 0.567
-files: 0.565
-ppc: 0.562
-user-level: 0.542
-mistranslation: 0.533
-PID: 0.504
-vnc: 0.498
-hypervisor: 0.492
-peripherals: 0.470
-architecture: 0.459
-semantic: 0.454
-alpha: 0.419
-permissions: 0.403
-debug: 0.400
-arm: 0.379
-risc-v: 0.345
-assembly: 0.275
-VMM: 0.258
-TCG: 0.217
-i386: 0.187
-x86: 0.164
-KVM: 0.153
-kernel: 0.063
-
-[Qemu-devel] [BUG] network : windows os lost ip address of the network card  in some cases
-
-we  found this problem for a long time 。For example, if we has three network 
-card in virtual xml file ，such as "network connection 1" / "network connection 
-2"/"network connection 3" 。
-
-Echo network card has own ip address ，such as 192.168.1.1 / 2.1 /3.1 , when 
-delete the first card ，reboot the windows virtual os, then this problem 
-happened !
-
-
-
-
-we found that the sencond network card will  replace the first one , then the 
-ip address of "network connection 2 " become 192.168.1.1 。
-
-
-Our third party users began to complain about this bug 。All the business of the 
-second ip  lost !!! 
-
-I mean both of windows and linux has this bug ,  we solve this bug in linux  
-throught bonding netcrad pci and mac address 。
-
-There is no good solution on windows os . thera are ?  we implemented a plan to 
-resumption of IP by QGA.  Is there a better way ?
-
diff --git a/results/classifier/014/operating system/63565653 b/results/classifier/014/operating system/63565653
deleted file mode 100644
index ab28ef97..00000000
--- a/results/classifier/014/operating system/63565653
+++ /dev/null
@@ -1,76 +0,0 @@
-operating system: 0.908
-device: 0.889
-boot: 0.889
-PID: 0.887
-architecture: 0.864
-network: 0.861
-debug: 0.855
-ppc: 0.855
-performance: 0.834
-KVM: 0.827
-semantic: 0.825
-peripherals: 0.824
-i386: 0.792
-virtual: 0.787
-x86: 0.765
-register: 0.755
-kernel: 0.746
-socket: 0.745
-permissions: 0.739
-arm: 0.737
-graphic: 0.734
-files: 0.705
-VMM: 0.695
-risc-v: 0.657
-hypervisor: 0.624
-user-level: 0.607
-vnc: 0.588
-assembly: 0.571
-TCG: 0.567
-alpha: 0.545
-mistranslation: 0.462
-
-[Qemu-devel] [BUG]pcibus_reset assertion failure on guest reboot
-
-Qemu-2.6.2
-
-Start a vm with vhost-net , do reboot and hot-unplug viritio-net nic in short 
-time, we touch 
-pcibus_reset assertion failure.
-
-Here is qemu log:
-22:29:46.359386+08:00  acpi_pm1_cnt_write -> guest do soft power off
-22:29:46.785310+08:00  qemu_devices_reset
-22:29:46.788093+08:00  virtio_pci_device_unplugged -> virtio net unpluged
-22:29:46.803427+08:00  pcibus_reset: Assertion `bus->irq_count[i] == 0' failed.
-
-Here is stack info: 
-(gdb) bt
-#0  0x00007f9a336795d7 in raise () from /usr/lib64/libc.so.6
-#1  0x00007f9a3367acc8 in abort () from /usr/lib64/libc.so.6
-#2  0x00007f9a33672546 in __assert_fail_base () from /usr/lib64/libc.so.6
-#3  0x00007f9a336725f2 in __assert_fail () from /usr/lib64/libc.so.6
-#4  0x0000000000641884 in pcibus_reset (qbus=0x29eee60) at hw/pci/pci.c:283
-#5  0x00000000005bfc30 in qbus_reset_one (bus=0x29eee60, opaque=<optimized 
-out>) at hw/core/qdev.c:319
-#6  0x00000000005c1b19 in qdev_walk_children (dev=0x29ed2b0, pre_devfn=0x0, 
-pre_busfn=0x0, post_devfn=0x5c2440 ...
-#7  0x00000000005c1c59 in qbus_walk_children (bus=0x2736f80, pre_devfn=0x0, 
-pre_busfn=0x0, post_devfn=0x5c2440 ...
-#8  0x00000000005513f5 in qemu_devices_reset () at vl.c:1998
-#9  0x00000000004cab9d in pc_machine_reset () at 
-/home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/i386/pc.c:1976
-#10 0x000000000055148b in qemu_system_reset (address@hidden) at vl.c:2011
-#11 0x000000000055164f in main_loop_should_exit () at vl.c:2169
-#12 0x0000000000551719 in main_loop () at vl.c:2212
-#13 0x000000000041c9a8 in main (argc=<optimized out>, argv=<optimized out>, 
-envp=<optimized out>) at vl.c:5130
-(gdb) f 4
-...
-(gdb) p bus->irq_count[0]
-$6 = 1
-
-Seems pci_update_irq_disabled doesn't work well
-
-can anyone help?
-
diff --git a/results/classifier/014/operating system/73660729 b/results/classifier/014/operating system/73660729
deleted file mode 100644
index b2077566..00000000
--- a/results/classifier/014/operating system/73660729
+++ /dev/null
@@ -1,58 +0,0 @@
-arm: 0.920
-architecture: 0.913
-operating system: 0.906
-graphic: 0.858
-kernel: 0.798
-performance: 0.786
-x86: 0.785
-peripherals: 0.733
-virtual: 0.733
-semantic: 0.698
-device: 0.697
-hypervisor: 0.677
-ppc: 0.673
-files: 0.640
-mistranslation: 0.633
-network: 0.598
-VMM: 0.588
-register: 0.583
-debug: 0.580
-socket: 0.556
-user-level: 0.556
-PID: 0.549
-TCG: 0.541
-i386: 0.532
-risc-v: 0.497
-vnc: 0.467
-permissions: 0.403
-assembly: 0.393
-boot: 0.367
-KVM: 0.272
-alpha: 0.268
-
-[BUG]The latest qemu crashed when I tested cxl
-
-I test cxl with the patch:[v11,0/2] arm/virt:
- CXL support via pxb_cxl.
-https://patchwork.kernel.org/project/cxl/cover/20220616141950.23374-1-Jonathan.Cameron@huawei.com/
-But the qemu crashed,and showing an error:
-qemu-system-aarch64: ../hw/arm/virt.c:1735: virt_get_high_memmap_enabled:
- Assertion `ARRAY_SIZE(extended_memmap) - VIRT_LOWMEMMAP_LAST == ARRAY_SIZE(enabled_array)' failed.
-Then I modify the patch to fix the bug:
-diff --git a/hw/arm/virt.c b/hw/arm/virt.c
-index ea2413a0ba..3d4cee3491 100644
---- a/hw/arm/virt.c
-+++ b/hw/arm/virt.c
-@@ -1710,6 +1730,7 @@ static inline bool *virt_get_high_memmap_enabled(VirtMachineState
- *vms,
-&vms->highmem_redists,
-&vms->highmem_ecam,
-&vms->highmem_mmio,
-+ &vms->cxl_devices_state.is_enabled,
-};
-Now qemu works good.
-Could you tell me when the patch(
-arm/virt:
- CXL support via pxb_cxl
-) will be merged into upstream?
-