From: Paul Durrant <xadimgnik@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Joao Martins <joao.m.martins@oracle.com>,
Ankur Arora <ankur.a.arora@oracle.com>,
Stefano Stabellini <sstabellini@kernel.org>,
vikram.garhwal@amd.com,
Anthony Perard <anthony.perard@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH v1 05/25] hw/xen: Watches on XenStore transactions
Date: Tue, 7 Mar 2023 13:32:48 +0000 [thread overview]
Message-ID: <f133ca78-8b1e-149c-d907-7a843c8f322d@xen.org> (raw)
In-Reply-To: <20230302153435.1170111-6-dwmw2@infradead.org>
On 02/03/2023 15:34, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Firing watches on the nodes that still exist is relatively easy; just
> walk the tree and look at the nodes with refcount of one.
>
> Firing watches on *deleted* nodes is more fun. We add 'modified_in_tx'
> and 'deleted_in_tx' flags to each node. Nodes with those flags cannot
> be shared, as they will always be unique to the transaction in which
> they were created.
>
> When xs_node_walk would need to *create* a node as scaffolding and it
> encounters a deleted_in_tx node, it can resurrect it simply by clearing
> its deleted_in_tx flag. If that node originally had any *data*, they're
> gone, and the modified_in_tx flag will have been set when it was first
> deleted.
>
> We then attempt to send appropriate watches when the transaction is
> committed, properly delete the deleted_in_tx nodes, and remove the
> modified_in_tx flag from the others.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> hw/i386/kvm/xenstore_impl.c | 151 ++++++++++++++++++++++-
> tests/unit/test-xs-node.c | 231 +++++++++++++++++++++++++++++++++++-
> 2 files changed, 380 insertions(+), 2 deletions(-)
>
Reviewed-by: Paul Durrant <paul@xen.org>
... with a couple of nits in comments called out below...
[snip]
> +static gboolean tx_commit_walk(gpointer key, gpointer value,
> + gpointer user_data)
> +{
> + struct walk_op *op = user_data;
> + int path_len = strlen(op->path);
> + int key_len = strlen(key);
> + bool fire_parents = true;
> + XsWatch *watch;
> + XsNode *n = value;
> +
> + if (n->ref != 1) {
> + return false;
> + }
> +
> + if (n->deleted_in_tx) {
> + /*
> + * We first watches on our parents if we are the *first* node
We first *fire* watches on our parents...
> + * to be deleted (the topmost one). This matches the behaviour
> + * when deleting in the live tree.
> + */
> + fire_parents = !op->deleted_in_tx;
> +
> + /* Only used on the way down so no need to clear it later */
> + op->deleted_in_tx = true;
> + }
> +
> + assert(key_len + path_len + 2 <= sizeof(op->path));
> + op->path[path_len] = '/';
> + memcpy(op->path + path_len + 1, key, key_len + 1);
> +
> + watch = g_hash_table_lookup(op->s->watches, op->path);
> + if (watch) {
> + op->watches = g_list_append(op->watches, watch);
> + }
> +
> + if (n->children) {
> + g_hash_table_foreach_remove(n->children, tx_commit_walk, op);
> + }
> +
> + if (watch) {
> + op->watches = g_list_remove(op->watches, watch);
> + }
> +
> + /*
> + * Don't fire watches if this node was only copied because a
> + * descendent was changed. The modifieD_in_tx flag indicates the
s/modifieD/modified
> + * ones which were really changed.
> + */
> + if (n->modified_in_tx || n->deleted_in_tx) {
> + fire_watches(op, fire_parents);
> + n->modified_in_tx = false;
> + }
> + op->path[path_len] = '\0';
> +
> + /* Deleted nodes really do get expunged when we commit */
> + return n->deleted_in_tx;
> +}
next prev parent reply other threads:[~2023-03-07 13:33 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 15:34 [RFC PATCH v1 00/25] Enable PV backends with Xen/KVM emulation David Woodhouse
2023-03-02 15:34 ` [RFC PATCH v1 01/25] hw/xen: Add xenstore wire implementation and implementation stubs David Woodhouse
2023-03-07 10:55 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 02/25] hw/xen: Add basic XenStore tree walk and write/read/directory support David Woodhouse
2023-03-07 11:14 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 03/25] hw/xen: Implement XenStore watches David Woodhouse
2023-03-07 11:29 ` Paul Durrant
2023-03-07 12:20 ` David Woodhouse
2023-03-02 15:34 ` [RFC PATCH v1 04/25] hw/xen: Implement XenStore transactions David Woodhouse
2023-03-07 13:16 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 05/25] hw/xen: Watches on " David Woodhouse
2023-03-07 13:32 ` Paul Durrant [this message]
2023-03-07 13:37 ` David Woodhouse
2023-03-02 15:34 ` [RFC PATCH v1 06/25] hw/xen: Implement XenStore permissions David Woodhouse
2023-03-07 13:40 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 07/25] hw/xen: Implement core serialize/deserialize methods for xenstore_impl David Woodhouse
2023-03-07 16:33 ` David Woodhouse
2023-03-07 16:39 ` Paul Durrant
2023-03-07 16:45 ` Paul Durrant
2023-03-07 16:52 ` David Woodhouse
2023-03-07 16:59 ` Paul Durrant
2023-03-07 17:00 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 08/25] hw/xen: Create initial XenStore nodes David Woodhouse
2023-03-07 13:52 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 09/25] hw/xen: Add evtchn operations to allow redirection to internal emulation David Woodhouse
2023-03-07 14:04 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 10/25] hw/xen: Add gnttab " David Woodhouse
2023-03-07 14:22 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 11/25] hw/xen: Pass grant ref to gnttab unmap operation David Woodhouse
2023-03-07 14:30 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 12/25] hw/xen: Add foreignmem operations to allow redirection to internal emulation David Woodhouse
2023-03-07 14:40 ` Paul Durrant
2023-03-07 14:48 ` David Woodhouse
2023-03-07 14:54 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 13/25] hw/xen: Add xenstore " David Woodhouse
2023-03-07 14:44 ` Paul Durrant
2023-03-07 14:52 ` David Woodhouse
2023-03-07 14:55 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 14/25] hw/xen: Move xenstore_store_pv_console_info to xen_console.c David Woodhouse
2023-03-07 14:47 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 15/25] hw/xen: Use XEN_PAGE_SIZE in PV backend drivers David Woodhouse
2023-03-07 14:48 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 16/25] hw/xen: Rename xen_common.h to xen_native.h David Woodhouse
2023-03-07 14:58 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 17/25] hw/xen: Build PV backend drivers for CONFIG_XEN_BUS David Woodhouse
2023-03-07 15:42 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 18/25] hw/xen: Avoid crash when backend watch fires too early David Woodhouse
2023-03-07 15:43 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 19/25] hw/xen: Only advertise ring-page-order for xen-block if gnttab supports it David Woodhouse
2023-03-07 15:48 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 20/25] hw/xen: Hook up emulated implementation for event channel operations David Woodhouse
2023-03-07 15:50 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 21/25] hw/xen: Add emulated implementation of grant table operations David Woodhouse
2023-03-07 16:07 ` Paul Durrant
2023-03-07 16:16 ` David Woodhouse
2023-03-02 15:34 ` [RFC PATCH v1 22/25] hw/xen: Add emulated implementation of XenStore operations David Woodhouse
2023-03-07 16:21 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 23/25] hw/xen: Map guest XENSTORE_PFN grant in emulated Xenstore David Woodhouse
2023-03-07 16:26 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 24/25] hw/xen: Implement soft reset for emulated gnttab David Woodhouse
2023-03-07 16:29 ` Paul Durrant
2023-03-02 15:34 ` [RFC PATCH v1 25/25] i386/xen: Initialize Xen backends from pc_basic_device_init() for emulation David Woodhouse
2023-03-07 16:31 ` Paul Durrant
2023-03-07 16:21 ` [RFC PATCH v1 26/25] MAINTAINERS: Add entry for Xen on KVM emulation David Woodhouse
2023-03-07 16:32 ` Paul Durrant
2023-03-07 16:22 ` [RFC PATCH v1 27/25] docs: Update Xen-on-KVM documentation for PV disk support David Woodhouse
2023-03-07 16:33 ` Paul Durrant
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=f133ca78-8b1e-149c-d907-7a843c8f322d@xen.org \
--to=xadimgnik@gmail.com \
--cc=ankur.a.arora@oracle.com \
--cc=anthony.perard@citrix.com \
--cc=dwmw2@infradead.org \
--cc=joao.m.martins@oracle.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=vikram.garhwal@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).