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=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 14559C83003 for ; Wed, 29 Apr 2020 05:51:30 +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 E2C4B206F0 for ; Wed, 29 Apr 2020 05:51:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2C4B206F0 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 1jTfct-0003px-3d; Wed, 29 Apr 2020 05:51:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jTfcr-0003pr-Co for xen-devel@lists.xenproject.org; Wed, 29 Apr 2020 05:51:17 +0000 X-Inumbo-ID: 7057b296-89dd-11ea-ae69-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7057b296-89dd-11ea-ae69-bc764e2007e4; Wed, 29 Apr 2020 05:51:15 +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 1C630AC79; Wed, 29 Apr 2020 05:51:14 +0000 (UTC) Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred To: Julien Grall References: <20200428155144.8253-1-jgross@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Wed, 29 Apr 2020 07:51:13 +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: 7bit 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 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 28.04.20 22:55, Julien Grall wrote: > Hi Juergen, > > On Tue, 28 Apr 2020 at 16:53, Juergen Gross wrote: >> >> The XS_INTRODUCE command has two parameters: the mfn (or better: gfn) >> of the domain's xenstore ring page and the event channel of the >> domain for communicating with Xenstore. >> >> The gfn is not really needed. It is stored in the per-domain struct >> in xenstored and in case of another XS_INTRODUCE for the domain it >> is tested to match the original value. If it doesn't match the >> command is aborted via EINVAL. >> >> Today there shouldn't be multiple XS_INTRODUCE requests for the same >> domain issued, so the mfn/gfn can just be ignored and multiple >> XS_INTRODUCE commands can be rejected without testing the mfn/gfn. > > So there is a comment in the else part: > > /* Use XS_INTRODUCE for recreating the xenbus event-channel. */ > > From the commit message this is not entirely clear why we want to > prevent recreating the event-channel. Can you expand it? 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. > >> >> Signed-off-by: Juergen Gross >> --- >> tools/xenstore/xenstored_domain.c | 47 ++++++++++++++++----------------------- >> 1 file changed, 19 insertions(+), 28 deletions(-) >> >> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c >> index 5858185211..17328f9fc9 100644 >> --- a/tools/xenstore/xenstored_domain.c >> +++ b/tools/xenstore/xenstored_domain.c >> @@ -369,7 +369,6 @@ int do_introduce(struct connection *conn, struct buffered_data *in) >> struct domain *domain; >> char *vec[3]; >> unsigned int domid; >> - unsigned long mfn; >> evtchn_port_t port; >> int rc; >> struct xenstore_domain_interface *interface; >> @@ -381,7 +380,7 @@ int do_introduce(struct connection *conn, struct buffered_data *in) >> return EACCES; >> >> domid = atoi(vec[0]); >> - mfn = atol(vec[1]); >> + /* Ignore the mfn, we don't need it. */ > > s/mfn/GFN/ Okay, then I should probably change the parameter description, too. > >> port = atoi(vec[2]); >> >> /* Sanity check args. */ >> @@ -390,34 +389,26 @@ int do_introduce(struct connection *conn, struct buffered_data *in) >> >> domain = find_domain_by_domid(domid); >> >> - if (domain == NULL) { >> - interface = map_interface(domid); >> - if (!interface) >> - return errno; >> - /* Hang domain off "in" until we're finished. */ >> - domain = new_domain(in, domid, port); >> - if (!domain) { >> - rc = errno; >> - unmap_interface(interface); >> - return rc; >> - } >> - domain->interface = interface; >> - domain->mfn = mfn; > > AFAICT domain->mfn is not used anymore, so could we remove the field? Oh, yes, I missed that. Juergen