Use the 'xl pci-attach $DomU $BDF' command to attach more than one
PCI devices to the guest, then detach the devices with 'xl
pci-detach $DomU $BDF', after that, re-attach these PCI devices
again, an error message will be reported like following:
libxl: error:
Hi All,
Have you returned from vacation? If so, could you help to review my
patches I have submitted three weeks ago? Thanks a lot.
Liang
-Original Message-
From: Li, Liang Z
Sent: Friday, December 12, 2014 9:29 AM
To: qemu-devel@nongnu.org
Cc: quint...@redhat.com; lcapitul
Hi Paolo,
We have found a bug in all the xen-4.4 and xen-4.5-rcx, the bug
can be reproduced by the following steps:
Use the 'xl pci-attach $DomU $BDF' command to attach more then
one PCI devices to the guest, then detach the devices with
'xl pci-detach $DomU $BDF', after that, re-attach these
-Original Message-
From: Li, Liang Z
Sent: Friday, December 12, 2014 9:29 AM
To: qemu-devel@nongnu.org
Cc: quint...@redhat.com; lcapitul...@redhat.com; ebl...@redhat.com;
arm...@redhat.com; Zhang, Yang Z; dgilb...@redhat.com; Li, Liang Z
Subject: [PATCH v3 0/13] migration: Add a new
##
{ 'enum': 'MigrationCapability',
- 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
}
+ 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+ 'compress'] }
I'll repeat what I said on v1 (but this time, with some links to back
it up :)
We really
#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
- 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
}
+ 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
+ 'compress'] }
I'll repeat what I said on v1 (but this time, with some links to back it
# @auto-converge: If enabled, QEMU will automatically throttle down the
guest
# to speed up convergence of RAM migration. (since 1.6)
#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
- 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
}
+
hmm, multiple thread compression can't co-work with xbzrle. xbzrle need
guarantee the cache at src is same to dest. But I dont see that below:
+/* XBZRLE overflow or normal page */
+if (bytes_sent == -1) {
+bytes_sent = migrate_save_block_hdr(param-migbuf, block,
+
+static void migrate_put_be32(MigBuf *f, unsigned int v)
+{
+migrate_put_byte(f, v 24);
+migrate_put_byte(f, v 16);
+migrate_put_byte(f, v 8);
+migrate_put_byte(f, v);
+}
+
+static void migrate_put_be64(MigBuf *f, uint64_t v)
+{
+migrate_put_be32(f, v
+int migrate_compress_threads(void)
+{
+MigrationState *s;
+
+s = migrate_get_current();
+
+return s-compress_thread_count;
+}
+
int migrate_use_xbzrle(void)
{
MigrationState *s;
@@ -697,4 +795,5 @@ void migrate_fd_connect(MigrationState *s)
OK, some high level questions:
1) How does the performance compare to running a separate compressor process
in the stream rather than embedding it in the qemu?
I have not do the test, so I don't know the performance. Maybe I can do it
later.
2) Since you're looking at different
This patch is a RFC version.
-Original Message-
From: Li, Liang Z
Sent: Friday, October 31, 2014 1:40 PM
To: qemu-devel@nongnu.org
Cc: lcapitul...@redhat.com; ebl...@redhat.com; arm...@redhat.com; Li, Liang Z
Subject: [PATCH 1/2] migration: Implement a multiple compress threads feature
This is a RFC version.
-Original Message-
From: Li, Liang Z
Sent: Friday, October 31, 2014 1:40 PM
To: qemu-devel@nongnu.org
Cc: lcapitul...@redhat.com; ebl...@redhat.com; arm...@redhat.com; Li, Liang Z
Subject: [PATCH 2/2] docs: Add a document about multiple compression threads
From
301 - 313 of 313 matches
Mail list logo
