[Qemu-devel] [PULL 0/2] virtio-9p fixes for 2.5

[Qemu-devel] [PULL 0/2] virtio-9p fixes for 2.5

[Greg Kurz]

The following changes since commit 714487515dbe0c65d5904251e796cd3a5b3579fb:

  Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging (2015-11-27 10:44:42 +0000)

are available in the git repository at:

  https://github.com/gkurz/qemu.git tags/for-upstream

for you to fetch changes up to ebac1202c95a4f1b76b6ef3f0f63926fa76e753e:

  virtio-9p: use QEMU thread pool (2015-11-30 12:36:12 +0100)

----------------------------------------------------------------
Two fixes for virtfs/9p from Paolo.

----------------------------------------------------------------
Paolo Bonzini (2):
      fsdev-proxy-helper: avoid TOC/TOU race
      virtio-9p: use QEMU thread pool

 fsdev/virtfs-proxy-helper.c | 20 ++++++-------
 hw/9pfs/virtio-9p-coth.c    | 69 +++++++++------------------------------------
 hw/9pfs/virtio-9p-coth.h    | 10 +------
 hw/9pfs/virtio-9p-device.c  |  4 ---
 4 files changed, 25 insertions(+), 78 deletions(-)
-- 
2.4.3

[Qemu-devel] [PULL 1/2] fsdev-proxy-helper: avoid TOC/TOU race

[Greg Kurz]

From: Paolo Bonzini <pbonzini@redhat.com>

There is a minor time of check/time of use race between statfs and chroot.
It can be fixed easily by stat-ing the root after it has been changed.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
 fsdev/virtfs-proxy-helper.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 9097d15c989c..ad1da0d6f530 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -1128,10 +1128,19 @@ int main(int argc, char **argv)
         }
     }
 
+    if (chdir("/") < 0) {
+        do_perror("chdir");
+        goto error;
+    }
+    if (chroot(rpath) < 0) {
+        do_perror("chroot");
+        goto error;
+    }
+
     get_version = false;
 #ifdef FS_IOC_GETVERSION
     /* check whether underlying FS support IOC_GETVERSION */
-    retval = statfs(rpath, &st_fs);
+    retval = statfs("/", &st_fs);
     if (!retval) {
         switch (st_fs.f_type) {
         case EXT2_SUPER_MAGIC:
@@ -1144,16 +1153,7 @@ int main(int argc, char **argv)
     }
 #endif
 
-    if (chdir("/") < 0) {
-        do_perror("chdir");
-        goto error;
-    }
-    if (chroot(rpath) < 0) {
-        do_perror("chroot");
-        goto error;
-    }
     umask(0);
-
     if (init_capabilities() < 0) {
         goto error;
     }
-- 
2.4.3

[Qemu-devel] [PULL 2/2] virtio-9p: use QEMU thread pool

[Greg Kurz]

From: Paolo Bonzini <pbonzini@redhat.com>

The QEMU thread pool already has a mechanism to invoke callbacks in the main
thread.  It does not need an EventNotifier and it is more efficient too.
Use it instead of GAsyncQueue + GThreadPool + glue.

As a side effect, it silences Coverity's complaint about an unchecked
return value for event_notifier_init.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
(removed no more needed #include <glib.h> from virtio-9p-coth.h)
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
 hw/9pfs/virtio-9p-coth.c   | 69 ++++++++++------------------------------------
 hw/9pfs/virtio-9p-coth.h   | 10 +------
 hw/9pfs/virtio-9p-device.c |  4 ---
 3 files changed, 15 insertions(+), 68 deletions(-)

diff --git a/hw/9pfs/virtio-9p-coth.c b/hw/9pfs/virtio-9p-coth.c
index 5057f8d220df..fb6e8f80e0f4 100644
--- a/hw/9pfs/virtio-9p-coth.c
+++ b/hw/9pfs/virtio-9p-coth.c
@@ -12,71 +12,30 @@
  *
  */
 
-#include "fsdev/qemu-fsdev.h"
-#include "qemu/thread.h"
-#include "qemu/event_notifier.h"
+#include "qemu-common.h"
+#include "block/thread-pool.h"
 #include "qemu/coroutine.h"
+#include "qemu/main-loop.h"
 #include "virtio-9p-coth.h"
 
-/* v9fs glib thread pool */
-static V9fsThPool v9fs_pool;
-
-void co_run_in_worker_bh(void *opaque)
+/* Called from QEMU I/O thread.  */
+static void coroutine_enter_cb(void *opaque, int ret)
 {
     Coroutine *co = opaque;
-    g_thread_pool_push(v9fs_pool.pool, co, NULL);
-}
-
-static void v9fs_qemu_process_req_done(EventNotifier *e)
-{
-    Coroutine *co;
-
-    event_notifier_test_and_clear(e);
-
-    while ((co = g_async_queue_try_pop(v9fs_pool.completed)) != NULL) {
-        qemu_coroutine_enter(co, NULL);
-    }
+    qemu_coroutine_enter(co, NULL);
 }
 
-static void v9fs_thread_routine(gpointer data, gpointer user_data)
+/* Called from worker thread.  */
+static int coroutine_enter_func(void *arg)
 {
-    Coroutine *co = data;
-
+    Coroutine *co = arg;
     qemu_coroutine_enter(co, NULL);
-
-    g_async_queue_push(v9fs_pool.completed, co);
-
-    event_notifier_set(&v9fs_pool.e);
+    return 0;
 }
 
-int v9fs_init_worker_threads(void)
+void co_run_in_worker_bh(void *opaque)
 {
-    int ret = 0;
-    V9fsThPool *p = &v9fs_pool;
-    sigset_t set, oldset;
-
-    sigfillset(&set);
-    /* Leave signal handling to the iothread.  */
-    pthread_sigmask(SIG_SETMASK, &set, &oldset);
-
-    p->pool = g_thread_pool_new(v9fs_thread_routine, p, -1, FALSE, NULL);
-    if (!p->pool) {
-        ret = -1;
-        goto err_out;
-    }
-    p->completed = g_async_queue_new();
-    if (!p->completed) {
-        /*
-         * We are going to terminate.
-         * So don't worry about cleanup
-         */
-        ret = -1;
-        goto err_out;
-    }
-    event_notifier_init(&p->e, 0);
-
-    event_notifier_set_handler(&p->e, v9fs_qemu_process_req_done);
-err_out:
-    pthread_sigmask(SIG_SETMASK, &oldset, NULL);
-    return ret;
+    Coroutine *co = opaque;
+    thread_pool_submit_aio(qemu_get_aio_context()->thread_pool,
+                           coroutine_enter_func, co, coroutine_enter_cb, co);
 }
diff --git a/hw/9pfs/virtio-9p-coth.h b/hw/9pfs/virtio-9p-coth.h
index 0fbe49a94615..4ac1aaf90292 100644
--- a/hw/9pfs/virtio-9p-coth.h
+++ b/hw/9pfs/virtio-9p-coth.h
@@ -18,14 +18,6 @@
 #include "qemu/thread.h"
 #include "qemu/coroutine.h"
 #include "virtio-9p.h"
-#include <glib.h>
-
-typedef struct V9fsThPool {
-    EventNotifier e;
-
-    GThreadPool *pool;
-    GAsyncQueue *completed;
-} V9fsThPool;
 
 /*
  * we want to use bottom half because we want to make sure the below
@@ -45,7 +37,7 @@ typedef struct V9fsThPool {
         qemu_bh_schedule(co_bh);                                        \
         /*                                                              \
          * yield in qemu thread and re-enter back                       \
-         * in glib worker thread                                        \
+         * in worker thread                                             \
          */                                                             \
         qemu_coroutine_yield();                                         \
         qemu_bh_delete(co_bh);                                          \
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index e3abcfaffb2a..944b5f5e9fcc 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -116,10 +116,6 @@ static void virtio_9p_device_realize(DeviceState *dev, Error **errp)
                    " and export path:%s", s->fsconf.fsdev_id, s->ctx.fs_root);
         goto out;
     }
-    if (v9fs_init_worker_threads() < 0) {
-        error_setg(errp, "worker thread initialization failed");
-        goto out;
-    }
 
     /*
      * Check details of export path, We need to use fs driver
-- 
2.4.3

Re: [Qemu-devel] [PULL 0/2] virtio-9p fixes for 2.5

[Peter Maydell]

On 30 November 2015 at 16:11, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> The following changes since commit 714487515dbe0c65d5904251e796cd3a5b3579fb:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging (2015-11-27 10:44:42 +0000)
>
> are available in the git repository at:
>
>   https://github.com/gkurz/qemu.git tags/for-upstream
>
> for you to fetch changes up to ebac1202c95a4f1b76b6ef3f0f63926fa76e753e:
>
>   virtio-9p: use QEMU thread pool (2015-11-30 12:36:12 +0100)
>
> ----------------------------------------------------------------
> Two fixes for virtfs/9p from Paolo.
>
> ----------------------------------------------------------------
> Paolo Bonzini (2):
>       fsdev-proxy-helper: avoid TOC/TOU race
>       virtio-9p: use QEMU thread pool

Applied, thanks. If you're in a position to meet face-to-face
with any other QEMU developers and do the check-official-identity
and sign GPG keys, that would be cool -- your GPG key doesn't
really seem to be signed by many other people at the moment.

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/2] virtio-9p fixes for 2.5

[Greg Kurz]

On Tue, 1 Dec 2015 16:30:09 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 30 November 2015 at 16:11, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> > The following changes since commit 714487515dbe0c65d5904251e796cd3a5b3579fb:
> >
> >   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging (2015-11-27 10:44:42 +0000)
> >
> > are available in the git repository at:
> >
> >   https://github.com/gkurz/qemu.git tags/for-upstream
> >
> > for you to fetch changes up to ebac1202c95a4f1b76b6ef3f0f63926fa76e753e:
> >
> >   virtio-9p: use QEMU thread pool (2015-11-30 12:36:12 +0100)
> >
> > ----------------------------------------------------------------
> > Two fixes for virtfs/9p from Paolo.
> >
> > ----------------------------------------------------------------
> > Paolo Bonzini (2):
> >       fsdev-proxy-helper: avoid TOC/TOU race
> >       virtio-9p: use QEMU thread pool
> 
> Applied, thanks. If you're in a position to meet face-to-face
> with any other QEMU developers and do the check-official-identity
> and sign GPG keys, that would be cool -- your GPG key doesn't
> really seem to be signed by many other people at the moment.
> 

Hi Peter,

I understand there are key signing parties during KVM Forum and other public
events. Apart from that, I am not sure if I can easily reach out to other
developers from my location (Toulouse, France). I'll do my best ! :)

Thanks.

--
Greg

> thanks
> -- PMM
>