qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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;
> +}



  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).