2011/1/19 Kevin Wolf <kw...@redhat.com>:
> 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 <tamura.yoshi...@lab.ntt.co.jp>
>> ---
>>  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?

> 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
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.

Yoshi

>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to