[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 14/19] block: insert event-tap to bdrv_aio_write
From: |
Yoshiaki Tamura |
Subject: |
Re: [Qemu-devel] [PATCH 14/19] block: insert event-tap to bdrv_aio_writev() and bdrv_aio_flush(). |
Date: |
Thu, 20 Jan 2011 14:01:05 +0900 |
2011/1/19 Kevin Wolf <address@hidden>:
> Am 19.01.2011 14:16, schrieb Yoshiaki Tamura:
>> 2011/1/19 Kevin Wolf <address@hidden>:
>>> Am 19.01.2011 06:44, schrieb Yoshiaki Tamura:
>>>> event-tap function is called only when it is on, and requests sent
>>>> from device emulators.
>>>>
>>>> Signed-off-by: Yoshiaki Tamura <address@hidden>
>>>> ---
>>>> block.c | 11 +++++++++++
>>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/block.c b/block.c
>>>> index ff2795b..85bd8b8 100644
>>>> --- a/block.c
>>>> +++ b/block.c
>>>> @@ -28,6 +28,7 @@
>>>> #include "block_int.h"
>>>> #include "module.h"
>>>> #include "qemu-objects.h"
>>>> +#include "event-tap.h"
>>>>
>>>> #ifdef CONFIG_BSD
>>>> #include <sys/types.h>
>>>> @@ -2111,6 +2112,11 @@ BlockDriverAIOCB *bdrv_aio_writev(BlockDriverState
>>>> *bs, int64_t sector_num,
>>>> if (bdrv_check_request(bs, sector_num, nb_sectors))
>>>> return NULL;
>>>>
>>>> + if (bs->device_name && event_tap_is_on()) {
>>>> + return event_tap_bdrv_aio_writev(bs, sector_num, qiov, nb_sectors,
>>>> + cb, opaque);
>>>> + }
>>>> +
>>>> if (bs->dirty_bitmap) {
>>>> blk_cb_data = blk_dirty_cb_alloc(bs, sector_num, nb_sectors, cb,
>>>> opaque);
>>>
>>> Just noticed the context here... Does this patch break block migration
>>> when event-tap is on?
>>
>> I don't think so. event-tap will call bdrv_aio_writev() upon
>> flushing requests and it shouldn't affect block-migration. The
>> block written after the synchronization should be marked as dirty
>> and should be sent in the next round. Am I missing the point?
>
> No, that makes sense. I don't have a complete understanding of the whole
> series yet, so there may be well more misunderstandings on my side.
It's OK. I'm glad that you're reviewing.
>>> Another question that came to my mind is if we really hook everything we
>>> need. I think we'll need to have a hook in bdrv_flush as well. I don't
>>> know if you do hook qemu_aio_flush and friends - does a call cause
>>> event-tap to flush its queue? If not, a call to qemu_aio_flush might
>>> hang qemu because it's waiting for requests to complete which are
>>> actually stuck in the event-tap queue.
>>
>> No it doesn't queue at event-tap. Marcelo pointed that we should
>> hook bdrv_aio_flush to avoid requests inversion, that made sense
>> to me. Do we need to hook bdrv_flush for that same reason? If
>
> bdrv_flush() is the synchronous version of bdrv_aio_flush(), so in
> general it seems likely that we need to do the same.
Hmm. Because it's synchronous, we need to start synchronization
right away, and once done, flush requests queued in event-tap
then return.
>> we hook bdrv_flush and qemu_aio_flush, we're going loop forever
>> because the synchronization code is calling vm_stop that call
>> bdrv_flush_all and qemu_aio_flush.
>
> qemu_aio_flush doesn't invoke any bdrv_* functions, so I don't see why
> we would loop forever. It just waits for AIO requests to complete.
>
> I just looked up the code and I think the situation is a bit different
> than I thought originally: qemu_aio_flush waits only for completion of
> requests which belong to a driver that has registered using
> qemu_aio_set_fd_handler. So this means that AIO requests queued in
> event-tap are not considered in-flight requests and we won't get stuck
> in a loop. Maybe we have no problem in fact. :-)
I had the same thoughts. We don't have to hook qemu_aio_flush.
> On the other hand, e.g. migration relies on the fact that after a
> qemu_aio_flush, all AIO requests that the device model has submitted are
> completed. I think event-tap must take care that the requests which are
> queued are not forgotten to be migrated. (Maybe the code already
> considers this, I'm just writing down what comes to my mind...)
That's where event-tap is calling qemu_aio_flush. It should be
almost same as for live migration. Requests queued in event-tap
are replayed on the secondary side, that is the core design of
Kemari.
Thanks,
Yoshi
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- [Qemu-devel] [PATCH 15/19] savevm: introduce qemu_savevm_trans_{begin, commit}., (continued)
- [Qemu-devel] [PATCH 15/19] savevm: introduce qemu_savevm_trans_{begin, commit}., Yoshiaki Tamura, 2011/01/19
- [Qemu-devel] [PATCH 03/19] Introduce skip_header parameter to qemu_loadvm_state()., Yoshiaki Tamura, 2011/01/19
- [Qemu-devel] [PATCH 04/19] qemu-char: export socket_set_nodelay()., Yoshiaki Tamura, 2011/01/19
- [Qemu-devel] [PATCH 12/19] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c., Yoshiaki Tamura, 2011/01/19
- [Qemu-devel] [PATCH 14/19] block: insert event-tap to bdrv_aio_writev() and bdrv_aio_flush()., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 18/19] Introduce -k option to enable FT migration mode (Kemari)., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 17/19] migration-tcp: modify tcp_accept_incoming_migration() to handle ft_mode, and add a hack not to close fd when ft_mode is enabled., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 16/19] migration: introduce migrate_ft_trans_{put, get}_ready(), and modify migrate_fd_put_ready() when ft_mode is on., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 11/19] ioport: insert event_tap_ioport() to ioport_write()., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 19/19] migration: add a parser to accept FT migration incoming mode., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 10/19] Call init handler of event-tap at main() in vl.c., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 02/19] Introduce read() to FdMigrationState., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 01/19] Make QEMUFile buf expandable, and introduce qemu_realloc_buffer() and qemu_clear_buffer()., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 08/19] savevm: introduce util functions to control ft_trans_file from savevm layer., Yoshiaki Tamura, 2011/01/19
[Qemu-devel] [PATCH 07/19] Introduce fault tolerant VM transaction QEMUFile and ft_mode., Yoshiaki Tamura, 2011/01/19