[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 08/22] iscsi: implement .bdrv_detach/attach_aio_

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 08/22] iscsi: implement .bdrv_detach/attach_aio_context()
Date: Wed, 07 May 2014 12:29:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Il 07/05/2014 12:07, Stefan Hajnoczi ha scritto:
On Fri, May 02, 2014 at 12:39:06AM +0200, Peter Lieven wrote:
+static void iscsi_attach_aio_context(BlockDriverState *bs,
+                                     AioContext *new_context)
+    IscsiLun *iscsilun = bs->opaque;
+    iscsilun->aio_context = new_context;
+    iscsi_set_events(iscsilun);
+    /* Set up a timer for sending out iSCSI NOPs */
+    iscsilun->nop_timer = aio_timer_new(iscsilun->aio_context,
+                                        QEMU_CLOCK_REALTIME, SCALE_MS,
+                                        iscsi_nop_timed_event, iscsilun);
+    timer_mod(iscsilun->nop_timer,
+              qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + NOP_INTERVAL);

Is it still guaranteed that iscsi_nop_timed_event for a target is not invoked
while we are in another function/callback of the iscsi driver for the same 

Yes, since the timer is in the same AioContext as the iscsi driver callbacks.

This is a good point.

Previously, the nop timer was deferred until the qemu_aio_wait() loop

With this patch the nop timer fires during aio_poll() loops for any
synchronous emulation that QEMU does (including iscsi_aio_cancel() and
.bdrv_ioctl() in block/iscsi.c).

I don't know libiscsi well enough to understand the implications.  I can
see that iscsi_reconnect() resends in-flight commands.  So what's the
upshot of all this?

I think it's fine. The target will process NOPs asynchronously, so iscsi_nop_timed_event will see no NOP in flight if the target is working properly.

BTW, is iscsi_reconnect() the right libiscsi interface to use since it
is synchronous?  It seems like this would block QEMU until the socket
has connected!  The guest would be frozen.

There is no asynchronous interface yet for reconnection, unfortunately.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]