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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 B8249C83003 for ; Wed, 29 Apr 2020 12:29:55 +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 915D42186A for ; Wed, 29 Apr 2020 12:29:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 915D42186A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.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 1jTlqF-0001cR-OW; Wed, 29 Apr 2020 12:29:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jTlqE-0001cM-Hr for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 12:29:30 +0000 X-Inumbo-ID: 11fe7332-8a15-11ea-ae69-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 11fe7332-8a15-11ea-ae69-bc764e2007e4; Wed, 29 Apr 2020 12:29:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 55B39AEDD; Wed, 29 Apr 2020 12:29:27 +0000 (UTC) Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred To: Igor Druzhinin , 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> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Wed, 29 Apr 2020 14:29:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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.20 13:04, Igor Druzhinin wrote: > On 29/04/2020 11:49, Jürgen Groß wrote: >> On 29.04.20 12:39, Igor Druzhinin wrote: >>> On 29/04/2020 10:22, Julien Grall wrote: >>>> Hi Juergen, >>>> >>>> On 29/04/2020 06:51, Jürgen Groß wrote: >>>>> >>>>> Recreating the event channel would be fine, but I don't see why it >>>>> would ever be needed. And XS_INTRODUCE is called only at domain creation >>>>> time today, so there is obviously no need for repeating this call. >>>>> >>>>> Maybe the idea was to do this after sending a XS_RESUME command, which >>>>> isn't used anywhere in Xen and is another part of Xenstore which doesn't >>>>> make any sense today. >>>> >>>> Commit f6cc37ea8ac71385b60507c034519f304da75f4c "tools/oxenstored: port XS_INTRODUCE evtchn rebind function from cxenstored" added the exact same behavior in the OCaml XenStored last year. >>>> >>>> This was introduced 12 years after C XenStored, so surely someone think this is useful. We should check why this was introduced in OCaml XenStored (I have CCed the author of the patch). >>>> >>>> If we still think this is not useful, then you should add an explanation in the commit message why the two implementations diverge and possibly update the spec. >>> >>> Thanks for CC, Julien. >>> >>> We indeed already use this functionality in our toolstack for guest kdump >>> functions. It's not possible in XAPI to adopt libxl model where almost everything >>> is restarted for a domain entering kdump, so we have to use this message to >>> rebind xenstore evtchn after soft reset without shutting down backends and >>> recreating the whole subtree (frontends reconnect fine after that). >>> >>> We obviously only require it for now to be present in oxenstored only. >>> Please don't remove this functionality if possible. >> >> If I read handling in libxl correctly, in the soft reset case XS_RELEASE >> is issued before doing another XS_INTRODUCE. XS_RELEASE will result in >> xenstored throwing away its related struct domain, so XS_INTRODUCE will >> be possible again. > > From what I remember it was not possible to keep xenstored data for a domain > and at the same time perform release-introduce cycle (at least in oxenstored). > It also involved firing @releaseDomain which caused havoc in other part of > the toolstack. 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? Juergen