From patchwork Tue Mar 14 08:35:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 13173909 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 13983C6FD1C for ; Tue, 14 Mar 2023 08:35:32 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.509501.785347 (Exim 4.92) (envelope-from ) id 1pc07l-0005gO-WC; Tue, 14 Mar 2023 08:35:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 509501.785347; Tue, 14 Mar 2023 08:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pc07l-0005gH-RS; Tue, 14 Mar 2023 08:35:13 +0000 Received: by outflank-mailman (input) for mailman id 509501; Tue, 14 Mar 2023 08:35:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pc07k-0005es-Jb for xen-devel@lists.xenproject.org; Tue, 14 Mar 2023 08:35:12 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2003914f-c243-11ed-b464-930f4c7d94ae; Tue, 14 Mar 2023 09:35:07 +0100 (CET) Received: from [2001:8b0:10b:5:4cf8:b30f:f81:c818] (helo=u3832b3a9db3152.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pc07c-00CjXL-CG; Tue, 14 Mar 2023 08:35:05 +0000 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 Sender: "Xen-devel" X-Inumbo-ID: 2003914f-c243-11ed-b464-930f4c7d94ae DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EsKGQKX5H5xQ8a7eKIcDS4lNhDTY1QgeDsjiXjaL+wY=; b=Q3KTTBjRp4HZROuSt1P5CO7dsl ASM35AdLZE6b9pWaGCiKCGkvzdtPQ/qtisIo484KDeYG/YON9l59/o/Ht+4LBRc02lzPzlArSc20t ETImXJAn16fiNXZYtpyPjk5O3ndTtggzg1qRCcFNuId5Dl4V3cTVo8nMmJxa17y4OvanlW8tTiQ6a +Kf4oxCxVMO3B6bsW1+GCvpqFdOzoVyTCDxum/HG5XBKCG4hByHBTrN5yfswM3jfVS3623uvUXTEb EUihNWtyYo2c5Zq4GuBVlgWLFaNTvtt1/xFT3QAZwUn+mcohXUpz7rezZC3q1TxJm6eKInStTYAvQ k3sDqJqA==; Message-ID: <1f141995bb61af32c2867ef5559e253f39b0949c.camel@infradead.org> Subject: [PATCH] accel/xen: Fix DM state change notification in dm_restrict mode From: David Woodhouse To: Jason Andryuk Cc: Peter Maydell , qemu-devel@nongnu.org, Paolo Bonzini , Paul Durrant , Joao Martins , Ankur Arora , Stefano Stabellini , vikram.garhwal@amd.com, Anthony Perard , xen-devel@lists.xenproject.org, Juan Quintela , "Dr . David Alan Gilbert" Date: Tue, 14 Mar 2023 08:35:03 +0000 In-Reply-To: References: <20230307182707.2298618-1-dwmw2@infradead.org> <20230307182707.2298618-14-dwmw2@infradead.org> <5062bef5b5cfd3e2d7f313de9af306f5e4f841f5.camel@infradead.org> User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html From: David Woodhouse When dm_restrict is set, QEMU isn't permitted to update the XenStore node to indicate its running status. Previously, the xs_write() call would fail but the failure was ignored. However, in refactoring to allow for emulated XenStore operations, a new call to xs_open() was added. That one didn't fail gracefully, causing a fatal error when running in dm_restrict mode. Partially revert the offending patch, removing the additional call to xs_open() because the global 'xenstore' variable is still available; it just needs to be used with qemu_xen_xs_write() now instead of directly with the xs_write() libxenstore function. Also make the whole thing conditional on !xen_domid_restrict. There's no point even registering the state change handler to attempt to update the XenStore node when we know it's destined to fail. Fixes: ba2a92db1ff6 ("hw/xen: Add xenstore operations to allow redirection to internal emulation") Reported-by: Jason Andryuk Co-developed-by: Jason Andryuk Not-Signed-off-by: Jason Andryuk Signed-off-by: David Woodhouse Will-be-Tested-by: Jason Andryuk Reviewed-by: Paul Durrant Signed-off-by: Jason Andryuk Tested-by: Jason Andryuk --- accel/xen/xen-all.c | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-) diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c index 00221e23c5..5ff0cb8bd9 100644 --- a/accel/xen/xen-all.c +++ b/accel/xen/xen-all.c @@ -32,28 +32,13 @@ xendevicemodel_handle *xen_dmod; static void xenstore_record_dm_state(const char *state) { - struct xs_handle *xs; char path[50]; - /* We now have everything we need to set the xenstore entry. */ - xs = xs_open(0); - if (xs == NULL) { - fprintf(stderr, "Could not contact XenStore\n"); - exit(1); - } - snprintf(path, sizeof (path), "device-model/%u/state", xen_domid); - /* - * This call may fail when running restricted so don't make it fatal in - * that case. Toolstacks should instead use QMP to listen for state changes. - */ - if (!xs_write(xs, XBT_NULL, path, state, strlen(state)) && - !xen_domid_restrict) { + if (!qemu_xen_xs_write(xenstore, XBT_NULL, path, state, strlen(state))) { error_report("error recording dm state"); exit(1); } - - xs_close(xs); } @@ -111,7 +96,15 @@ static int xen_init(MachineState *ms) xc_interface_close(xen_xc); return -1; } - qemu_add_vm_change_state_handler(xen_change_state_handler, NULL); + + /* + * The XenStore write would fail when running restricted so don't attempt + * it in that case. Toolstacks should instead use QMP to listen for state + * changes. + */ + if (!xen_domid_restrict) { + qemu_add_vm_change_state_handler(xen_change_state_handler, NULL); + } /* * opt out of system RAM being allocated by generic code */