On 25/03/2015 09:18, Markus Armbruster wrote:
Signed-off-by: Markus Armbruster arm...@redhat.com
---
blockdev-nbd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index b29e456..85cda4c 100644
--- a/blockdev-nbd.c
+++
+##
+{ 'enum' : 'COLOMode',
+ 'data' : ['unprotected', 'primary', 'secondary']}
Perhaps replace COLOMode with ReplicationMode or FaultToleranceMode?
+##
# @BlockdevSnapshotInternal
#
# @device: the name of the device to generate the snapshot from
Apart from this,
Reviewed-by: Paolo
On 25/03/2015 10:36, Wen Congyang wrote:
Block replication is a very important feature which is used for
continuous checkpoints(for example: COLO).
Usage:
Please refer to docs/block-replication.txt
You can get the patch here:
On 25/03/2015 10:36, Wen Congyang wrote:
+void backup_do_checkpoint(BlockJob *job, Error **errp)
+{
+BackupBlockJob *backup_job = container_of(job, BackupBlockJob, common);
+
+if (job-driver != backup_job_driver) {
+error_setg(errp, It is not backup job);
+
On 30/03/2015 16:25, Markus Armbruster wrote:
Andreas Färber afaer...@suse.de writes:
Hello Markus et al.,
This series attempts to fix the -device pc87312 issues you reported.
I can't add alias properties for devices that don't get created before
realize.
Therefore this involves
On 23/03/2015 21:19, Markus Armbruster wrote:
Paolo Bonzini pbonz...@redhat.com writes:
On 23/03/2015 18:48, Eric Blake wrote:
Why can't libvirt just add ,format=raw instead of leaving out the
format key altogether?
Libvirt DOES add format=raw. This patch is an extra insurance
policy
will
notice that the coroutine has completed and schedule the bottom
half itself.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block.c | 43 ++-
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index 0fe97de..3fe0642
On 23/03/2015 11:04, Markus Armbruster wrote:
Probing is convenient, but probing untrusted raw images is insecure
(CVE-2008-2004). To avoid it, users should always specify raw format
explicitly. This isn't trivial, and even sophisticated users have
gotten it wrong (libvirt CVE-2010-2237,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/03/2015 18:48, Eric Blake wrote:
Why can't libvirt just add ,format=raw instead of leaving out the
format key altogether?
Libvirt DOES add format=raw. This patch is an extra insurance
policy to guarantee that libvirt does not have any
On 03/04/2015 12:01, Wen Congyang wrote:
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
Cc: Jeff Cody jc...@redhat.com
---
block/backup.c | 13 +
blockjob.c
On 21/04/2015 03:25, Wen Congyang wrote:
Please do not introduce name+colo block drivers. This approach is
invasive and makes block replication specific to only a few block
drivers, e.g. NBD or qcow2.
NBD is used to connect to secondary qemu, so it must be used. But the primary
qemu
On 24/04/2015 10:58, Dr. David Alan Gilbert wrote:
If we can add a filter dynamically, we can add a filter that's file is nbd
dynamically after secondary qemu's nbd server is ready. In this case, I
think
there is no need to touch nbd client.
Yes, I think maybe the harder part is
On 24/04/2015 11:02, Fam Zheng wrote:
However, it shouldn't be a problem for
the rest of the series.
It is. The request has to be splitted to aligned part and unaligned part
because the latter requires a buffer, as we don't like unbounded allocation.
Yes, I found that out after reading
On 24/04/2015 11:53, Wen Congyang wrote:
Only before starting up a new secondary. Basically you do a migration
with non-shared storage, and then start the secondary in colo mode.
But it's only for the failover case. Quorum (or a new block/colo.c
driver or filter) is fine for normal
,
+ use_local_qiov ? local_qiov : qiov,
+ flags);
+}
fail:
tracked_request_end(req);
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
On 24/04/2015 13:00, Paolo Bonzini wrote:
-qemu_iovec_add(local_qiov, head_buf, offset (align - 1));
-qemu_iovec_concat(local_qiov, qiov, 0, qiov-size);
-use_local_qiov = true;
+if (qiov) {
+qemu_iovec_init(local_qiov, qiov ? qiov-niov + 2 : 1
On 23/04/2015 11:00, Kevin Wolf wrote:
Because it may be the right design.
If you're really worried about the test matrix, put a check in the
filter block driver that its bs-file is qcow2. Of course, such an
artificial restriction looks a bit ugly, but using a bad design just
in order to
On 23/04/2015 12:17, Kevin Wolf wrote:
Perhaps quorum is not a great match after all, and it's better to add a
new colo driver similar to quorum but simpler and only using the read
policy that you need for colo. The new driver would also know how to
use BDRV_O_NO_CONNECT. In any case
On 23/04/2015 12:40, Kevin Wolf wrote:
The question that is still open for me is whether it would be a colo.c
or an active-mirror.c, i.e. if this would be tied specifically to COLO
or if it could be kept generic enough that it could be used for other
use cases as well.
Understood (now).
On 23/04/2015 11:14, Wen Congyang wrote:
The bs-file-driver should support backing file, and use backing reference
already.
What about the primary side? We should control when to connect to NBD server,
not in nbd_open().
My naive suggestion could be to add a BDRV_O_NO_CONNECT option to
On 23/04/2015 14:19, Dr. David Alan Gilbert wrote:
So that means the bdrv_start_replication and bdrv_stop_replication
callbacks are more or less redundant, at least on the primary?
In fact, who calls them? Certainly nothing in this patch set...
:)
In the main colo set (I'm looking
On 23/04/2015 13:36, Kevin Wolf wrote:
Crap. Then we need to figure out dynamic reconfiguration for filters
(CCed Markus and Jeff).
And this is really part of the fundamental operation mode and not just a
way to give users a way to change their mind at runtime? Because if it
were, we
On 22/04/2015 11:31, Kevin Wolf wrote:
Actually I liked the foo+colo names.
These are just internal details of the implementations and the
primary/secondary disks actually can be any format.
Stefan, what was your worry with the +colo block drivers?
I haven't read the patches yet, so I
On 06/05/2015 03:45, Fam Zheng wrote:
This is not enough, you also have to do the discard in block/mirror.c,
otherwise the destination image could even become fully provisioned!
I wasn't sure what if src and dest have different can_write_zeroes_with_unmap
value, but your argument is
On 06/05/2015 11:50, Fam Zheng wrote:
# src can_write_zeroes_with_unmap target can_write_zeroes_with_unmap
1 true true
2 true
On 06/05/2015 14:20, Fam Zheng wrote:
Does non-dataplane need to do anything, since it uses iohandlers rather
than aio_set_event_notifier_handler?
I guess it's not for this specific bug. See this as an attempt on a general
purpose pause mechanism to the device in investment for the
On 06/05/2015 19:23, Max Reitz wrote:
The guest sees whatever has been written into reply-error, and that
field hasn't been written by this function in that case. It has been
written by nbd_receive_reply() in nbd.c, and that value comes directly
from the server. In case of qemu-nbd being the
On 08/05/2015 12:34, Kevin Wolf wrote:
Am 08.05.2015 um 12:16 hat Paolo Bonzini geschrieben:
On 08/05/2015 12:08, Kevin Wolf wrote:
If so, the commands seem to be hopelessly underspecified, especially
with respect to error conditions. And where it says something about
errors, it doesn't
On 07/05/2015 16:34, Kevin Wolf wrote:
Am 07.05.2015 um 16:16 hat Paolo Bonzini geschrieben:
On 07/05/2015 16:07, Kevin Wolf wrote:
This is not right for two reasons: The first is that this is
BlockBackend code
I think it would take effect for the qemu-nbd case though.
Oh, you want
On 06/05/2015 18:12, Max Reitz wrote:
I very much think it would be worth fixing, if there wasn't the problem
with legitimate use cases throwing unnecessary warnings.
Right.
I remember having a discussion with Kevin about this series (v1)
regarding qcow2 on LVM; I think my point was that
On 06/05/2015 15:04, Max Reitz wrote:
Introducing a warning for a normal QEMU invocation is a bit weird.
What is the point of this series? Were users confused that they hit
ENOSPC?
Users were confused when exporting a qcow2 image using nbd-server
instead of qemu-img, and then accessing
On 11/05/2015 12:16, Kevin Wolf wrote:
Am 08.05.2015 um 19:47 hat Dimitris Aragiorgis geschrieben:
Building the QEMU tools fails if we #define DEBUG_BLOCK inside
block/raw-posix.c. Here instead of adding qemu-log.o in block-obj-y
so that DEBUG_BLOCK_PRINT can be used, we substitute the
On 09/05/2015 05:54, phoeagon wrote:
zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img convert -f raw -t writeback
-O vdi /run/shm/rand 1.vdi
real0m8.678s
user0m0.169s
sys0m0.500s
zheq-PC sdb # time qemu-img convert -f raw -t writeback -O vdi /run/shm/rand
1.vdi
real0m4.320s
+
4 files changed, 45 insertions(+), 42 deletions(-)
I am okay with the debug printf, even though the problem with debug
printfs is that no one uses them and they bitrot.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
On 10/05/2015 18:02, Stefan Weil wrote:
Since the default qemu-img convert case isn't slowed down, I
would think that correctness trumps performance. Nevertheless,
it's a huge difference.
I doubt that the convert case isn't slowed down.
The *default* convert case isn't slowed down
) {
bs-request_alignment = 1;
s-buf_align = 1;
return;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
On 08/05/2015 13:38, Dimitris Aragiorgis wrote:
During migration, QEMU uses fsync()/fdatasync() on the open file
descriptor for read-write block devices to flush data just before
stopping the VM.
However, fsync() on a scsi-generic device returns -EINVAL which
causes the migration to fail.
On 13/05/2015 19:28, Fam Zheng wrote:
+static void virtio_blk_data_plane_pause(VirtIOBlock *vblk)
+{
+VirtIOBlockDataPlane *s = vblk-dataplane;
+
+event_notifier_test_and_clear(s-host_notifier);
+aio_set_event_notifier(s-ctx, s-host_notifier, NULL);
+}
+
+static void
On 13/05/2015 19:28, Fam Zheng wrote:
We don't want new requests from guest, so block the operation around the
nested poll.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/io.c | 12
1 file changed, 12 insertions(+)
diff --git a/block/io.c b/block/io.c
index
/get_block_status
return a larger p_num than nb_sectors---which maybe could make
nb_sectors obsolete completely, I don't know. But this is already an
improvement.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Thanks,
Paolo
Signed-off-by: Fam Zheng f...@redhat.com
---
block/mirror.c | 13
On 13/05/2015 13:08, Fam Zheng wrote:
I think this isn't enough. It's the callers of bdrv_drain and
bdrv_drain_all that need to block before drain and unblock before
aio_context_release.
Which callers do you mean? qmp_transaction is covered in this series.
All of them. :(
In some
On 13/05/2015 19:28, Fam Zheng wrote:
+state-bs = bs;
+error_setg(state-blocker, blockdev-backup in progress);
+bdrv_op_block(bs, BLOCK_OP_TYPE_DEVICE_IO, state-blocker);
+
qmp_blockdev_backup(backup-device, backup-target,
backup-sync,
On 13/05/2015 17:02, Fam Zheng wrote:
For example, SCSI requests can result in many consecutive I/Os:
(1) FUA requests are split in write+flush
(2) adapters that do not use QEMUSGList-based I/O only read 128K at a time
(3) WRITE SAME operations are also split in chunks
(4)
On 13/05/2015 16:55, Fam Zheng wrote:
So if we consider this idea worthwhile, and decide that pausing device
I/O on the target should pause the block job, the backup job actually
has to prevent *adding a DEVICE_IO blocker* on the target.
When do we need to pause device IO on the target?
On 12/05/2015 12:19, Denis V. Lunev wrote:
hades /vol $ strace -f -e pwrite -e raw=write,pwrite qemu-io -n -c
write -P 0x11 0 64M ./1.img
Process 19326 attached
[pid 19326] pwrite(0x6, 0x7fac07fff200, 0x400, 0x5) = 0x400
1 GB Write from userspace
FWIW this is 64 MB
On 14/05/2015 13:02, Dimitris Aragiorgis wrote:
Also note that QEMU seems to flush the disk cache explicitly in
case of iSCSI, using iscsi_synchronizecache10_task() from libiscsi
inside iscsi_co_flush().
Right, QEMU does that if type is DISK only.
Perhaps we can also extend this approach
On 13/05/2015 18:34, Alexander Yarygin wrote:
Ah, right. We need second loop, something like this:
@@ -2030,20 +2033,33 @@ void bdrv_drain(BlockDriverState *bs)
void bdrv_drain_all(void)
{
/* Always run first iteration so any pending completion BHs run */
-bool busy = true;
+
On 13/05/2015 17:17, Fam Zheng wrote:
It can be the topic of a separate series. But this patch brings a
false sense of security (either the blocker is unnecessary, or it
needs to last after bdrv_drain returns), so I think it should be
dropped.
Doesn't this let bdrv_drain_all return
...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
block/io.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/io.c b/block/io.c
index 1ce62c4..809688b 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2343,8 +2343,6 @@ int coroutine_fn
On 19/05/2015 13:49, Fam Zheng wrote:
When block job mirror is finished, the source and target is synced. But
we call bdrv_swap() later in main loop bh. If the guest write before
that, target will not get the new data.
This is too late. As a rule, the blocker must be established before
On 19/05/2015 18:48, Fam Zheng wrote:
This is too late. As a rule, the blocker must be established before
calling bdrv_drain, and removed on the next yield (in this case, before
the assignment to last_pause_ns).
I don't understand. If the blocker is removed before mirror_run returns,
On 19/05/2015 20:37, Fam Zheng wrote:
On Tue, 05/19 10:49, Paolo Bonzini wrote:
On 19/05/2015 18:48, Fam Zheng wrote:
This is too late. As a rule, the blocker must be established before
calling bdrv_drain, and removed on the next yield (in this case, before
the assignment
On 12/05/2015 12:27, Kevin Wolf wrote:
I think it would make more sense to keep this specific to the raw-posix
driver. After all, it's only the kernel page cache that we optimise
here. Other backends probably don't take advantage of page alignment.
I don't think it makes sense to keep it
On 14/04/2015 08:49, Peter Lieven wrote:
Hi,
Ronnie came up with an idea to reduce latency if !bs-enable_write_cache
for an iSCSI device.
If !bs-enable_write_cache Qemu sends a flush after every single write.
What could be done is
the following:
if (!bs-enable_write_cache)
set FUA
On 14/04/2015 11:04, Stefan Hajnoczi wrote:
Do other commands besides writes rely on iscsi_co_flush()?
Paolo: I checked NBD and noticed there is an inconsistency there.
nbd_co_writev_1() uses FUA when bs-enable_write_cache == true but it
also sends flushes. Does that mean it's doing
On 16/04/2015 14:18, Peter Lieven wrote:
We need this to support SCSI_STATUS_TASK_SET_FULL.
Any reason apart from the missing constant?
Paolo
Signed-off-by: Peter Lieven p...@kamp.de
---
configure | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure
On 16/04/2015 15:02, Peter Lieven wrote:
Also, I think it is iscsi_co_generic_cb that should set
force_next_flush, so that it is only set on failure. Not really for the
optimization value, but because it's clearer.
I don't get what you mean with it should only set on failure.
My
On 09/04/2015 16:54, Peter Lieven wrote:
#define BM_MIGRATION_COMPAT_STATUS_BITS \
(IDE_RETRY_DMA | IDE_RETRY_PIO | \
IDE_RETRY_READ | IDE_RETRY_FLUSH)
Why is there no IDE_RETRY_WRITE ?
Because that's represented by none of read and flush being set. :)
Honestly, I have
On 09/04/2015 14:46, Peter Lieven wrote:
BMDMA is the PCI HBA for IDE, I think it's the default for most
machines that aren't using the AHCI HBA.
To get ISA, try launching with the machine isapc which will force
it, or add the device manually, it's named isa-ide.
The BMDMA PCI device is
On 07/04/2015 20:44, Peter Lieven wrote:
Has the cdrom the power of taking down the bus?
IDE can only issue one command per bus, so hda/hdb can take down each
other, and hdc/hdd can take down each other. However, hda cannot take
down hdc and vice versa---so likely the CDROM cannot take down
from this,
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
On 20/05/2015 08:16, Fam Zheng wrote:
static void mirror_exit(BlockJob *job, void *opaque)
@@ -328,6 +330,8 @@ static void mirror_exit(BlockJob *job, void *opaque)
MirrorExitData *data = opaque;
AioContext *replace_aio_context = NULL;
+bdrv_op_unblock(s-common.bs,
On 08/06/2015 12:34, Fam Zheng wrote:
- unmap: whether the target sectors should be discarded where source has
only
zeroes. (json-bool, optional, default true)
+- detect-zeroes: if true, the source sectors that are zeroes will be
written as
+ sparse on target. (json-bool, optional,
On 08/06/2015 16:51, Eric Blake wrote:
+# @unmap: #optional Whether to try to unmap target sectors where source
has
+# only zero. If true, and target unallocated sectors will read as
zero,
+# target image sectors will be unmapped; otherwise, zeroes will be
+#
On 08/06/2015 16:17, Eric Blake wrote:
+
+if (detect_zeroes == BLOCKDEV_DETECT_ZEROES_OPTIONS_UNMAP
+!(bdrv_flags BDRV_O_UNMAP)) {
+error_setg(errp, setting detect-zeroes to unmap is not allowed
+ without setting discard operation to
On 02/06/2015 18:43, ronnie sahlberg wrote:
If we change this to iSCSI, we can actually avoid this by using task
management functions:
guest - QEMUwrite A to sector 1
QEMU - iSCSIwrite A to sector 1
... timeout...
QEMU - iSCSI task management:
() on it in virtio_blk_reset().
Cc: Christian Borntraeger borntrae...@de.ibm.com
Cc: Cornelia Huck cornelia.h...@de.ibm.com
Cc: Kevin Wolf kw...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Alexander Yarygin yary...@linux.vnet.ibm.com
On 25/06/2015 20:07, Programmingkid wrote:
I honestly think it is in the right place. The function find_image_format()
is doing just that - trying to find the format. The image part of the
function's name
does bother me. But we could ignore it. Since we know it is a real cdrom
drive,
it
Ping?
Paolo
On 28/05/2015 16:17, Paolo Bonzini wrote:
bdrv_close already does that, and in fact hmp_drive_del would need
another drain after the flush (which bdrv_close does). So remove
the duplication.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
blockdev.c | 3 ---
1 file
Kevin, can you queue this patch for 2.4?
Paolo
On 29/05/2015 12:53, Fam Zheng wrote:
There callers work on a single BlockDriverState subtree, where using
bdrv_drain() is more accurate.
Signed-off-by: Fam Zheng f...@redhat.com
---
block.c | 6 +++---
block/snapshot.c | 2 +-
On 25/06/2015 17:32, Programmingkid wrote:
I think we are going to have to agree to disagree. I have never
used the /dev/sr(0 | 1) devices and don't see how they would be
effected by this patch. Are you trying to say the /dev/sr(0 | 1)
devices *should* be handled by this patch?
Thinking
On 25/06/2015 18:12, Laurent Vivier wrote:
On 25/06/2015 17:48, Paolo Bonzini wrote:
On 25/06/2015 17:32, Programmingkid wrote:
I think we are going to have to agree to disagree. I have never
used the /dev/sr(0 | 1) devices and don't see how they would be
effected by this patch
On 25/06/2015 19:56, Programmingkid wrote:
In fact, programmingkid, you should fix it in hdev_open() where
there is already a #if __APPLE__ .
Nice to hear from you again Laurent. The only way a solution in
hdev_open() would work is if it could prevent find_image_format()
from executing.
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.
On 23/06/2015 11:00, Markus Armbruster wrote:
My point is: the problem is more general than just block nodes. Doesn't
mean we mustn't solve the special problem unless we solve the general
problem. Does mean we should at least try to solve the general problem,
and if we fail, try our best
On 26/06/2015 12:08, Peter Lieven wrote:
RHEL7 and others are stuck with libiscsi 1.9.0 since there
unfortunately was an ABI breakage after that release.
Signed-off-by: Peter Lieven p...@kamp.de
---
block/iscsi.c | 31 ++-
configure |6 +++---
On 25/06/2015 23:21, Peter Lieven wrote:
I will send a v2 that is compatible with 1.9.0 and enables the timeout
stuff only for libiscsi = 1.15.0
Since Stefan has already applied the patch, restoring 1.9.0
compatibility (and disabling timeouts between 1.9.0 and 1.14.x) on top
of this patch
On 27/05/2015 09:19, Fam Zheng wrote:
This series looks at the other side of the broken qmp transaction problem
with dataplane [1] - the event loop.
Before, an ioeventfd of a non-dataplane device is registered via
qemu_set_fd_handler, which is only polled directly by main_loop_wait(), not
On 27/05/2015 11:07, Kevin Wolf wrote:
This is the first part of what's troubling me with this series, as it
makes me doubtful if op blockers are the right tool to implement what
the commit message says (block device I/O). This is are we doing the
thing right?
The second part should
On 27/05/2015 12:10, Kevin Wolf wrote:
Am 27.05.2015 um 11:50 hat Paolo Bonzini geschrieben:
On 27/05/2015 11:07, Kevin Wolf wrote:
This is the first part of what's troubling me with this series, as it
makes me doubtful if op blockers are the right tool to implement what
the commit
(QEMUFile *f,
BlkMigDevState *bmds,
blk_mig_lock();
if (bmds_aio_inflight(bmds, sector)) {
blk_mig_unlock();
-bdrv_drain_all();
+bdrv_drain(bmds-bs);
} else {
blk_mig_unlock();
}
Reviewed-by: Paolo
On 29/05/2015 12:53, Fam Zheng wrote:
Signed-off-by: Fam Zheng f...@redhat.com
---
blockdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/blockdev.c b/blockdev.c
index 5eaf77e..46f8d60 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1262,6 +1262,7 @@ typedef struct
On 13/05/2015 18:46, Denis V. Lunev wrote:
I agree with this. Kernel guys are aware and may be we will have
the fix after a while... I have heard (not tested) that performance
loss over multi-queue SSD is around 30%.
I came up with this patch... can you test it with your test case
(and old
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/06/2015 12:34, Dmitry Monakhov wrote:
Yes. Improvement is not huge, but it can be detected for old qemu
unpatched kernel: 728 MiB/sec ± 20Mb patched kernel : 748 MiB/sec
± 10Mb
Ok, so about 3-4%. What does the blktrace look like with
On 27/05/2015 15:30, Kevin Wolf wrote:
So it would be even more important to figure out what to do with
bdrv_swap().
Paolo, you added that bunch of assertions to bdrv_swap() when you
introduced it in commit 4ddc07ca. Did you just add them because they
were true at the time, or is anything
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
block/mirror.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/block/mirror.c b/block/mirror.c
index 85995b2..ba33254 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -164,6 +164,8 @@ static uint64_t
/tests/qemu-iotests/group
@@ -129,4 +129,5 @@
129 rw auto quick
130 rw auto quick
131 rw auto quick
+132 rw auto quick
134 rw auto quick
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
='BLOCK_JOB_READY', match=f)
def wait_ready_and_cancel(self, drive='drive0'):
self.wait_ready(drive=drive)
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Fam Zheng f...@redhat.com
On 28/05/2015 04:49, Fam Zheng wrote:
On a second thought, although in this series, we only need to modify
virtio-{scsi,blk}, Wen pointed out that mirror job also wants this during
completion (because bdrv_swap is in a BH after the job coroutine returns).
Mirror needs to pause/resume the
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone else should be okay, because the bottom half runs
immediately and the big QEMU lock is not released in the
On 28/05/2015 13:44, Fam Zheng wrote:
The reason for doing it in the block layer is that it's in one place and
we can be sure that it's applied. We can still in addition modify
specific users to avoid even trying to send requests, but I think it's
good to have the single place that
On 28/05/2015 12:46, Fam Zheng wrote:
Mirror needs to pause/resume the source. It doesn't need to handle
pause/resume of the target, does it?
So, in order for the solution to be general, and complete, this
nofitier list
approach relies on the listening devices to do the
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Sorry, I'm confused. Do you mean there is a way to implement blk_pause
completely in block
On 28/05/2015 13:24, Kevin Wolf wrote:
Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben:
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed to
aio_poll(), then would this idea work?
I think it's a bad idea to
On 28/05/2015 13:49, Fam Zheng wrote:
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:16, Fam Zheng wrote:
On 28/05/2015 03:46, Fam Zheng wrote:
The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed
bdrv_close already does that, and in fact hmp_drive_del would need
another drain after the flush (which bdrv_close does). So remove
the duplication.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
blockdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
nothing for that.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
blockdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index d506a70..aee0395 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2355,9 +2355,6 @@ void qmp_block_commit(const char *device
On 28/05/2015 14:26, Fam Zheng wrote:
Right, but the two sets of iohandlers are stored in different places, so
it's obvious that you don't execute all of them. On the other hand,
examining global state in aio_poll is really bad.
OK.
Would moving the ioeventfds to a new
1 - 100 of 2713 matches
Mail list logo
