From patchwork Wed Oct 25 14:50:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 13436326 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2917BC0032E for ; Wed, 25 Oct 2023 14:51:33 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.622973.970384 (Exim 4.92) (envelope-from ) id 1qvfE3-0003jS-QL; Wed, 25 Oct 2023 14:51:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 622973.970384; Wed, 25 Oct 2023 14:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qvfE3-0003ie-E7; Wed, 25 Oct 2023 14:51:15 +0000 Received: by outflank-mailman (input) for mailman id 622973; Wed, 25 Oct 2023 14:51:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qvfE1-0008W8-2k for xen-devel@lists.xenproject.org; Wed, 25 Oct 2023 14:51:13 +0000 Received: from desiato.infradead.org (desiato.infradead.org [2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f0200bad-7345-11ee-98d5-6d05b1d4d9a1; Wed, 25 Oct 2023 16:51:12 +0200 (CEST) Received: from [2001:8b0:10b:1::ebe] (helo=i7.infradead.org) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qvfDZ-00GPLw-00; Wed, 25 Oct 2023 14:50:51 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1qvfDX-002dEB-38; Wed, 25 Oct 2023 15:50:43 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list X-Inumbo-ID: f0200bad-7345-11ee-98d5-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=Q/tyhQvSuMwg2Gh5kOIH6qsA0eNCoglo/BC/VrIl6Es=; b=KDYI3aY4tMOqlZWdfNfO3LfWji oD5wYOBY7+ELSt03QoqbH58su+Ih3wGW5y4L029rvsFpFws8RSdxkpx1kvzrlS+TR8NZrSvLHKS2E SjvLuuRm8b/GnqIqaDOe5rDZTyJ/8Guse6k/gguUsxYD44GH6Tn/1C0kqkUq3glxbg20jjPwKv8u9 Utgyvf4duButgytsgIFvJi/gbUd0SSA1jqoxw3sxA0TP7WEocX4xU//yXPAlhMq2BmAgFO6SYdQxX O1MwfOqd73UkIrEQm5B9gRr0qBVYQsayxRgtHc1M0nfSNSW/4X7QtGGxiam1VQgi1BhfsTGnBKIs/ 5Klyv7rQ==; From: David Woodhouse To: qemu-devel@nongnu.org Cc: Kevin Wolf , Hanna Reitz , Stefano Stabellini , Anthony Perard , Paul Durrant , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Paolo Bonzini , "Michael S. Tsirkin" , Marcel Apfelbaum , Richard Henderson , Eduardo Habkost , Jason Wang , Marcelo Tosatti , qemu-block@nongnu.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, Bernhard Beschow , Joel Upham Subject: [PATCH v3 04/28] hw/xen: don't clear map_track[] in xen_gnttab_reset() Date: Wed, 25 Oct 2023 15:50:18 +0100 Message-Id: <20231025145042.627381-5-dwmw2@infradead.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20231025145042.627381-1-dwmw2@infradead.org> References: <20231025145042.627381-1-dwmw2@infradead.org> MIME-Version: 1.0 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by desiato.infradead.org. See http://www.infradead.org/rpr.html From: David Woodhouse The refcounts actually correspond to 'active_ref' structures stored in a GHashTable per "user" on the backend side (mostly, per XenDevice). If we zero map_track[] on reset, then when the backend drivers get torn down and release their mapping we hit the assert(s->map_track[ref] != 0) in gnt_unref(). So leave them in place. Each backend driver will disconnect and reconnect as the guest comes back up again and reconnects, and it all works out OK in the end as the old refs get dropped. Fixes: de26b2619789 ("hw/xen: Implement soft reset for emulated gnttab") Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/kvm/xen_gnttab.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/hw/i386/kvm/xen_gnttab.c b/hw/i386/kvm/xen_gnttab.c index 21c30e3659..839ec920a1 100644 --- a/hw/i386/kvm/xen_gnttab.c +++ b/hw/i386/kvm/xen_gnttab.c @@ -541,7 +541,5 @@ int xen_gnttab_reset(void) s->entries.v1[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access; s->entries.v1[GNTTAB_RESERVED_XENSTORE].frame = XEN_SPECIAL_PFN(XENSTORE); - memset(s->map_track, 0, s->max_frames * ENTRIES_PER_FRAME_V1); - return 0; }