9 files changed, 1859 insertions, 0 deletions

diff --git a/results/classifier/006/semantic/12360755 b/results/classifier/006/semantic/12360755
new file mode 100644
index 00000000..62cae74a
--- /dev/null
+++ b/results/classifier/006/semantic/12360755
@@ -0,0 +1,301 @@
+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
new file mode 100644
index 00000000..1212284c
--- /dev/null
+++ b/results/classifier/006/semantic/14887122
@@ -0,0 +1,263 @@
+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
new file mode 100644
index 00000000..ec81c83b
--- /dev/null
+++ b/results/classifier/006/semantic/70294255
@@ -0,0 +1,1066 @@
+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
new file mode 100644
index 00000000..ba7fa933
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_addsubps
@@ -0,0 +1,33 @@
+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
new file mode 100644
index 00000000..be39cec2
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_adox
@@ -0,0 +1,46 @@
+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
new file mode 100644
index 00000000..ec7c57fb
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_bextr
@@ -0,0 +1,35 @@
+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
new file mode 100644
index 00000000..7a43b890
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_blsi
@@ -0,0 +1,30 @@
+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
new file mode 100644
index 00000000..db865852
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_blsmsk
@@ -0,0 +1,37 @@
+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
new file mode 100644
index 00000000..672c4b22
--- /dev/null
+++ b/results/classifier/006/semantic/gitlab_semantic_bzhi
@@ -0,0 +1,48 @@
+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.