From patchwork Mon Mar 7 19:25:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Markus Armbruster X-Patchwork-Id: 8522461 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1B5319F2B4 for ; Mon, 7 Mar 2016 19:46:11 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7676220114 for ; Mon, 7 Mar 2016 19:46:10 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BDCE92010E for ; Mon, 7 Mar 2016 19:46:09 +0000 (UTC) Received: from localhost ([::1]:58115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad16X-0005bV-7v for patchwork-qemu-devel@patchwork.kernel.org; Mon, 07 Mar 2016 14:46:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad0n9-000480-Cz for qemu-devel@nongnu.org; Mon, 07 Mar 2016 14:26:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad0n7-0003z2-Bw for qemu-devel@nongnu.org; Mon, 07 Mar 2016 14:26:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad0n7-0003yY-52 for qemu-devel@nongnu.org; Mon, 07 Mar 2016 14:26:05 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id C04B764388; Mon, 7 Mar 2016 19:26:04 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-61.ams2.redhat.com [10.36.116.61]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27JQ1t2026202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 14:26:03 -0500 Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 4A90130052FA; Mon, 7 Mar 2016 20:25:57 +0100 (CET) From: Markus Armbruster To: qemu-devel@nongnu.org Date: Mon, 7 Mar 2016 20:25:41 +0100 Message-Id: <1457378754-21649-30-git-send-email-armbru@redhat.com> In-Reply-To: <1457378754-21649-1-git-send-email-armbru@redhat.com> References: <1457378754-21649-1-git-send-email-armbru@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 07 Mar 2016 19:26:04 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: claudio.fontana@huawei.com, cam@cs.ualberta.ca, mlureau@redhat.com, david.marchand@6wind.com, pbonzini@redhat.com Subject: [Qemu-devel] [PATCH v2 29/42] ivshmem: Rely on server sending the ID right after the version X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The protocol specification (ivshmem-spec.txt, formerly ivshmem_device_spec.txt) has always required the ID message to be sent right at the beginning, and ivshmem-server has always complied. The device, however, accepts it out of order. If an interrupt setup arrived before it, though, it would be misinterpreted as connect notification. Fix the latent bug by relying on the spec and ivshmem-server's actual behavior. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau --- hw/misc/ivshmem.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c index c3327dc..ca64654 100644 --- a/hw/misc/ivshmem.c +++ b/hw/misc/ivshmem.c @@ -653,8 +653,6 @@ static void process_msg(IVShmemState *s, int64_t msg, int fd, Error **errp) if (fd >= 0) { process_msg_connect(s, msg, fd, errp); - } else if (s->vm_id == -1) { - s->vm_id = msg; } else { process_msg_disconnect(s, msg, errp); } @@ -722,6 +720,30 @@ static void ivshmem_recv_setup(IVShmemState *s, Error **errp) } /* + * ivshmem-server sends the remaining initial messages in a fixed + * order, but the device has always accepted them in any order. + * Stay as compatible as practical, just in case people use + * servers that behave differently. + */ + + /* + * ivshmem_device_spec.txt has always required the ID message + * right here, and ivshmem-server has always complied. However, + * older versions of the device accepted it out of order, but + * broke when an interrupt setup message arrived before it. + */ + msg = ivshmem_recv_msg(s, &fd, &err); + if (err) { + error_propagate(errp, err); + return; + } + if (fd != -1 || msg < 0 || msg > IVSHMEM_MAX_PEERS) { + error_setg(errp, "server sent invalid ID message"); + return; + } + s->vm_id = msg; + + /* * Receive more messages until we got shared memory. */ do { @@ -952,7 +974,6 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error **errp) /* we allocate enough space for 16 peers and grow as needed */ resize_peers(s, 16); - s->vm_id = -1; pci_register_bar(dev, 2, attr, &s->bar);