All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall.oss@gmail.com>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred
Date: Tue, 28 Apr 2020 21:55:51 +0100	[thread overview]
Message-ID: <CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com> (raw)
In-Reply-To: <20200428155144.8253-1-jgross@suse.com>

Hi Juergen,

On Tue, 28 Apr 2020 at 16:53, Juergen Gross <jgross@suse.com> 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?

>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  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/

>         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?

Cheers,


  parent reply	other threads:[~2020-04-28 20:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 15:51 [PATCH] tools/xenstore: don't store domU's mfn of ring page in xensotred Juergen Gross
2020-04-28 20:54 ` Andrew Cooper
2020-04-28 20:55 ` Julien Grall [this message]
2020-04-29  5:51   ` Jürgen Groß
2020-04-29  9:22     ` Julien Grall
2020-04-29 10:39       ` Igor Druzhinin
2020-04-29 10:49         ` Jürgen Groß
2020-04-29 11:04           ` Igor Druzhinin
2020-04-29 12:29             ` Jürgen Groß
2020-04-29 12:49               ` Igor Druzhinin
2020-04-29 12:56                 ` Paul Durrant
2020-04-29 13:16                   ` Igor Druzhinin
2020-04-29 13:22                     ` Paul Durrant
2020-04-29 13:27                       ` Igor Druzhinin
2020-04-29 13:06                 ` Jürgen Groß
2020-04-29 13:39                   ` Igor Druzhinin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ=z9a0WfWQs+UJ-t4Kt6PGGdNnA2kMeK5p8bNnDT_eFcpDiiQ@mail.gmail.com' \
    --to=julien.grall.oss@gmail.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.