From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE527C83004 for ; Wed, 29 Apr 2020 13:17:08 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 9263921974 for ; Wed, 29 Apr 2020 13:17:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="XWJzPsBe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9263921974 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jTma5-0006vx-HR; Wed, 29 Apr 2020 13:16:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jTma4-0006vs-Sr for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 13:16:52 +0000 X-Inumbo-ID: afde216e-8a1b-11ea-ae69-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id afde216e-8a1b-11ea-ae69-bc764e2007e4; Wed, 29 Apr 2020 13:16:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1588166211; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=li7mdtzKQF/3GuwIKiRLZGF3S+9lCMvTSVu9CWtxfxA=; b=XWJzPsBeoAMrjCpgVkXr6+j3E9JYBljvgDz+HWctgpSurgQO9JLTsN6D XpQAoHqd85+G7KfmrhDCDjwq7nkuOC/lZiQmsBSuVSDexsyNZ33TgKhBX mUugh+7xxlyvy3B8PwvKkdogY9bMG4mZos7u2JaF/Jnd3c9hEKqvyS7GZ 8=; Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=igor.druzhinin@citrix.com; spf=Pass smtp.mailfrom=igor.druzhinin@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of igor.druzhinin@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="igor.druzhinin@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa5.hc3370-68.iphmx.com: domain of igor.druzhinin@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="igor.druzhinin@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa5.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa5.hc3370-68.iphmx.com; envelope-from="igor.druzhinin@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: IA8d+2jwmHBxcmYi/W7rRyNbopQ6ZwT70My7h5Mts90e3AffUB9bwXft4nj6SDIGeVMvUr1RJ3 TtvoIByi3OHRVgS49yM+eofZ/FFx1d/CLfyfa3ptjj84Rn9OMtjkxJi20L+xmyXmx8i0rdbgOC qUzmHpp3JlHNKmdKQfJV/l7ycV3yRfAot2Fpl4FTWJV8lmb63dq55o+JKCEIx5+QiV1fjLNqut 2qQhd9K4WtT6IOSTGNK33C1pcsBp/xm+YaecT4pIRgue3NfZ9y9NKjHjZvu+WDSaJu9TSlEzmI BPE= X-SBRS: 2.7 X-MesageID: 16750942 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,332,1583211600"; d="scan'208";a="16750942" Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred To: , =?UTF-8?B?J0rDvHJnZW4gR3Jvw58n?= , 'Julien Grall' , 'Julien Grall' References: <20200428155144.8253-1-jgross@suse.com> <76ed29d6-e2fc-cd48-6de7-e0032daaa2e9@xen.org> <3fd79cb1-e18f-1987-69ff-94f1bd15c66f@citrix.com> <3dcbe001-c66c-13a6-7a28-ef24b05eefa0@suse.com> <000001d61e25$97f86530$c7e92f90$@xen.org> From: Igor Druzhinin Message-ID: <0eaea23f-8b4a-2c67-2fc4-827cf26dbd8d@citrix.com> Date: Wed, 29 Apr 2020 14:16:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <000001d61e25$97f86530$c7e92f90$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'xen-devel' , 'Ian Jackson' , 'Wei Liu' , andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29/04/2020 13:56, Paul Durrant wrote: >> -----Original Message----- >> From: Igor Druzhinin >> Sent: 29 April 2020 13:50 >> To: Jürgen Groß ; Julien Grall ; Julien Grall >> >> Cc: xen-devel ; Ian Jackson ; Wei Liu >> ; andrew.cooper3@citrix.com; Paul Durrant >> Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred >> >> On 29/04/2020 13:29, Jürgen Groß wrote: >>> >>> Wei, Ian, can you please tell me where I'm wrong? >>> >>> A soft reset should restart the domain in a clean state. AFAIK libxl is >>> handling that by doing kind of in-place save-restore, including calling >>> xs_release_domain() and later xs_introduce_domain(). This should result >>> in xenstored throwing away all state it has regarding the domain and >>> then restarting with a new (internal) domain instance. >>> >>> Is XAPI doing soft reset differently? Why should there be a need for >>> keeping xenstored data across a soft reset? >> >> Yes, XAPI is doing soft reset differently from libxl. You need to keep xenstore >> data to at least keep backends working without the need to reinitialize them >> before entering kdump kernel. We do the same thing while entering crash kernel >> in Windows after BSOD (CC Paul as he recommended this approach). > > IIRC I recommended not involving Xen or the toolstack in entering the crash kernel... they don't need to know. Windows quite happily enters its crash kernel, rebuilds its Xen interfaces and re-attaches to PV backends without any external intervention. In case of kdump toolstack certainly needs to know as it gets shutdown code 5 and needs to restart the domain. And I'm not completely sure it's possible to enter kdump without calling soft reset at all. Even if it's possible I'd be cautious to do it in production for the future. Igor