From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Cc: Bertrand.Marquis@arm.com, Luca Miccio <lucmiccio@gmail.com>,
Stefano Stabellini <stefano.stabellini@xilinx.com>,
wl@xen.org, Anthony PERARD <anthony.perard@citrix.com>,
Juergen Gross <jgross@suse.com>
Subject: Re: [XEN PATCH 6/7] xenstored: do_introduce: handle the late_init case
Date: Sat, 8 Jan 2022 07:54:58 +0400 [thread overview]
Message-ID: <3c2bb1e9-16d7-0329-9396-db7705f84ae6@xen.org> (raw)
In-Reply-To: <20220108004912.3820176-6-sstabellini@kernel.org>
Hi Stefano,
On 08/01/2022 00:49, Stefano Stabellini wrote:
> From: Luca Miccio <lucmiccio@gmail.com>
>
> If the function is called with late_init set then also notify the domain
> using the xenstore event channel.
>
> Signed-off-by: Luca Miccio <lucmiccio@gmail.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> CC: wl@xen.org
> CC: Anthony PERARD <anthony.perard@citrix.com>
> CC: Juergen Gross <jgross@suse.com>
> CC: julien@xen.org
> ---
> tools/xenstore/xenstored_domain.c | 15 ++++++++++-----
All the changes to the protocol should be reflected in
docs/misc/xenstore.txt. However...
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index d03c7d93a9..17b8021ca8 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -429,7 +429,7 @@ static void domain_conn_reset(struct domain *domain)
>
> static struct domain *introduce_domain(const void *ctx,
> unsigned int domid,
> - evtchn_port_t port, bool restore)
> + evtchn_port_t port, bool restore, bool late_init)
> {
> struct domain *domain;
> int rc;
> @@ -461,6 +461,9 @@ static struct domain *introduce_domain(const void *ctx,
> /* Now domain belongs to its connection. */
> talloc_steal(domain->conn, domain);
>
> + if (late_init)
> + xenevtchn_notify(xce_handle, domain->port);
... I am not convinced the parameter late_init is necessary. I believe
it would be safe to always raise an event channel because a domain
should be resilient (event channel are just to say "Please check the
status", there are no data carried).
If you really need late_init, then it should be made optional to avoid
breaking existing user of Xenstore (IHMO the protocol is stable and
should be backward compatible).
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2022-01-08 3:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 0:49 [XEN PATCH 0/7] dom0less PV drivers Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 1/7] xen: introduce XENFEAT_xenstore_late_init Stefano Stabellini
2022-01-08 3:41 ` Julien Grall
2022-01-10 22:55 ` Stefano Stabellini
2022-01-11 11:01 ` David Vrabel
2022-01-11 22:52 ` Stefano Stabellini
2022-01-10 9:46 ` Jan Beulich
2022-01-10 23:08 ` Stefano Stabellini
2022-01-11 7:14 ` Jan Beulich
2022-01-11 22:51 ` Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 2/7] xen: introduce _evtchn_alloc_unbound Stefano Stabellini
2022-01-10 10:25 ` Jan Beulich
2022-01-11 22:49 ` Stefano Stabellini
2022-01-12 7:42 ` Jan Beulich
2022-01-13 0:45 ` Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 3/7] tools: add a late_init argument to xs_introduce_domain Stefano Stabellini
2022-01-08 2:35 ` Marek Marczykowski-Górecki
2022-01-13 0:49 ` Stefano Stabellini
2022-01-08 3:46 ` Julien Grall
2022-01-08 0:49 ` [XEN PATCH 4/7] xen: introduce xen,enhanced dom0less property Stefano Stabellini
2022-01-11 3:31 ` Volodymyr Babchuk
2022-01-11 23:03 ` Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 5/7] xen/arm: configure dom0less domain for enabling xenstore after boot Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 6/7] xenstored: do_introduce: handle the late_init case Stefano Stabellini
2022-01-08 2:39 ` Marek Marczykowski-Górecki
2022-01-13 0:51 ` Stefano Stabellini
2022-01-08 3:54 ` Julien Grall [this message]
2022-01-10 22:48 ` Stefano Stabellini
2022-01-08 0:49 ` [XEN PATCH 7/7] tools: add example application to initialize dom0less PV drivers Stefano Stabellini
2022-01-08 4:02 ` Julien Grall
2022-01-10 22:57 ` Stefano Stabellini
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=3c2bb1e9-16d7-0329-9396-db7705f84ae6@xen.org \
--to=julien@xen.org \
--cc=Bertrand.Marquis@arm.com \
--cc=anthony.perard@citrix.com \
--cc=jgross@suse.com \
--cc=lucmiccio@gmail.com \
--cc=sstabellini@kernel.org \
--cc=stefano.stabellini@xilinx.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.