On Thu, 06/11 16:29, Fam Zheng wrote:
On Mon, 06/08 14:02, Stefan Hajnoczi wrote:
On Mon, Jun 08, 2015 at 01:56:06PM +0800, Fam Zheng wrote:
v7: Fix the lost assignment of s-unmap.
v6: Fix pnum in bdrv_get_block_status_above. [Paolo]
v5: Rewrite patch 1.
Address Eric's
From: Gonglei arei.gong...@huawei.com
in_num = req-elem.in_num, and req-elem.in_num is
checked in line 489, so the check about in_num variable
is superflous, let's drop it.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/block/virtio-blk.c | 3 +--
1 file changed, 1 insertion(+), 2
On 24/06/2015 04:47, Fam Zheng wrote:
2. Is this about thread safety? (No, it's about exclusive access to a
BDS *within* the AioContext.)
As it has to quiesce iothreads as well (for now it's even more urgent than
exclusive access within the same AioContext), I'd rather take it as yes.
Right now, we don't have an interface to detect that cases and
got back to the iterative stage.
How about go back to the iterative stage when detect that the
pending_size is larger Than max_size, like this:
+/* do flush here is aimed to shorten the VM
On Wed, 06/24 17:29, arei.gong...@huawei.com wrote:
From: Gonglei arei.gong...@huawei.com
in_num = req-elem.in_num, and req-elem.in_num is
checked in line 489, so the check about in_num variable
is superflous, let's drop it.
Signed-off-by: Gonglei arei.gong...@huawei.com
Reviewed-by: Fam
* Wen Congyang (ghost...@gmail.com) wrote:
At 2015/6/19 18:49, Stefan Hajnoczi Wrote:
On Fri, Jun 19, 2015 at 08:54:56AM +0800, Wen Congyang wrote:
On 06/19/2015 12:06 AM, Stefan Hajnoczi wrote:
On Thu, Jun 18, 2015 at 10:36:39PM +0800, Wen Congyang wrote:
At 2015/6/18 20:55, Stefan Hajnoczi
On Tue, Jun 23, 2015 at 01:00:44PM -0400, John Snow wrote:
Stefan: I know you said this wasn't expressly requisite, but I was
encouraged by Kevin to send it out as a usability patch for non-libvirt
users, so here it is.
Final Yeah sure or No, definitely not as 2.4 approaches?
Also note
On Wed, 06/24 18:34, Max Reitz wrote:
On 09.06.2015 04:13, Fam Zheng wrote:
This is the part that will be reused by blockdev-mirror.
Signed-off-by: Fam Zheng f...@redhat.com
---
blockdev.c | 158
+++--
1 file changed, 92
On Wed, Jun 24, 2015 at 05:29:24PM +0800, arei.gong...@huawei.com wrote:
From: Gonglei arei.gong...@huawei.com
in_num = req-elem.in_num, and req-elem.in_num is
checked in line 489, so the check about in_num variable
is superflous, let's drop it.
Signed-off-by: Gonglei
It's necessary to distinguish source and target before we can add
blockdev-mirror, because we would want a concrete type of operation to
check on target bs before starting.
Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
---
blockdev.c | 2
This will start a mirror job from a named device to another named
device, its relation with drive-mirror is similar with blockdev-backup
to drive-backup.
In blockdev-mirror, the target node should be prepared by blockdev-add,
which will be responsible for assigning a name to the new node, so
On 09.06.2015 04:13, Fam Zheng wrote:
This is the part that will be reused by blockdev-mirror.
Signed-off-by: Fam Zheng f...@redhat.com
---
blockdev.c | 158 +++--
1 file changed, 92 insertions(+), 66 deletions(-)
diff --git
On 09.06.2015 04:13, Fam Zheng wrote:
It's necessary to distinguish source and target before we can add
blockdev-mirror, because we would want a concrete type of operation to
check on target bs before starting.
Signed-off-by: Fam Zheng f...@redhat.com
---
blockdev.c | 2
On 09.06.2015 04:13, Fam Zheng wrote:
Signed-off-by: Fam Zheng f...@redhat.com
---
blockdev.c| 3 +++
include/block/block.h | 1 +
2 files changed, 4 insertions(+)
Reviewed-by: Max Reitz mre...@redhat.com
On 09.06.2015 04:13, Fam Zheng wrote:
In block/backup.c, we already check and add blocker on the target bs,
which is necessary so that it won't be intervened with other operations.
In block/mirror.c we should also protect the mirror target bs, because it
could have a node-name (drive-mirror ...
On 24.06.2015 07:05, Jindřich Makovička wrote:
Fixes a crash during image compression
Signed-off-by: Jindřich Makovička makov...@gmail.com
---
block/qcow2-refcount.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Max Reitz mre...@redhat.com
On 09.06.2015 04:13, Fam Zheng wrote:
Signed-off-by: Fam Zheng f...@redhat.com
---
tests/qemu-iotests/041 | 100 +++--
tests/qemu-iotests/041.out | 4 +-
2 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/tests/qemu-iotests/041
Ping...
https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01929.html
On Fri 05 Jun 2015 06:27:20 PM CEST, Alberto Garcia wrote:
v6:
- Update documentation to clarify what unused entries mean.
v5: https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg00573.html
- Fix build in
This series fixes a bug found by Richard Jones.
When we allocate the pagetable based on max_table_entries, we multiply
the max table entry value by 4 to accomodate a table of 32-bit integers.
However, max_table_entries is a uint32_t, and the VPC driver accepts
ranges for that entry over
When we allocate the pagetable based on max_table_entries, we multiply
the max table entry value by 4 to accomodate a table of 32-bit integers.
However, max_table_entries is a uint32_t, and the VPC driver accepts
ranges for that entry over 0x4000. So during this allocation:
s-pagetable =
This checks that VPC is able to successfully fail (without segfault)
on an image file with a max_table_entries that exceeds 0x4000.
This table entry is within the valid range for VPC (although too large
for this sample image).
Signed-off-by: Jeff Cody jc...@redhat.com
---
21 matches
Mail list logo
