From nobody Fri Nov 7 04:02:13 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1545316925392320.96380803905845; Thu, 20 Dec 2018 06:42:05 -0800 (PST) Received: from localhost ([::1]:37853 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZzWW-0008Vy-2J for importer@patchew.org; Thu, 20 Dec 2018 09:42:04 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZzLf-0007gN-6e for qemu-devel@nongnu.org; Thu, 20 Dec 2018 09:30:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZz7i-0000TO-Bv for qemu-devel@nongnu.org; Thu, 20 Dec 2018 09:16:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38104) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gZz7i-0000ST-2f for qemu-devel@nongnu.org; Thu, 20 Dec 2018 09:16:26 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 655B93D957 for ; Thu, 20 Dec 2018 14:16:25 +0000 (UTC) Received: from localhost (ovpn-112-51.ams2.redhat.com [10.36.112.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 22CE05EDEB; Thu, 20 Dec 2018 14:16:21 +0000 (UTC) From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= To: qemu-devel@nongnu.org Date: Thu, 20 Dec 2018 18:15:44 +0400 Message-Id: <20181220141553.24098-4-marcandre.lureau@redhat.com> In-Reply-To: <20181220141553.24098-1-marcandre.lureau@redhat.com> References: <20181220141553.24098-1-marcandre.lureau@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 20 Dec 2018 14:16:25 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 03/12] char/spice: discard write() if backend is disconnected X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kraxel@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" Most chardev backend handle write() as discarded data if underlying system is disconnected. For unknown historical reasons, the Spice backend has "reliable" write: it will wait until the client end is reconnected to do further successful write(). To decide whether it make sense to wait until the client is reconnected (or queue the writes), let's review Spice chardev usage and handling of a disconnected client: * spice vdagent The agents reopen the virtio port on disconnect. In qemu side, virtio_serial_close() will also discard pending data. * usb redirection A disconnect creates a device disconnection. * smartcard emulation Data is discarded in passthru_apdu_from_guest(). (Spice doesn't explicitly open the smartcard char device until upcoming 0.14.2, commit 69a5cfc74131ec0459f2eb5a231139f5a69a8037) * spice webdavd The daemon will restart the service, and reopen the virtio port. * spice ports (serial console, qemu monitor..) Depends on the associated device or usage. - serial, may be throttled or discarded on write, depending on device - QMP/HMP monitor have some CLOSED event handling, but want to flush the write, which will finish when a new client connects. On disconnect/reconnect, the client starts with fresh sessions. If it is a seamless migration, the client disconnects after the source migrated. The handling of source disconnect in qemu is thus irrelevant for the Spice session migration. For all these use cases, it is better to discard writes when the client is disconnected, and require the vm-side device/agent to behave correctly on CHR_EVENT_CLOSED, to stop reading and writing from the spice chardev. Signed-off-by: Marc-Andr=C3=A9 Lureau --- chardev/spice.c | 12 ++++++++++++ chardev/trace-events | 1 + 2 files changed, 13 insertions(+) diff --git a/chardev/spice.c b/chardev/spice.c index c2baeb5461..c68e60115b 100644 --- a/chardev/spice.c +++ b/chardev/spice.c @@ -208,6 +208,12 @@ static int spice_chr_write(Chardev *chr, const uint8_t= *buf, int len) int read_bytes; =20 assert(s->datalen =3D=3D 0); + + if (!chr->be_open) { + trace_spice_chr_discard_write(len); + return len; + } + s->datapos =3D buf; s->datalen =3D len; spice_server_char_device_wakeup(&s->sin); @@ -300,6 +306,12 @@ static void qemu_chr_open_spice_vmc(Chardev *chr, } =20 *be_opened =3D false; +#if SPICE_SERVER_VERSION < 0x000e02 + /* Spice < 0.14.2 doesn't explicitly open smartcard chardev */ + if (strcmp(type, "smartcard") =3D=3D 0) { + *be_opened =3D true; + } +#endif chr_open(chr, type); } =20 diff --git a/chardev/trace-events b/chardev/trace-events index d0e5f3bbc1..b8a7596344 100644 --- a/chardev/trace-events +++ b/chardev/trace-events @@ -10,6 +10,7 @@ wct_cmd_other(const char *cmd) "%s" wct_speed(int speed) "%d" =20 # chardev/spice.c +spice_chr_discard_write(int len) "spice chr write discarded %d" spice_vmc_write(ssize_t out, int len) "spice wrote %zd of requested %d" spice_vmc_read(int bytes, int len) "spice read %d of requested %d" spice_vmc_register_interface(void *scd) "spice vmc registered interface %p" --=20 2.20.1.2.gb21ebb671b