All of lore.kernel.org
 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: 68+ 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 13:51   ` Paul Durrant
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 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.