9 files changed, 0 insertions, 1859 deletions

diff --git a/results/classifier/006/semantic/12360755 b/results/classifier/006/semantic/12360755
deleted file mode 100644
index 62cae74a7..000000000
--- a/results/classifier/006/semantic/12360755
+++ /dev/null
@@ -1,301 +0,0 @@
-semantic: 0.911
-device: 0.902
-graphic: 0.899
-other: 0.886
-boot: 0.818
-vnc: 0.810
-socket: 0.805
-KVM: 0.770
-network: 0.738
-
-[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/006/semantic/14887122 b/results/classifier/006/semantic/14887122
deleted file mode 100644
index 1212284cf..000000000
--- a/results/classifier/006/semantic/14887122
+++ /dev/null
@@ -1,263 +0,0 @@
-semantic: 0.928
-device: 0.919
-socket: 0.914
-graphic: 0.910
-other: 0.890
-vnc: 0.871
-network: 0.855
-boot: 0.831
-KVM: 0.814
-
-[BUG][RFC] CPR transfer Issues: Socket permissions and PID files
-
-Hello,
-
-While testing CPR transfer I encountered two issues. The first is that the 
-transfer fails when running with pidfiles due to the destination qemu process 
-attempting to create the pidfile while it is still locked by the source 
-process. The second is that the transfer fails when running with the -run-with 
-user=$USERID parameter. This is because the destination qemu process creates 
-the UNIX sockets used for the CPR transfer before dropping to the lower 
-permissioned user, which causes them to be owned by the original user. The 
-source qemu process then does not have permission to connect to it because it 
-is already running as the lesser permissioned user.
-
-Reproducing the first issue:
-
-Create a source and destination qemu instance associated with the same VM where 
-both processes have the -pidfile parameter passed on the command line. You 
-should see the following error on the command line of the second process:
-
-qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource 
-temporarily unavailable
-
-Reproducing the second issue:
-
-Create a source and destination qemu instance associated with the same VM where 
-both processes have -run-with user=$USERID passed on the command line, where 
-$USERID is a different user from the one launching the processes. Then attempt 
-a CPR transfer using UNIX sockets for the main and cpr sockets. You should 
-receive the following error via QMP:
-{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': 
-Permission denied"}}
-
-I provided a minimal patch that works around the second issue.
-
-Thank you,
-Ben Chaney
-
----
-include/system/os-posix.h | 4 ++++
-os-posix.c | 8 --------
-util/qemu-sockets.c | 21 +++++++++++++++++++++
-3 files changed, 25 insertions(+), 8 deletions(-)
-
-diff --git a/include/system/os-posix.h b/include/system/os-posix.h
-index ce5b3bccf8..2a414a914a 100644
---- a/include/system/os-posix.h
-+++ b/include/system/os-posix.h
-@@ -55,6 +55,10 @@ void os_setup_limits(void);
-void os_setup_post(void);
-int os_mlock(bool on_fault);
-
-+extern struct passwd *user_pwd;
-+extern uid_t user_uid;
-+extern gid_t user_gid;
-+
-/**
-* qemu_alloc_stack:
-* @sz: pointer to a size_t holding the requested usable stack size
-diff --git a/os-posix.c b/os-posix.c
-index 52925c23d3..9369b312a0 100644
---- a/os-posix.c
-+++ b/os-posix.c
-@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s)
-}
-
-
--/*
-- * Must set all three of these at once.
-- * Legal combinations are unset by name by uid
-- */
--static struct passwd *user_pwd; /* NULL non-NULL NULL */
--static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */
--static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */
--
-/*
-* Prepare to change user ID. user_id can be one of 3 forms:
-* - a username, in which case user ID will be changed to its uid,
-diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
-index 77477c1cd5..987977ead9 100644
---- a/util/qemu-sockets.c
-+++ b/util/qemu-sockets.c
-@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr)
-#endif
-}
-
-+/*
-+ * Must set all three of these at once.
-+ * Legal combinations are unset by name by uid
-+ */
-+struct passwd *user_pwd; /* NULL non-NULL NULL */
-+uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */
-+gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */
-+
-static int unix_listen_saddr(UnixSocketAddress *saddr,
-int num,
-Error **errp)
-@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr,
-error_setg_errno(errp, errno, "Failed to bind socket to %s", path);
-goto err;
-}
-+ if (user_pwd) {
-+ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) {
-+ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", 
-path);
-+ goto err;
-+ }
-+ }
-+ else if (user_uid != -1 && user_gid != -1) {
-+ if (chown(un.sun_path, user_uid, user_gid) < 0) {
-+ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", 
-path);
-+ goto err;
-+ }
-+ }
-+
-if (listen(sock, num) < 0) {
-error_setg_errno(errp, errno, "Failed to listen on socket");
-goto err;
---
-2.40.1
-
-Thank you Ben.  I appreciate you testing CPR and shaking out the bugs.
-I will study these and propose patches.
-
-My initial reaction to the pidfile issue is that the orchestration layer must
-pass a different filename when starting the destination qemu instance.  When
-using live update without containers, these types of resource conflicts in the
-global namespaces are a known issue.
-
-- Steve
-
-On 3/14/2025 2:33 PM, Chaney, Ben wrote:
-Hello,
-
-While testing CPR transfer I encountered two issues. The first is that the 
-transfer fails when running with pidfiles due to the destination qemu process 
-attempting to create the pidfile while it is still locked by the source 
-process. The second is that the transfer fails when running with the -run-with 
-user=$USERID parameter. This is because the destination qemu process creates 
-the UNIX sockets used for the CPR transfer before dropping to the lower 
-permissioned user, which causes them to be owned by the original user. The 
-source qemu process then does not have permission to connect to it because it 
-is already running as the lesser permissioned user.
-
-Reproducing the first issue:
-
-Create a source and destination qemu instance associated with the same VM where 
-both processes have the -pidfile parameter passed on the command line. You 
-should see the following error on the command line of the second process:
-
-qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource 
-temporarily unavailable
-
-Reproducing the second issue:
-
-Create a source and destination qemu instance associated with the same VM where 
-both processes have -run-with user=$USERID passed on the command line, where 
-$USERID is a different user from the one launching the processes. Then attempt 
-a CPR transfer using UNIX sockets for the main and cpr sockets. You should 
-receive the following error via QMP:
-{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': 
-Permission denied"}}
-
-I provided a minimal patch that works around the second issue.
-
-Thank you,
-Ben Chaney
-
----
-include/system/os-posix.h | 4 ++++
-os-posix.c | 8 --------
-util/qemu-sockets.c | 21 +++++++++++++++++++++
-3 files changed, 25 insertions(+), 8 deletions(-)
-
-diff --git a/include/system/os-posix.h b/include/system/os-posix.h
-index ce5b3bccf8..2a414a914a 100644
---- a/include/system/os-posix.h
-+++ b/include/system/os-posix.h
-@@ -55,6 +55,10 @@ void os_setup_limits(void);
-void os_setup_post(void);
-int os_mlock(bool on_fault);
-
-+extern struct passwd *user_pwd;
-+extern uid_t user_uid;
-+extern gid_t user_gid;
-+
-/**
-* qemu_alloc_stack:
-* @sz: pointer to a size_t holding the requested usable stack size
-diff --git a/os-posix.c b/os-posix.c
-index 52925c23d3..9369b312a0 100644
---- a/os-posix.c
-+++ b/os-posix.c
-@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s)
-}
-
-
--/*
-- * Must set all three of these at once.
-- * Legal combinations are unset by name by uid
-- */
--static struct passwd *user_pwd; /* NULL non-NULL NULL */
--static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */
--static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */
--
-/*
-* Prepare to change user ID. user_id can be one of 3 forms:
-* - a username, in which case user ID will be changed to its uid,
-diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
-index 77477c1cd5..987977ead9 100644
---- a/util/qemu-sockets.c
-+++ b/util/qemu-sockets.c
-@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr)
-#endif
-}
-
-+/*
-+ * Must set all three of these at once.
-+ * Legal combinations are unset by name by uid
-+ */
-+struct passwd *user_pwd; /* NULL non-NULL NULL */
-+uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */
-+gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */
-+
-static int unix_listen_saddr(UnixSocketAddress *saddr,
-int num,
-Error **errp)
-@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr,
-error_setg_errno(errp, errno, "Failed to bind socket to %s", path);
-goto err;
-}
-+ if (user_pwd) {
-+ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) {
-+ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", 
-path);
-+ goto err;
-+ }
-+ }
-+ else if (user_uid != -1 && user_gid != -1) {
-+ if (chown(un.sun_path, user_uid, user_gid) < 0) {
-+ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", 
-path);
-+ goto err;
-+ }
-+ }
-+
-if (listen(sock, num) < 0) {
-error_setg_errno(errp, errno, "Failed to listen on socket");
-goto err;
---
-2.40.1
-
diff --git a/results/classifier/006/semantic/70294255 b/results/classifier/006/semantic/70294255
deleted file mode 100644
index ec81c83b1..000000000
--- a/results/classifier/006/semantic/70294255
+++ /dev/null
@@ -1,1066 +0,0 @@
-semantic: 0.858
-socket: 0.858
-device: 0.857
-graphic: 0.857
-other: 0.852
-network: 0.846
-vnc: 0.837
-boot: 0.811
-KVM: 0.806
-
-[Qemu-devel] 答复: Re:   答复: Re:  答复: Re: 答复: Re: [BUG]COLO failover hang
-
-hi:
-
-yes.it is better.
-
-And should we delete 
-
-
-
-
-#ifdef WIN32
-
-    QIO_CHANNEL(cioc)-＞event = CreateEvent(NULL, FALSE, FALSE, NULL)
-
-#endif
-
-
-
-
-in qio_channel_socket_accept？
-
-qio_channel_socket_new already have it.
-
-
-
-
-
-
-
-
-
-
-
-
-原始邮件
-
-
-
-发件人： address@hidden
-收件人：王广10165992
-抄送人： address@hidden address@hidden address@hidden address@hidden
-日 期 ：2017年03月22日 15:03
-主 题 ：Re: [Qemu-devel]  答复: Re:  答复: Re: 答复: Re: [BUG]COLO failover hang
-
-
-
-
-
-Hi,
-
-On 2017/3/22 9:42, address@hidden wrote:
-＞ diff --git a/migration/socket.c b/migration/socket.c
-＞
-＞
-＞ index 13966f1..d65a0ea 100644
-＞
-＞
-＞ --- a/migration/socket.c
-＞
-＞
-＞ +++ b/migration/socket.c
-＞
-＞
-＞ @@ -147,8 +147,9 @@ static gboolean 
-socket_accept_incoming_migration(QIOChannel *ioc,
-＞
-＞
-＞       }
-＞
-＞
-＞
-＞
-＞
-＞       trace_migration_socket_incoming_accepted()
-＞
-＞
-＞
-＞
-＞
-＞       qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming")
-＞
-＞
-＞ +    qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN)
-＞
-＞
-＞       migration_channel_process_incoming(migrate_get_current(),
-＞
-＞
-＞                                          QIO_CHANNEL(sioc))
-＞
-＞
-＞       object_unref(OBJECT(sioc))
-＞
-＞
-＞
-＞
-＞ Is this patch ok?
-＞
-
-Yes, i think this works, but a better way maybe to call 
-qio_channel_set_feature()
-in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the 
-socket accept fd,
-Or fix it by this:
-
-diff --git a/io/channel-socket.c b/io/channel-socket.c
-index f546c68..ce6894c 100644
---- a/io/channel-socket.c
-+++ b/io/channel-socket.c
-@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc,
-                            Error **errp)
-  {
-      QIOChannelSocket *cioc
--
--    cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET))
--    cioc-＞fd = -1
-+
-+    cioc = qio_channel_socket_new()
-      cioc-＞remoteAddrLen = sizeof(ioc-＞remoteAddr)
-      cioc-＞localAddrLen = sizeof(ioc-＞localAddr)
-
-
-Thanks,
-Hailiang
-
-＞ I have test it . The test could not hang any more.
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞ 原始邮件
-＞
-＞
-＞
-＞ 发件人： address@hidden
-＞ 收件人： address@hidden address@hidden
-＞ 抄送人： address@hidden address@hidden address@hidden
-＞ 日 期 ：2017年03月22日 09:11
-＞ 主 题 ：Re: [Qemu-devel]  答复: Re:  答复: Re: [BUG]COLO failover hang
-＞
-＞
-＞
-＞
-＞
-＞ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote:
-＞ ＞ * Hailiang Zhang (address@hidden) wrote:
-＞ ＞＞ Hi,
-＞ ＞＞
-＞ ＞＞ Thanks for reporting this, and i confirmed it in my test, and it is a bug.
-＞ ＞＞
-＞ ＞＞ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in
-＞ ＞＞ case COLO thread/incoming thread is stuck in read/write() while do 
-failover,
-＞ ＞＞ but it didn't take effect, because all the fd used by COLO (also migration)
-＞ ＞＞ has been wrapped by qio channel, and it will not call the shutdown API if
-＞ ＞＞ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN).
-＞ ＞＞
-＞ ＞＞ Cc: Dr. David Alan Gilbert address@hidden
-＞ ＞＞
-＞ ＞＞ I doubted migration cancel has the same problem, it may be stuck in write()
-＞ ＞＞ if we tried to cancel migration.
-＞ ＞＞
-＞ ＞＞ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, 
-Error **errp)
-＞ ＞＞ {
-＞ ＞＞      qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing")
-＞ ＞＞      migration_channel_connect(s, ioc, NULL)
-＞ ＞＞      ... ...
-＞ ＞＞ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN) above,
-＞ ＞＞ and the
-＞ ＞＞ migrate_fd_cancel()
-＞ ＞＞ {
-＞ ＞＞   ... ...
-＞ ＞＞      if (s-＞state == MIGRATION_STATUS_CANCELLING && f) {
-＞ ＞＞          qemu_file_shutdown(f)  --＞ This will not take effect. No ?
-＞ ＞＞      }
-＞ ＞＞ }
-＞ ＞
-＞ ＞ (cc'd in Daniel Berrange).
-＞ ＞ I see that we call qio_channel_set_feature(ioc, 
-QIO_CHANNEL_FEATURE_SHUTDOWN) at the
-＞ ＞ top of qio_channel_socket_new  so I think that's safe isn't it?
-＞ ＞
-＞
-＞ Hmm, you are right, this problem is only exist for the migration incoming fd, 
-thanks.
-＞
-＞ ＞ Dave
-＞ ＞
-＞ ＞＞ Thanks,
-＞ ＞＞ Hailiang
-＞ ＞＞
-＞ ＞＞ On 2017/3/21 16:10, address@hidden wrote:
-＞ ＞＞＞ Thank you。
-＞ ＞＞＞
-＞ ＞＞＞ I have test aready。
-＞ ＞＞＞
-＞ ＞＞＞ When the Primary Node panic,the Secondary Node qemu hang at the same 
-place。
-＞ ＞＞＞
-＞ ＞＞＞ Incorrding
-http://wiki.qemu-project.org/Features/COLO
-，kill Primary Node 
-qemu will not produce the problem,but Primary Node panic can。
-＞ ＞＞＞
-＞ ＞＞＞ I think due to the feature of channel does not support 
-QIO_CHANNEL_FEATURE_SHUTDOWN.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ when failover,channel_shutdown could not shut down the channel.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ so the colo_process_incoming_thread will hang at recvmsg.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ I test a patch:
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ diff --git a/migration/socket.c b/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ index 13966f1..d65a0ea 100644
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ --- a/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ +++ b/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ @@ -147,8 +147,9 @@ static gboolean 
-socket_accept_incoming_migration(QIOChannel *ioc,
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        }
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        trace_migration_socket_incoming_accepted()
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        qio_channel_set_name(QIO_CHANNEL(sioc), 
-"migration-socket-incoming")
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ +    qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN)
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        migration_channel_process_incoming(migrate_get_current(),
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞                                           QIO_CHANNEL(sioc))
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        object_unref(OBJECT(sioc))
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ My test will not hang any more.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 原始邮件
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 发件人： address@hidden
-＞ ＞＞＞ 收件人：王广10165992 address@hidden
-＞ ＞＞＞ 抄送人： address@hidden address@hidden
-＞ ＞＞＞ 日 期 ：2017年03月21日 15:58
-＞ ＞＞＞ 主 题 ：Re: [Qemu-devel]  答复: Re:  [BUG]COLO failover hang
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 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
-＞ ＞＞＞ ＞ address@hidden
-＞ ＞＞＞ ＞ address@hidden@huawei.com＞
-＞ ＞＞＞ ＞ *日 期 ：*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
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞
-＞ ＞＞
-＞ ＞ --
-＞ ＞ Dr. David Alan Gilbert / address@hidden / Manchester, UK
-＞ ＞
-＞ ＞ .
-＞ ＞
-＞
-
-On 2017/3/22 16:09, address@hidden wrote:
-hi:
-
-yes.it is better.
-
-And should we delete
-Yes, you are right.
-#ifdef WIN32
-
-     QIO_CHANNEL(cioc)-＞event = CreateEvent(NULL, FALSE, FALSE, NULL)
-
-#endif
-
-
-
-
-in qio_channel_socket_accept？
-
-qio_channel_socket_new already have it.
-
-
-
-
-
-
-
-
-
-
-
-
-原始邮件
-
-
-
-发件人： address@hidden
-收件人：王广10165992
-抄送人： address@hidden address@hidden address@hidden address@hidden
-日 期 ：2017年03月22日 15:03
-主 题 ：Re: [Qemu-devel]  答复: Re:  答复: Re: 答复: Re: [BUG]COLO failover hang
-
-
-
-
-
-Hi,
-
-On 2017/3/22 9:42, address@hidden wrote:
-＞ diff --git a/migration/socket.c b/migration/socket.c
-＞
-＞
-＞ index 13966f1..d65a0ea 100644
-＞
-＞
-＞ --- a/migration/socket.c
-＞
-＞
-＞ +++ b/migration/socket.c
-＞
-＞
-＞ @@ -147,8 +147,9 @@ static gboolean 
-socket_accept_incoming_migration(QIOChannel *ioc,
-＞
-＞
-＞       }
-＞
-＞
-＞
-＞
-＞
-＞       trace_migration_socket_incoming_accepted()
-＞
-＞
-＞
-＞
-＞
-＞       qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming")
-＞
-＞
-＞ +    qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN)
-＞
-＞
-＞       migration_channel_process_incoming(migrate_get_current(),
-＞
-＞
-＞                                          QIO_CHANNEL(sioc))
-＞
-＞
-＞       object_unref(OBJECT(sioc))
-＞
-＞
-＞
-＞
-＞ Is this patch ok?
-＞
-
-Yes, i think this works, but a better way maybe to call 
-qio_channel_set_feature()
-in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the 
-socket accept fd,
-Or fix it by this:
-
-diff --git a/io/channel-socket.c b/io/channel-socket.c
-index f546c68..ce6894c 100644
---- a/io/channel-socket.c
-+++ b/io/channel-socket.c
-@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc,
-                             Error **errp)
-   {
-       QIOChannelSocket *cioc
--
--    cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET))
--    cioc-＞fd = -1
-+
-+    cioc = qio_channel_socket_new()
-       cioc-＞remoteAddrLen = sizeof(ioc-＞remoteAddr)
-       cioc-＞localAddrLen = sizeof(ioc-＞localAddr)
-
-
-Thanks,
-Hailiang
-
-＞ I have test it . The test could not hang any more.
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞
-＞ 原始邮件
-＞
-＞
-＞
-＞ 发件人： address@hidden
-＞ 收件人： address@hidden address@hidden
-＞ 抄送人： address@hidden address@hidden address@hidden
-＞ 日 期 ：2017年03月22日 09:11
-＞ 主 题 ：Re: [Qemu-devel]  答复: Re:  答复: Re: [BUG]COLO failover hang
-＞
-＞
-＞
-＞
-＞
-＞ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote:
-＞ ＞ * Hailiang Zhang (address@hidden) wrote:
-＞ ＞＞ Hi,
-＞ ＞＞
-＞ ＞＞ Thanks for reporting this, and i confirmed it in my test, and it is a bug.
-＞ ＞＞
-＞ ＞＞ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in
-＞ ＞＞ case COLO thread/incoming thread is stuck in read/write() while do 
-failover,
-＞ ＞＞ but it didn't take effect, because all the fd used by COLO (also migration)
-＞ ＞＞ has been wrapped by qio channel, and it will not call the shutdown API if
-＞ ＞＞ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN).
-＞ ＞＞
-＞ ＞＞ Cc: Dr. David Alan Gilbert address@hidden
-＞ ＞＞
-＞ ＞＞ I doubted migration cancel has the same problem, it may be stuck in write()
-＞ ＞＞ if we tried to cancel migration.
-＞ ＞＞
-＞ ＞＞ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, 
-Error **errp)
-＞ ＞＞ {
-＞ ＞＞      qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing")
-＞ ＞＞      migration_channel_connect(s, ioc, NULL)
-＞ ＞＞      ... ...
-＞ ＞＞ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN) above,
-＞ ＞＞ and the
-＞ ＞＞ migrate_fd_cancel()
-＞ ＞＞ {
-＞ ＞＞   ... ...
-＞ ＞＞      if (s-＞state == MIGRATION_STATUS_CANCELLING && f) {
-＞ ＞＞          qemu_file_shutdown(f)  --＞ This will not take effect. No ?
-＞ ＞＞      }
-＞ ＞＞ }
-＞ ＞
-＞ ＞ (cc'd in Daniel Berrange).
-＞ ＞ I see that we call qio_channel_set_feature(ioc, 
-QIO_CHANNEL_FEATURE_SHUTDOWN) at the
-＞ ＞ top of qio_channel_socket_new  so I think that's safe isn't it?
-＞ ＞
-＞
-＞ Hmm, you are right, this problem is only exist for the migration incoming fd, 
-thanks.
-＞
-＞ ＞ Dave
-＞ ＞
-＞ ＞＞ Thanks,
-＞ ＞＞ Hailiang
-＞ ＞＞
-＞ ＞＞ On 2017/3/21 16:10, address@hidden wrote:
-＞ ＞＞＞ Thank you。
-＞ ＞＞＞
-＞ ＞＞＞ I have test aready。
-＞ ＞＞＞
-＞ ＞＞＞ When the Primary Node panic,the Secondary Node qemu hang at the same 
-place。
-＞ ＞＞＞
-＞ ＞＞＞ Incorrding
-http://wiki.qemu-project.org/Features/COLO
-，kill Primary Node 
-qemu will not produce the problem,but Primary Node panic can。
-＞ ＞＞＞
-＞ ＞＞＞ I think due to the feature of channel does not support 
-QIO_CHANNEL_FEATURE_SHUTDOWN.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ when failover,channel_shutdown could not shut down the channel.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ so the colo_process_incoming_thread will hang at recvmsg.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ I test a patch:
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ diff --git a/migration/socket.c b/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ index 13966f1..d65a0ea 100644
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ --- a/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ +++ b/migration/socket.c
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ @@ -147,8 +147,9 @@ static gboolean 
-socket_accept_incoming_migration(QIOChannel *ioc,
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        }
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        trace_migration_socket_incoming_accepted()
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        qio_channel_set_name(QIO_CHANNEL(sioc), 
-"migration-socket-incoming")
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ +    qio_channel_set_feature(QIO_CHANNEL(sioc), 
-QIO_CHANNEL_FEATURE_SHUTDOWN)
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        migration_channel_process_incoming(migrate_get_current(),
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞                                           QIO_CHANNEL(sioc))
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞        object_unref(OBJECT(sioc))
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ My test will not hang any more.
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 原始邮件
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 发件人： address@hidden
-＞ ＞＞＞ 收件人：王广10165992 address@hidden
-＞ ＞＞＞ 抄送人： address@hidden address@hidden
-＞ ＞＞＞ 日 期 ：2017年03月21日 15:58
-＞ ＞＞＞ 主 题 ：Re: [Qemu-devel]  答复: Re:  [BUG]COLO failover hang
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞
-＞ ＞＞＞ 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
-＞ ＞＞＞ ＞ address@hidden
-＞ ＞＞＞ ＞ address@hidden@huawei.com＞
-＞ ＞＞＞ ＞ *日 期 ：*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
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞ ＞
-＞ ＞＞＞
-＞ ＞＞
-＞ ＞ --
-＞ ＞ Dr. David Alan Gilbert / address@hidden / Manchester, UK
-＞ ＞
-＞ ＞ .
-＞ ＞
-＞
-
diff --git a/results/classifier/006/semantic/gitlab_semantic_addsubps b/results/classifier/006/semantic/gitlab_semantic_addsubps
deleted file mode 100644
index ba7fa933e..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_addsubps
+++ /dev/null
@@ -1,33 +0,0 @@
-semantic: 0.974
-device: 0.758
-other: 0.732
-graphic: 0.700
-vnc: 0.544
-boot: 0.465
-socket: 0.426
-network: 0.393
-KVM: 0.192
-
-x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
-
-Description of problem
-The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
-
-Steps to reproduce
-
-Compile this code
-
-void main() {
-    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
-    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
-    asm("addsubps xmm1, xmm2");
-}
-
-Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
-
-CPU xmm1[3] = 0xffffffff
-
-QEMU xmm1[3] = 0x7fffffff
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/006/semantic/gitlab_semantic_adox b/results/classifier/006/semantic/gitlab_semantic_adox
deleted file mode 100644
index be39cec22..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_adox
+++ /dev/null
@@ -1,46 +0,0 @@
-semantic: 0.990
-graphic: 0.782
-device: 0.776
-vnc: 0.663
-boot: 0.599
-socket: 0.556
-network: 0.426
-other: 0.286
-KVM: 0.240
-
-x86 ADOX and ADCX semantic bug
-Description of problem
-The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("push 512; popfq;");
-    asm("mov rax, 0xffffffff84fdbf24");
-    asm("mov rbx, 0xb197d26043bec15d");
-    asm("adox eax, ebx");
-}
-
-
-
-Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
-
-CPU
-
-OF = 0
-
-
-QEMU
-
-OF = 1
-
-
-
-
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/006/semantic/gitlab_semantic_bextr b/results/classifier/006/semantic/gitlab_semantic_bextr
deleted file mode 100644
index ec7c57fb1..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_bextr
+++ /dev/null
@@ -1,35 +0,0 @@
-semantic: 0.993
-graphic: 0.790
-device: 0.717
-boot: 0.516
-vnc: 0.471
-socket: 0.397
-network: 0.219
-other: 0.099
-KVM: 0.091
-
-x86 BEXTR semantic bug
-Description of problem
-The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
-
-Steps to reproduce
-
-Compile this code
-
-void main() {
-    asm("mov rax, 0x17b3693f77fb6e9");
-    asm("mov rbx, 0x8f635a775ad3b9b4");
-    asm("mov rcx, 0xb717b75da9983018");
-    asm("bextr eax, ebx, ecx");
-}
-
-Execute and compare the result with the CPU.
-
-CPU
-RAX = 0x5a
-
-QEMU
-RAX = 0x635a775a
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/006/semantic/gitlab_semantic_blsi b/results/classifier/006/semantic/gitlab_semantic_blsi
deleted file mode 100644
index 7a43b8907..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_blsi
+++ /dev/null
@@ -1,30 +0,0 @@
-semantic: 0.983
-graphic: 0.873
-device: 0.790
-socket: 0.764
-vnc: 0.756
-boot: 0.678
-network: 0.672
-other: 0.609
-KVM: 0.412
-
-x86 BLSI and BLSR semantic bug
-Description of problem
-The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("blsi rax, rbx");
-}
-
-
-
-Execute and compare the result with the CPU. The value of CF is exactly the opposite. This problem happens with BLSR, too.
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/006/semantic/gitlab_semantic_blsmsk b/results/classifier/006/semantic/gitlab_semantic_blsmsk
deleted file mode 100644
index db8658526..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_blsmsk
+++ /dev/null
@@ -1,37 +0,0 @@
-semantic: 0.987
-device: 0.743
-graphic: 0.735
-vnc: 0.612
-socket: 0.607
-boot: 0.585
-network: 0.366
-other: 0.269
-KVM: 0.163
-
-x86 BLSMSK semantic bug
-Description of problem
-The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
-
-Steps to reproduce
-
-Compile this code
-
-void main() {
-    asm("mov rax, 0x65b2e276ad27c67");
-    asm("mov rbx, 0x62f34955226b2b5d");
-    asm("blsmsk eax, ebx");
-}
-
-Execute and compare the result with the CPU.
-
-CPU
-
-CF = 0
-
-
-QEMU
-
-CF = 1
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/006/semantic/gitlab_semantic_bzhi b/results/classifier/006/semantic/gitlab_semantic_bzhi
deleted file mode 100644
index 672c4b22d..000000000
--- a/results/classifier/006/semantic/gitlab_semantic_bzhi
+++ /dev/null
@@ -1,48 +0,0 @@
-semantic: 0.920
-graphic: 0.652
-device: 0.589
-vnc: 0.287
-boot: 0.220
-network: 0.203
-socket: 0.198
-other: 0.064
-KVM: 0.064
-
-x86 BZHI semantic bug
-Description of problem
-The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("mov rax, 0xb1aa9da2fe33fe3");
-    asm("mov rbx, 0x80000000ffffffff");
-    asm("mov rcx, 0xf3fce8829b99a5c6");
-    asm("bzhi rax, rbx, rcx");
-}
-
-
-
-Execute and compare the result with the CPU.
-
-CPU
-
-RAX = 0x0x80000000ffffffff
-SF = 1
-
-
-QEMU
-
-RAX = 0xffffffff
-SF = 0
-
-
-
-
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.