From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767509; cv=none; d=zohomail.com; s=zohoarc; b=EjbmY4J67SjSVhxUYLfZJxEgp6wrYXd6pNQbgqMnDHw4AtuFynPOsMl8piYrI8+iGrck/hpINq3OIw0lRWsqxNFclioO1xcEhK9tEwq5waneJYcY3L3h6reQnL8bBVFwgsV7PQirXiNOmeEfsWUZyXL+4Xxjd+yWXCminkue010= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767509; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=esp89t+fnW0drKd/fLhhDwaAuTU2hKERPQRnJ2oRD4g=; b=IUy8mLxOn+xyU92lleANpqNdctaRnYR2ktkHZPO/atoU15wswwtq/NryEFaYCuSTZQykpwph1Xngj/4HomNXTNluGa4XAmpuZEs39yhLnvUdBt2ZcDfl0xD4cnQBE7a3mE5Gs9JBkq1TitFc8IgVuwp3ImmoOWFJAOO14VcK460= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767509562605.132994362133; Thu, 23 Jan 2020 00:18:29 -0800 (PST) Received: from localhost ([::1]:52724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXh4-0003EZ-Gu for importer@patchew.org; Thu, 23 Jan 2020 03:18:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53328) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfw-00020a-T1 for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005lE-K9 for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:16 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35492 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005ia-DE for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXfs-00FGF5-H1; Thu, 23 Jan 2020 09:17:12 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 1/6] libvhost-user: implement VHOST_USER_PROTOCOL_F_REPLY_ACK Date: Thu, 23 Jan 2020 09:17:03 +0100 Message-Id: <20200123081708.7817-2-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stefan Hajnoczi , Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Johannes Berg This is really simple, since we know whether a response is already requested or not, so we can just send a (successful) response when there isn't one already. Given that, it's not all _that_ useful but the master can at least be sure the message was processed, and we can exercise more code paths using the example code. Reviewed-by: Stefan Hajnoczi Signed-off-by: Johannes Berg --- contrib/libvhost-user/libvhost-user.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/= libvhost-user.c index ec27b78ff108..8cc3054fd510 100644 --- a/contrib/libvhost-user/libvhost-user.c +++ b/contrib/libvhost-user/libvhost-user.c @@ -1168,7 +1168,8 @@ vu_get_protocol_features_exec(VuDev *dev, VhostUserMs= g *vmsg) 1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD | 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_REQ | 1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER | - 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD; + 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD | + 1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK; =20 if (have_userfault()) { features |=3D 1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT; @@ -1550,13 +1551,20 @@ vu_dispatch(VuDev *dev) { VhostUserMsg vmsg =3D { 0, }; int reply_requested; - bool success =3D false; + bool need_reply, success =3D false; =20 if (!vu_message_read(dev, dev->sock, &vmsg)) { goto end; } =20 + need_reply =3D vmsg.flags & VHOST_USER_NEED_REPLY_MASK; + reply_requested =3D vu_process_message(dev, &vmsg); + if (!reply_requested && need_reply) { + vmsg_set_reply_u64(&vmsg, 0); + reply_requested =3D 1; + } + if (!reply_requested) { success =3D true; goto end; --=20 2.24.1 From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767523; cv=none; d=zohomail.com; s=zohoarc; b=dXI7FsqrqCP2u+jiUaDJMb2RNaUu7ecBcvahQfbR+/3WKSBNhJLGjfH3s3yaIBLOKIpQST5T9/u68UW4B5HK8cnvhaLnaoBgP6z73nVtKnjzlU0MBxF8PBEgKwILS+WNv7KioQFWSifAqbOFvWLCjc2ZJCQ10SwQ4l+vLuDAxhc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767523; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=FKhys9QfeqMlX6fJTd37kfsD5zoYjdjs45z5CM3B2Oc=; b=ELcSiet+diKttF3EELYAmxLLC27sngWxc0FLju+EUBCsdNQj9kdRd9/zCvFb+wqgdPd6ekZiGpob+hBJ90sToMI1Wjic5Ex6hs1u2iDxqoGmRtJRhJ56ectjZdPi79tjd1JPLTey3gQGhGeyVwM7NP9Y0TEvY78qH0Gbh/Z7Gh4= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767523716944.1658396286866; Thu, 23 Jan 2020 00:18:43 -0800 (PST) Received: from localhost ([::1]:52728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXhK-0003Vh-EL for importer@patchew.org; Thu, 23 Jan 2020 03:18:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53329) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfw-00020b-TB for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005l8-Jn for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:16 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35496 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005im-CQ for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXft-00FGF5-01; Thu, 23 Jan 2020 09:17:13 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 2/6] libvhost-user-glib: fix VugDev main fd cleanup Date: Thu, 23 Jan 2020 09:17:04 +0100 Message-Id: <20200123081708.7817-3-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" From: Johannes Berg If you try to make a device implementation that can handle multiple connections and allow disconnections (which requires overriding the VHOST_USER_NONE handling), then glib will warn that we remove a src while it's still on the mainloop, and will poll() an FD that doesn't exist anymore. Fix this by making vug_source_new() require pairing with the new vug_source_destroy() so we can keep the GSource referenced in the meantime. Note that this requires calling the new API in vhost-user-input. vhost-user-gpu also uses vug_source_new(), but never seems to free the result at all, so I haven't changed anything there. Fixes: 8bb7ddb78a1c ("libvhost-user: add glib source helper") Reviewed-by: Marc-Andr=C3=A9 Lureau Signed-off-by: Johannes Berg --- contrib/libvhost-user/libvhost-user-glib.c | 15 ++++++++++++--- contrib/libvhost-user/libvhost-user-glib.h | 1 + contrib/vhost-user-input/main.c | 6 ++---- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user-glib.c b/contrib/libvhost-= user/libvhost-user-glib.c index 99edd2f3de45..824c7780de61 100644 --- a/contrib/libvhost-user/libvhost-user-glib.c +++ b/contrib/libvhost-user/libvhost-user-glib.c @@ -91,7 +91,6 @@ vug_source_new(VugDev *gdev, int fd, GIOCondition cond, g_source_add_poll(gsrc, &src->gfd); id =3D g_source_attach(gsrc, NULL); g_assert(id); - g_source_unref(gsrc); =20 return gsrc; } @@ -131,6 +130,16 @@ static void vug_watch(VuDev *dev, int condition, void = *data) } } =20 +void vug_source_destroy(GSource *src) +{ + if (!src) { + return; + } + + g_source_destroy(src); + g_source_unref(src); +} + bool vug_init(VugDev *dev, uint16_t max_queues, int socket, vu_panic_cb panic, const VuDevIface *iface) @@ -144,7 +153,7 @@ vug_init(VugDev *dev, uint16_t max_queues, int socket, } =20 dev->fdmap =3D g_hash_table_new_full(NULL, NULL, NULL, - (GDestroyNotify) g_source_destroy); + (GDestroyNotify) vug_source_destroy= ); =20 dev->src =3D vug_source_new(dev, socket, G_IO_IN, vug_watch, NULL); =20 @@ -157,5 +166,5 @@ vug_deinit(VugDev *dev) g_assert(dev); =20 g_hash_table_unref(dev->fdmap); - g_source_unref(dev->src); + vug_source_destroy(dev->src); } diff --git a/contrib/libvhost-user/libvhost-user-glib.h b/contrib/libvhost-= user/libvhost-user-glib.h index 64d539d93aba..1a79a4916ef2 100644 --- a/contrib/libvhost-user/libvhost-user-glib.h +++ b/contrib/libvhost-user/libvhost-user-glib.h @@ -31,5 +31,6 @@ void vug_deinit(VugDev *dev); =20 GSource *vug_source_new(VugDev *dev, int fd, GIOCondition cond, vu_watch_cb vu_cb, gpointer data); +void vug_source_destroy(GSource *src); =20 #endif /* LIBVHOST_USER_GLIB_H */ diff --git a/contrib/vhost-user-input/main.c b/contrib/vhost-user-input/mai= n.c index ef4b7769f285..6020c6f33a46 100644 --- a/contrib/vhost-user-input/main.c +++ b/contrib/vhost-user-input/main.c @@ -187,7 +187,7 @@ vi_queue_set_started(VuDev *dev, int qidx, bool started) } =20 if (!started && vi->evsrc) { - g_source_destroy(vi->evsrc); + vug_source_destroy(vi->evsrc); vi->evsrc =3D NULL; } } @@ -401,9 +401,7 @@ main(int argc, char *argv[]) =20 vug_deinit(&vi.dev); =20 - if (vi.evsrc) { - g_source_unref(vi.evsrc); - } + vug_source_destroy(vi.evsrc); g_array_free(vi.config, TRUE); g_free(vi.queue); return 0; --=20 2.24.1 From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767510; cv=none; d=zohomail.com; s=zohoarc; b=gxY3LFsgul25rC41o9fU2TFkGANcjbjjuvzn6TszjeONa1ahPvfd/di58u+8o/20eWd4IVtmdl3B1Xn881zHVh2Jhk68EyraAexMDJRpwb7UgYMrZHz+4qCwso3juPe1Rs6S+vq5tTmC4YZhSeXbitn/NgipqgrVqdFnIeCqn6Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767510; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=wUGc+0Sdn0g5XvLAyX+/FlqlU/qbfhtAa8e/K0/soJo=; b=IsZlz1snfSG9rfuev5LFmpmkM5dOypJ3gB1C/m6+yU2Vd+WTJltcIv93OszfgVBssZMVaFxtjgOspAUHXARpsC4a2AQMH7JQktZdxANZDYxZsQN/mmcM0XK6iAzGiXK7LuazfbUjdFINh5FH3KSxEvdqf+SBFHRafkmQkhpe0Ko= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767510398568.0537836290235; Thu, 23 Jan 2020 00:18:30 -0800 (PST) Received: from localhost ([::1]:52726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXh6-0003HM-V3 for importer@patchew.org; Thu, 23 Jan 2020 03:18:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53322) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfw-00020Z-Nj for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005lK-LN for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:16 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35502 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005iz-EJ for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXft-00FGF5-Bb; Thu, 23 Jan 2020 09:17:13 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 3/6] libvhost-user-glib: use g_main_context_get_thread_default() Date: Thu, 23 Jan 2020 09:17:05 +0100 Message-Id: <20200123081708.7817-4-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Stefan Hajnoczi , Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" From: Johannes Berg If we use NULL, we just get the main program default mainloop here. Using g_main_context_get_thread_default() has basically the same effect, but it lets us start different devices in different threads with different mainloops, which can be useful. Reviewed-by: Stefan Hajnoczi Reviewed-by: Marc-Andr=C3=A9 Lureau Signed-off-by: Johannes Berg --- contrib/libvhost-user/libvhost-user-glib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/libvhost-user/libvhost-user-glib.c b/contrib/libvhost-= user/libvhost-user-glib.c index 824c7780de61..53f1ca4cdd73 100644 --- a/contrib/libvhost-user/libvhost-user-glib.c +++ b/contrib/libvhost-user/libvhost-user-glib.c @@ -89,7 +89,7 @@ vug_source_new(VugDev *gdev, int fd, GIOCondition cond, src->gfd.events =3D cond; =20 g_source_add_poll(gsrc, &src->gfd); - id =3D g_source_attach(gsrc, NULL); + id =3D g_source_attach(gsrc, g_main_context_get_thread_default()); g_assert(id); =20 return gsrc; --=20 2.24.1 From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767703; cv=none; d=zohomail.com; s=zohoarc; b=aLrpRFNRTJ5TYQ4F3/dCxrkAlnUYXDt8WYfPbQv8YpF9PRgF4kILlSMqQmVpgG1misr/cxyUeV1VXUlqU/xexgU2oUUlSXw1I9r4PsuUXD8l8s5SJTM8dmnbW9R/CR3uERsmRBYFfrvyuv/+0SxCBSmmvyNVP0z1pvDJVpmXrzg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767703; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=p1CIq+vCvB9EkHGcNwHq1SYOdspl+bOix/AFmGONZBQ=; b=ZnHPz+7a7dFL/+N+bVWCWT/1jJnSk7tSz0BE+lxMFK/nhtNmnSSYSrtZbKrRrHkgcK0TtENnjEHx92uqFeXgDqKILtk3kSXoru4QjNu6tkP2OBVRZBjTczDzJKrvFaTXqCovA4UIBuvOa+/WZ7En6j9wciXGB22GWCru5EgxmNE= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767703388361.20829651911583; Thu, 23 Jan 2020 00:21:43 -0800 (PST) Received: from localhost ([::1]:52924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXkE-00083t-8H for importer@patchew.org; Thu, 23 Jan 2020 03:21:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53338) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfx-00020c-6A for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005lX-Mq for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:17 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35498 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005ix-EI for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXft-00FGF5-Kq; Thu, 23 Jan 2020 09:17:13 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 4/6] libvhost-user: handle NOFD flag in call/kick/err better Date: Thu, 23 Jan 2020 09:17:06 +0100 Message-Id: <20200123081708.7817-5-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Johannes Berg The code here is odd, for example will it print out invalid file descriptor numbers that were never sent in the message. Clean that up a bit so it's actually possible to implement a device that uses polling. Signed-off-by: Johannes Berg --- contrib/libvhost-user/libvhost-user.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/= libvhost-user.c index 8cc3054fd510..34d08e2fc4be 100644 --- a/contrib/libvhost-user/libvhost-user.c +++ b/contrib/libvhost-user/libvhost-user.c @@ -920,6 +920,7 @@ static bool vu_check_queue_msg_file(VuDev *dev, VhostUserMsg *vmsg) { int index =3D vmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK; + bool nofd =3D vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK; =20 if (index >=3D dev->max_queues) { vmsg_close_fds(vmsg); @@ -927,8 +928,12 @@ vu_check_queue_msg_file(VuDev *dev, VhostUserMsg *vmsg) return false; } =20 - if (vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK || - vmsg->fd_num !=3D 1) { + if (nofd) { + vmsg_close_fds(vmsg); + return true; + } + + if (vmsg->fd_num !=3D 1) { vmsg_close_fds(vmsg); vu_panic(dev, "Invalid fds in request: %d", vmsg->request); return false; @@ -1025,6 +1030,7 @@ static bool vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg) { int index =3D vmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK; + bool nofd =3D vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK; =20 DPRINT("u64: 0x%016"PRIx64"\n", vmsg->payload.u64); =20 @@ -1038,8 +1044,8 @@ vu_set_vring_kick_exec(VuDev *dev, VhostUserMsg *vmsg) dev->vq[index].kick_fd =3D -1; } =20 - dev->vq[index].kick_fd =3D vmsg->fds[0]; - DPRINT("Got kick_fd: %d for vq: %d\n", vmsg->fds[0], index); + dev->vq[index].kick_fd =3D nofd ? -1 : vmsg->fds[0]; + DPRINT("Got kick_fd: %d for vq: %d\n", dev->vq[index].kick_fd, index); =20 dev->vq[index].started =3D true; if (dev->iface->queue_set_started) { @@ -1116,6 +1122,7 @@ static bool vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vmsg) { int index =3D vmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK; + bool nofd =3D vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK; =20 DPRINT("u64: 0x%016"PRIx64"\n", vmsg->payload.u64); =20 @@ -1128,14 +1135,14 @@ vu_set_vring_call_exec(VuDev *dev, VhostUserMsg *vm= sg) dev->vq[index].call_fd =3D -1; } =20 - dev->vq[index].call_fd =3D vmsg->fds[0]; + dev->vq[index].call_fd =3D nofd ? -1 : vmsg->fds[0]; =20 /* in case of I/O hang after reconnecting */ - if (eventfd_write(vmsg->fds[0], 1)) { + if (dev->vq[index].call_fd !=3D -1 && eventfd_write(vmsg->fds[0], 1)) { return -1; } =20 - DPRINT("Got call_fd: %d for vq: %d\n", vmsg->fds[0], index); + DPRINT("Got call_fd: %d for vq: %d\n", dev->vq[index].call_fd, index); =20 return false; } @@ -1144,6 +1151,7 @@ static bool vu_set_vring_err_exec(VuDev *dev, VhostUserMsg *vmsg) { int index =3D vmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK; + bool nofd =3D vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK; =20 DPRINT("u64: 0x%016"PRIx64"\n", vmsg->payload.u64); =20 @@ -1156,7 +1164,7 @@ vu_set_vring_err_exec(VuDev *dev, VhostUserMsg *vmsg) dev->vq[index].err_fd =3D -1; } =20 - dev->vq[index].err_fd =3D vmsg->fds[0]; + dev->vq[index].err_fd =3D nofd ? -1 : vmsg->fds[0]; =20 return false; } --=20 2.24.1 From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767631; cv=none; d=zohomail.com; s=zohoarc; b=ayDSCLZrX6JyuaNXRdjnBKalXkJgQCRazZUsGzrGb1kfTq2SvibDr3vfKJIrcSiQcwoi/bmrkeNhsnatBfbdnGjsE3CtNKcqnUnpAgxLOTXwT55+3RGQDK7OM2WoYwV/Q4KttRUe1igcgSLAVWzhf4j7f4KrJEoJtibquzhMTT8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767631; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=742A5ZxY0bywW2dzFbY6yk5CwpQV2sQHx5rjKF7J25Q=; b=kr1tAkc9QDhrng+pZKqX1BwUQoZXnqjXUqahjY0DOOjKrGPUt8DJntLIRpkxGOphuHKg1UL0470iUXTSEuyjoQurPA4slEVwq2mv3Pcc1C6kF4VVBcqI47fX3/PPeEcEUpjRvpTw68KEEUaDJB7JF+v2sM3pFPnHVGqJKr5KVFQ= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767631446848.1531834356158; Thu, 23 Jan 2020 00:20:31 -0800 (PST) Received: from localhost ([::1]:52780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXj3-0006DU-TH for importer@patchew.org; Thu, 23 Jan 2020 03:20:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53375) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfy-000210-5e for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005lp-UH for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:18 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35506 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005jB-Na for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXft-00FGF5-Ue; Thu, 23 Jan 2020 09:17:14 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 5/6] docs: vhost-user: add in-band kick/call messages Date: Thu, 23 Jan 2020 09:17:07 +0100 Message-Id: <20200123081708.7817-6-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Johannes Berg For good reason, vhost-user is currently built asynchronously, that way better performance can be obtained. However, for certain use cases such as simulation, this is problematic. Consider an event-based simulation in which both the device and CPU have scheduled according to a simulation "calendar". Now, consider the CPU sending I/O to the device, over a vring in the vhost-user protocol. In this case, the CPU must wait for the vring interrupt to have been processed by the device, so that the device is able to put an entry onto the simulation calendar to obtain time to handle the interrupt. Note that this doesn't mean the I/O is actually done at this time, it just means that the handling of it is scheduled before the CPU can continue running. This cannot be done with the asynchronous eventfd based vring kick and call design. Extend the protocol slightly, so that a message can be used for kick and call instead, if VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS is negotiated. This in itself doesn't guarantee synchronisation, but both sides can also negotiate VHOST_USER_PROTOCOL_F_REPLY_ACK and thus get a reply to this message by setting the need_reply flag, and ensure synchronisation this way. To really use it in both directions, VHOST_USER_PROTOCOL_F_SLAVE_REQ is also needed. Since it is used for simulation purposes and too many messages on the socket can lock up the virtual machine, document that this should only be used together with the mentioned features. Signed-off-by: Johannes Berg --- docs/interop/vhost-user.rst | 122 ++++++++++++++++++++++++++++++------ 1 file changed, 104 insertions(+), 18 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 5f8b3a456b5e..401652397cac 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -2,6 +2,7 @@ Vhost-user Protocol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D :Copyright: 2014 Virtual Open Systems Sarl. +:Copyright: 2019 Intel Corporation :Licence: This work is licensed under the terms of the GNU GPL, version 2 or later. See the COPYING file in the top-level directory. @@ -279,6 +280,9 @@ If *master* is unable to send the full message or recei= ves a wrong reply it will close the connection. An optional reconnection mechanism can be implemented. =20 +If *slave* detects some error such as incompatible features, it may also +close the connection. This should only happen in exceptional circumstances. + Any protocol extensions are gated by protocol feature bits, which allows full backwards compatibility on both master and slave. As older slaves don't support negotiating protocol features, a feature @@ -315,7 +319,8 @@ it until ring is started, or after it has been stopped. =20 Client must start ring upon receiving a kick (that is, detecting that file descriptor is readable) on the descriptor specified by -``VHOST_USER_SET_VRING_KICK``, and stop ring upon receiving +``VHOST_USER_SET_VRING_KICK`` or receiving the in-band message +``VHOST_USER_VRING_KICK`` if negotiated, and stop ring upon receiving ``VHOST_USER_GET_VRING_BASE``. =20 While processing the rings (whether they are enabled or not), client @@ -767,25 +772,49 @@ When reconnecting: #. Resubmit inflight ``DescStatePacked`` entries in order of their counter value =20 +In-band notifications +--------------------- + +In some limited situations (e.g. for simulation) it is desirable to +have the kick, call and error (if used) signals done via in-band +messages instead of asynchronous eventfd notifications. This can be +done by negotiating the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` +protocol feature. + +Note that due to the fact that too many messages on the sockets can +cause the sending application(s) to block, it is not advised to use +this feature unless absolutely necessary. It is also considered an +error to negotiate this feature without also negotiating +``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK`= `, +the former is necessary for getting a message channel from the slave +to the master, while the latter needs to be used with the in-band +notification messages to block until they are processed, both to avoid +blocking later and for proper processing (at least in the simulation +use case.) As it has no other way of signalling this error, the slave +should close the connection as a response to a +``VHOST_USER_SET_PROTOCOL_FEATURES`` message that sets the in-band +notifications feature flag without the other two. + Protocol features ----------------- =20 .. code:: c =20 - #define VHOST_USER_PROTOCOL_F_MQ 0 - #define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 - #define VHOST_USER_PROTOCOL_F_RARP 2 - #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 - #define VHOST_USER_PROTOCOL_F_MTU 4 - #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 - #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 - #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7 - #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8 - #define VHOST_USER_PROTOCOL_F_CONFIG 9 - #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 - #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 - #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 - #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13 + #define VHOST_USER_PROTOCOL_F_MQ 0 + #define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 + #define VHOST_USER_PROTOCOL_F_RARP 2 + #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 + #define VHOST_USER_PROTOCOL_F_MTU 4 + #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 + #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 + #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7 + #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8 + #define VHOST_USER_PROTOCOL_F_CONFIG 9 + #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 + #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 + #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 + #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13 + #define VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS 14 =20 Master message types -------------------- @@ -947,7 +976,12 @@ Master message types Bits (0-7) of the payload contain the vring index. Bit 8 is the invalid FD flag. This flag is set when there is no file descriptor in the ancillary data. This signals that polling should be used - instead of waiting for a kick. + instead of waiting for the kick. Note that if the protocol feature + ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` has been negotiated + this message isn't necessary as the ring is also started on the + ``VHOST_USER_VRING_KICK`` message, it may however still be used to + set an event file descriptor (which will be preferred over the + message) or to enable polling. =20 ``VHOST_USER_SET_VRING_CALL`` :id: 13 @@ -960,7 +994,12 @@ Master message types Bits (0-7) of the payload contain the vring index. Bit 8 is the invalid FD flag. This flag is set when there is no file descriptor in the ancillary data. This signals that polling will be used - instead of waiting for the call. + instead of waiting for the call. Note that if the protocol features + ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and + ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_SLAVE_VRING_CALL`` message can be + used, it may however still be used to set an event file descriptor + or to enable polling. =20 ``VHOST_USER_SET_VRING_ERR`` :id: 14 @@ -972,7 +1011,12 @@ Master message types =20 Bits (0-7) of the payload contain the vring index. Bit 8 is the invalid FD flag. This flag is set when there is no file descriptor - in the ancillary data. + in the ancillary data. Note that if the protocol features + ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and + ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_SLAVE_VRING_ERR`` message can be + used, it may however still be used to set an event file descriptor + (which will be preferred over the message). =20 ``VHOST_USER_GET_QUEUE_NUM`` :id: 17 @@ -1205,6 +1249,20 @@ Master message types Only valid if the ``VHOST_USER_PROTOCOL_F_RESET_DEVICE`` protocol feature is set by the backend. =20 +``VHOST_USER_VRING_KICK`` + :id: 35 + :equivalent ioctl: N/A + :slave payload: vring state description + :master payload: N/A + + When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol + feature has been successfully negotiated, this message may be + submitted by the master to indicate that a buffer was added to + the vring instead of signalling it using the vring's kick file + descriptor or having the slave rely on polling. + + The state.num field is currently reserved and must be set to 0. + Slave message types ------------------- =20 @@ -1261,6 +1319,34 @@ Slave message types ``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been successfully negotiated. =20 +``VHOST_USER_SLAVE_VRING_CALL`` + :id: 4 + :equivalent ioctl: N/A + :slave payload: vring state description + :master payload: N/A + + When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol + feature has been successfully negotiated, this message may be + submitted by the slave to indicate that a buffer was used from + the vring instead of signalling this using the vring's call file + descriptor or having the master relying on polling. + + The state.num field is currently reserved and must be set to 0. + +``VHOST_USER_SLAVE_VRING_ERR`` + :id: 5 + :equivalent ioctl: N/A + :slave payload: vring state description + :master payload: N/A + + When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol + feature has been successfully negotiated, this message may be + submitted by the slave to indicate that an error occurred on the + specific vring, instead of signalling the error file descriptor + set by the master via ``VHOST_USER_SET_VRING_ERR``. + + The state.num field is currently reserved and must be set to 0. + .. _reply_ack: =20 VHOST_USER_PROTOCOL_F_REPLY_ACK --=20 2.24.1 From nobody Sat May 18 16:18:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1579767623; cv=none; d=zohomail.com; s=zohoarc; b=CS06V9sOFxKoR9EoKwkFniMd/zl1tevwy2mw+oZUsbPHrAG1nIHR5nOSKyTebeBV0YRNSvvg0tetXiIGNrgM9HauHpO/quxn9phSVRTfeSuIfWd9TZ6QFzuTc+jvFElyzl7bvTz9HOQ984S/jFCVnJj/C9BIxmmy/Zgt/DrUkvQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579767623; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=ZmX9Nx8ry+A7oGsnXHrMz87RHXeKwTwzDRIflub433A=; b=Q21LlbOr2np07y3C2LT7WH82m5B9rYZjAC5P3ctI9xUzD9pBNlaUoI/tAzoBaMQxnzxwoNNqzBFCiY0/g+TqhuttWSC+pcGWZdyVseim0udA2XtBFfGAhnFEmEaA4T7hD7h5lxKbuqPcyFT5pkhMdpYbbvpHWGcq3+sWHQdqSD4= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1579767623233771.0982880018616; Thu, 23 Jan 2020 00:20:23 -0800 (PST) Received: from localhost ([::1]:52774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXiv-000602-Vp for importer@patchew.org; Thu, 23 Jan 2020 03:20:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53352) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuXfx-00020e-G3 for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuXfv-0005lc-N4 for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:17 -0500 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2]:35510 helo=sipsolutions.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iuXfv-0005jH-GF for qemu-devel@nongnu.org; Thu, 23 Jan 2020 03:17:15 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1iuXfu-00FGF5-96; Thu, 23 Jan 2020 09:17:14 +0100 From: Johannes Berg To: qemu-devel@nongnu.org Subject: [PATCH v5 6/6] libvhost-user: implement in-band notifications Date: Thu, 23 Jan 2020 09:17:08 +0100 Message-Id: <20200123081708.7817-7-johannes@sipsolutions.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200123081708.7817-1-johannes@sipsolutions.net> References: <20200123081708.7817-1-johannes@sipsolutions.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a01:4f8:191:4433::2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Johannes Berg , mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" From: Johannes Berg Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but as it's not desired by default, don't enable it unless the device implementation opts in by returning it from its protocol features callback. Note that I updated vu_set_vring_err_exec(), but didn't add any sending of the VHOST_USER_SLAVE_VRING_ERR message as there's no write to the err_fd today either. This also adds vu_queue_notify_sync() which can be used to force a synchronous notification if inband notifications are supported. Previously, I had left out the slave->master direction handling of F_REPLY_ACK, this now adds some code to support it as well. Signed-off-by: Johannes Berg --- contrib/libvhost-user/libvhost-user.c | 103 +++++++++++++++++++++++++- contrib/libvhost-user/libvhost-user.h | 14 ++++ 2 files changed, 114 insertions(+), 3 deletions(-) diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/= libvhost-user.c index 34d08e2fc4be..5cb8e6e32158 100644 --- a/contrib/libvhost-user/libvhost-user.c +++ b/contrib/libvhost-user/libvhost-user.c @@ -136,6 +136,7 @@ vu_request_to_string(unsigned int req) REQ(VHOST_USER_GET_INFLIGHT_FD), REQ(VHOST_USER_SET_INFLIGHT_FD), REQ(VHOST_USER_GPU_SET_SOCKET), + REQ(VHOST_USER_VRING_KICK), REQ(VHOST_USER_MAX), }; #undef REQ @@ -163,7 +164,10 @@ vu_panic(VuDev *dev, const char *msg, ...) dev->panic(dev, buf); free(buf); =20 - /* FIXME: find a way to call virtio_error? */ + /* + * FIXME: + * find a way to call virtio_error, or perhaps close the connection? + */ } =20 /* Translate guest physical address to our virtual address. */ @@ -1172,6 +1176,14 @@ vu_set_vring_err_exec(VuDev *dev, VhostUserMsg *vmsg) static bool vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg *vmsg) { + /* + * Note that we support, but intentionally do not set, + * VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS. This means that + * a device implementation can return it in its callback + * (get_protocol_features) if it wants to use this for + * simulation, but it is otherwise not desirable (if even + * implemented by the master.) + */ uint64_t features =3D 1ULL << VHOST_USER_PROTOCOL_F_MQ | 1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD | 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_REQ | @@ -1204,6 +1216,25 @@ vu_set_protocol_features_exec(VuDev *dev, VhostUserM= sg *vmsg) =20 dev->protocol_features =3D vmsg->payload.u64; =20 + if (vu_has_protocol_feature(dev, + VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS= ) && + (!vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_SLAVE_REQ) || + !vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_REPLY_ACK))) { + /* + * The use case for using messages for kick/call is simulation, to= make + * the kick and call synchronous. To actually get that behaviour, = both + * of the other features are required. + * Theoretically, one could use only kick messages, or do them wit= hout + * having F_REPLY_ACK, but too many (possibly pending) messages on= the + * socket will eventually cause the master to hang, to avoid this = in + * scenarios where not desired enforce that the settings are in a = way + * that actually enables the simulation case. + */ + vu_panic(dev, + "F_IN_BAND_NOTIFICATIONS requires F_SLAVE_REQ && F_REPLY_= ACK"); + return false; + } + if (dev->iface->set_protocol_features) { dev->iface->set_protocol_features(dev, features); } @@ -1464,6 +1495,34 @@ vu_set_inflight_fd(VuDev *dev, VhostUserMsg *vmsg) return false; } =20 +static bool +vu_handle_vring_kick(VuDev *dev, VhostUserMsg *vmsg) +{ + unsigned int index =3D vmsg->payload.state.index; + + if (index >=3D dev->max_queues) { + vu_panic(dev, "Invalid queue index: %u", index); + return false; + } + + DPRINT("Got kick message: handler:%p idx:%d\n", + dev->vq[index].handler, index); + + if (!dev->vq[index].started) { + dev->vq[index].started =3D true; + + if (dev->iface->queue_set_started) { + dev->iface->queue_set_started(dev, index, true); + } + } + + if (dev->vq[index].handler) { + dev->vq[index].handler(dev, index); + } + + return false; +} + static bool vu_process_message(VuDev *dev, VhostUserMsg *vmsg) { @@ -1546,6 +1605,8 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg) return vu_get_inflight_fd(dev, vmsg); case VHOST_USER_SET_INFLIGHT_FD: return vu_set_inflight_fd(dev, vmsg); + case VHOST_USER_VRING_KICK: + return vu_handle_vring_kick(dev, vmsg); default: vmsg_close_fds(vmsg); vu_panic(dev, "Unhandled request: %d", vmsg->request); @@ -2005,8 +2066,7 @@ vring_notify(VuDev *dev, VuVirtq *vq) return !v || vring_need_event(vring_get_used_event(vq), new, old); } =20 -void -vu_queue_notify(VuDev *dev, VuVirtq *vq) +static void _vu_queue_notify(VuDev *dev, VuVirtq *vq, bool sync) { if (unlikely(dev->broken) || unlikely(!vq->vring.avail)) { @@ -2018,11 +2078,48 @@ vu_queue_notify(VuDev *dev, VuVirtq *vq) return; } =20 + if (vq->call_fd < 0 && + vu_has_protocol_feature(dev, + VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS= ) && + vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_SLAVE_REQ)) { + VhostUserMsg vmsg =3D { + .request =3D VHOST_USER_SLAVE_VRING_CALL, + .flags =3D VHOST_USER_VERSION, + .size =3D sizeof(vmsg.payload.state), + .payload.state =3D { + .index =3D vq - dev->vq, + }, + }; + bool ack =3D sync && + vu_has_protocol_feature(dev, + VHOST_USER_PROTOCOL_F_REPLY_ACK= ); + + if (ack) { + vmsg.flags |=3D VHOST_USER_NEED_REPLY_MASK; + } + + vu_message_write(dev, dev->slave_fd, &vmsg); + if (ack) { + vu_message_read(dev, dev->slave_fd, &vmsg); + } + return; + } + if (eventfd_write(vq->call_fd, 1) < 0) { vu_panic(dev, "Error writing eventfd: %s", strerror(errno)); } } =20 +void vu_queue_notify(VuDev *dev, VuVirtq *vq) +{ + _vu_queue_notify(dev, vq, false); +} + +void vu_queue_notify_sync(VuDev *dev, VuVirtq *vq) +{ + _vu_queue_notify(dev, vq, true); +} + static inline void vring_used_flags_set_bit(VuVirtq *vq, int mask) { diff --git a/contrib/libvhost-user/libvhost-user.h b/contrib/libvhost-user/= libvhost-user.h index 46b600799b2e..cd12cbd92cc5 100644 --- a/contrib/libvhost-user/libvhost-user.h +++ b/contrib/libvhost-user/libvhost-user.h @@ -53,6 +53,7 @@ enum VhostUserProtocolFeature { VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD =3D 10, VHOST_USER_PROTOCOL_F_HOST_NOTIFIER =3D 11, VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD =3D 12, + VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS =3D 14, =20 VHOST_USER_PROTOCOL_F_MAX }; @@ -94,6 +95,7 @@ typedef enum VhostUserRequest { VHOST_USER_GET_INFLIGHT_FD =3D 31, VHOST_USER_SET_INFLIGHT_FD =3D 32, VHOST_USER_GPU_SET_SOCKET =3D 33, + VHOST_USER_VRING_KICK =3D 35, VHOST_USER_MAX } VhostUserRequest; =20 @@ -102,6 +104,8 @@ typedef enum VhostUserSlaveRequest { VHOST_USER_SLAVE_IOTLB_MSG =3D 1, VHOST_USER_SLAVE_CONFIG_CHANGE_MSG =3D 2, VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG =3D 3, + VHOST_USER_SLAVE_VRING_CALL =3D 4, + VHOST_USER_SLAVE_VRING_ERR =3D 5, VHOST_USER_SLAVE_MAX } VhostUserSlaveRequest; =20 @@ -522,6 +526,16 @@ bool vu_queue_empty(VuDev *dev, VuVirtq *vq); */ void vu_queue_notify(VuDev *dev, VuVirtq *vq); =20 +/** + * vu_queue_notify_sync: + * @dev: a VuDev context + * @vq: a VuVirtq queue + * + * Request to notify the queue via callfd (skipped if unnecessary) + * or sync message if possible. + */ +void vu_queue_notify_sync(VuDev *dev, VuVirtq *vq); + /** * vu_queue_pop: * @dev: a VuDev context --=20 2.24.1