All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugenio Perez Martin <eperezma@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-level <qemu-devel@nongnu.org>, Peter Xu <peterx@redhat.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Eli Cohen <eli@mellanox.com>, Eric Blake <eblake@redhat.com>,
	Parav Pandit <parav@mellanox.com>, Cindy Lu <lulu@redhat.com>,
	"Fangyi \(Eric\)" <eric.fangyi@huawei.com>,
	Markus Armbruster <armbru@redhat.com>,
	yebiaoxiang@huawei.com, Liuxiangdong <liuxiangdong5@huawei.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Gautam Dawar <gdawar@xilinx.com>,
	Xiao W Wang <xiao.w.wang@intel.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Harpreet Singh Anand <hanand@xilinx.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Lingshan <lingshan.zhu@intel.com>
Subject: Re: [PATCH v2 08/14] util: Add iova_tree_alloc
Date: Tue, 1 Mar 2022 11:06:04 +0100	[thread overview]
Message-ID: <CAJaqyWdNWqpdBQ-iTWLu7fH0prHPo8Uc1LXkEKvQ4X6cp7_TOA@mail.gmail.com> (raw)
In-Reply-To: <7829cc8d-66d0-cedd-eca5-f899cd5ecd07@redhat.com>

On Mon, Feb 28, 2022 at 7:39 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2022/2/27 下午9:41, Eugenio Pérez 写道:
> > This iova tree function allows it to look for a hole in allocated
> > regions and return a totally new translation for a given translated
> > address.
> >
> > It's usage is mainly to allow devices to access qemu address space,
> > remapping guest's one into a new iova space where qemu can add chunks of
> > addresses.
> >
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > Reviewed-by: Peter Xu <peterx@redhat.com>
> > ---
> >   include/qemu/iova-tree.h |  18 ++++++
> >   util/iova-tree.c         | 133 +++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 151 insertions(+)
> >
> > diff --git a/include/qemu/iova-tree.h b/include/qemu/iova-tree.h
> > index 8249edd764..a623136cd8 100644
> > --- a/include/qemu/iova-tree.h
> > +++ b/include/qemu/iova-tree.h
> > @@ -29,6 +29,7 @@
> >   #define  IOVA_OK           (0)
> >   #define  IOVA_ERR_INVALID  (-1) /* Invalid parameters */
> >   #define  IOVA_ERR_OVERLAP  (-2) /* IOVA range overlapped */
> > +#define  IOVA_ERR_NOMEM    (-3) /* Cannot allocate */
> >
> >   typedef struct IOVATree IOVATree;
> >   typedef struct DMAMap {
> > @@ -119,6 +120,23 @@ const DMAMap *iova_tree_find_address(const IOVATree *tree, hwaddr iova);
> >    */
> >   void iova_tree_foreach(IOVATree *tree, iova_tree_iterator iterator);
> >
> > +/**
> > + * iova_tree_alloc:
>
>
> Should be iova_tree_alloc_map.
>

That's right, I'll change. It's also missing from the patch subject.

>
> > + *
> > + * @tree: the iova tree to allocate from
> > + * @map: the new map (as translated addr & size) to allocate in the iova region
> > + * @iova_begin: the minimum address of the allocation
> > + * @iova_end: the maximum addressable direction of the allocation
> > + *
> > + * Allocates a new region of a given size, between iova_min and iova_max.
> > + *
> > + * Return: Same as iova_tree_insert, but cannot overlap and can return error if
> > + * iova tree is out of free contiguous range. The caller gets the assigned iova
> > + * in map->iova.
> > + */
> > +int iova_tree_alloc_map(IOVATree *tree, DMAMap *map, hwaddr iova_begin,
> > +                        hwaddr iova_end);
> > +
> >   /**
> >    * iova_tree_destroy:
> >    *
> > diff --git a/util/iova-tree.c b/util/iova-tree.c
> > index 23ea35b7a4..302b01f1cc 100644
> > --- a/util/iova-tree.c
> > +++ b/util/iova-tree.c
> > @@ -16,6 +16,39 @@ struct IOVATree {
> >       GTree *tree;
> >   };
> >
> > +/* Args to pass to iova_tree_alloc foreach function. */
> > +struct IOVATreeAllocArgs {
> > +    /* Size of the desired allocation */
> > +    size_t new_size;
> > +
> > +    /* The minimum address allowed in the allocation */
> > +    hwaddr iova_begin;
> > +
> > +    /* Map at the left of the hole, can be NULL if "this" is first one */
> > +    const DMAMap *prev;
> > +
> > +    /* Map at the right of the hole, can be NULL if "prev" is the last one */
> > +    const DMAMap *this;
> > +
> > +    /* If found, we fill in the IOVA here */
> > +    hwaddr iova_result;
> > +
> > +    /* Whether have we found a valid IOVA */
> > +    bool iova_found;
> > +};
> > +
> > +/**
> > + * Iterate args to the next hole
> > + *
> > + * @args  The alloc arguments
> > + * @next  The next mapping in the tree. Can be NULL to signal the last one
> > + */
> > +static void iova_tree_alloc_args_iterate(struct IOVATreeAllocArgs *args,
> > +                                         const DMAMap *next) {
> > +    args->prev = args->this;
> > +    args->this = next;
> > +}
> > +
> >   static int iova_tree_compare(gconstpointer a, gconstpointer b, gpointer data)
> >   {
> >       const DMAMap *m1 = a, *m2 = b;
> > @@ -107,6 +140,106 @@ int iova_tree_remove(IOVATree *tree, const DMAMap *map)
> >       return IOVA_OK;
> >   }
> >
> > +/**
> > + * Try to find an unallocated IOVA range between prev and this elements.
> > + *
> > + * @args Arguments to allocation
> > + *
> > + * Cases:
> > + *
> > + * (1) !prev, !this: No entries allocated, always succeed
> > + *
> > + * (2) !prev, this: We're iterating at the 1st element.
> > + *
> > + * (3) prev, !this: We're iterating at the last element.
> > + *
> > + * (4) prev, this: this is the most common case, we'll try to find a hole
> > + * between "prev" and "this" mapping.
> > + *
> > + * Note that this function assumes the last valid iova is HWADDR_MAX, but it
> > + * searches linearly so it's easy to discard the result if it's not the case.
> > + */
> > +static void iova_tree_alloc_map_in_hole(struct IOVATreeAllocArgs *args)
> > +{
> > +    const DMAMap *prev = args->prev, *this = args->this;
> > +    uint64_t hole_start, hole_last;
> > +
> > +    if (this && this->iova + this->size < args->iova_begin) {
> > +        return;
> > +    }
> > +
> > +    hole_start = MAX(prev ? prev->iova + prev->size + 1 : 0, args->iova_begin);
> > +    hole_last = this ? this->iova : HWADDR_MAX;
>
>
> Do we need to use iova_last instead of HWADDR_MAX?
>

If I re-add iova_last to this function, this first part is the same as
RFC v5. The only difference would be iova_found.

To simplify this function, I extracted the iova_last check to
iova_tree_alloc_map. I thought this was closer to what you proposed.
As a disadvantage, the search could go beyond iova_last, but this
should not be common.

I'm ok with both versions.

>
> > +
> > +    if (hole_last - hole_start > args->new_size) {
> > +        args->iova_result = hole_start;
> > +        args->iova_found = true;
> > +    }
> > +}
> > +
> > +/**
> > + * Foreach dma node in the tree, compare if there is a hole with its previous
> > + * node (or minimum iova address allowed) and the node.
> > + *
> > + * @key   Node iterating
> > + * @value Node iterating
> > + * @pargs Struct to communicate with the outside world
> > + *
> > + * Return: false to keep iterating, true if needs break.
> > + */
> > +static gboolean iova_tree_alloc_traverse(gpointer key, gpointer value,
> > +                                         gpointer pargs)
> > +{
> > +    struct IOVATreeAllocArgs *args = pargs;
> > +    DMAMap *node = value;
> > +
> > +    assert(key == value);
> > +
> > +    iova_tree_alloc_args_iterate(args, node);
> > +    iova_tree_alloc_map_in_hole(args);
> > +    return args->iova_found;
> > +}
> > +
> > +int iova_tree_alloc_map(IOVATree *tree, DMAMap *map, hwaddr iova_begin,
> > +                        hwaddr iova_last)
> > +{
> > +    struct IOVATreeAllocArgs args = {
> > +        .new_size = map->size,
> > +        .iova_begin = iova_begin,
> > +    };
> > +
> > +    assert(iova_begin < iova_last);
>
>
> Should we use "<=" here, otherwise we disallow allocate the size of 1.
>
> And maybe we should return error instead of assert.
>

Right, I'll replace both.

>
> > +
> > +    /*
> > +     * Find a valid hole for the mapping
> > +     *
> > +     * Assuming low iova_begin, so no need to do a binary search to
> > +     * locate the first node.
> > +     *
> > +     * TODO: Replace all this with g_tree_node_first/next/last when available
> > +     * (from glib since 2.68). To do it with g_tree_foreach complicates the
> > +     * code a lot.
> > +     *
>
>
> One more question
>
> The current code looks work but still a little bit complicated to be
> reviewed. Looking at the missing helpers above, if the add and remove
> are seldom. I wonder if we can simply do
>
> g_tree_foreach() during each add/del to build a sorted list then we can
> emulate g_tree_node_first/next/last easily?
>

This sounds a lot like the method in v1 [1] :).

But it didn't use the O(N) foreach, since we can locate the new node's
previous element looking for the upper bound of iova-1, maintaining
the insertion's complexity O(log(N)). The function g_tree_upper_bound
is added in Glib version 2.68, so the proposed version will be deleted
sooner or later.

Also the deletion keeps being O(log(N)) since deleting a node in QLIST is O(1).

>
> > +     */
> > +    g_tree_foreach(tree->tree, iova_tree_alloc_traverse, &args);
> > +    if (!args.iova_found) {
> > +        /*
> > +         * Either tree is empty or the last hole is still not checked.
> > +         * g_tree_foreach does not compare (last, iova_end] range, so we check
>
>
> "(last, iova_last]" ?
>

Right, I'll change it too.

Thanks!

[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg863699.html
[2] https://docs.gtk.org/glib/method.Tree.upper_bound.html

> Thanks
>
>
> > +         * it here.
> > +         */
> > +        iova_tree_alloc_args_iterate(&args, NULL);
> > +        iova_tree_alloc_map_in_hole(&args);
> > +    }
> > +
> > +    if (!args.iova_found || args.iova_result + map->size > iova_last) {
> > +        return IOVA_ERR_NOMEM;
> > +    }
> > +
> > +    map->iova = args.iova_result;
> > +    return iova_tree_insert(tree, map);
> > +}
> > +
> >   void iova_tree_destroy(IOVATree *tree)
> >   {
> >       g_tree_destroy(tree->tree);
>



  reply	other threads:[~2022-03-01 10:36 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-27 13:40 [PATCH v2 00/14] vDPA shadow virtqueue Eugenio Pérez
2022-02-27 13:40 ` [PATCH v2 01/14] vhost: Add VhostShadowVirtqueue Eugenio Pérez
2022-02-27 13:40 ` [PATCH v2 02/14] vhost: Add Shadow VirtQueue kick forwarding capabilities Eugenio Pérez
2022-02-28  2:57   ` Jason Wang
2022-02-28  2:57     ` Jason Wang
2022-03-01 18:49     ` Eugenio Perez Martin
2022-03-03  7:12       ` Jason Wang
2022-03-03  7:12         ` Jason Wang
2022-03-03  9:24         ` Eugenio Perez Martin
2022-03-04  1:39           ` Jason Wang
2022-03-04  1:39             ` Jason Wang
2022-02-27 13:41 ` [PATCH v2 03/14] vhost: Add Shadow VirtQueue call " Eugenio Pérez
2022-02-28  3:18   ` Jason Wang
2022-02-28  3:18     ` Jason Wang
2022-03-01 11:18     ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 04/14] vhost: Add vhost_svq_valid_features to shadow vq Eugenio Pérez
2022-02-28  3:25   ` Jason Wang
2022-02-28  3:25     ` Jason Wang
2022-03-01 19:18     ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 05/14] virtio: Add vhost_shadow_vq_get_vring_addr Eugenio Pérez
2022-02-27 13:41 ` [PATCH v2 06/14] vdpa: adapt vhost_ops callbacks to svq Eugenio Pérez
2022-02-28  3:59   ` Jason Wang
2022-02-28  3:59     ` Jason Wang
2022-03-01 19:31     ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 07/14] vhost: Shadow virtqueue buffers forwarding Eugenio Pérez
2022-02-28  5:39   ` Jason Wang
2022-02-28  5:39     ` Jason Wang
2022-03-02 18:23     ` Eugenio Perez Martin
2022-03-03  7:35       ` Jason Wang
2022-03-03  7:35         ` Jason Wang
2022-02-27 13:41 ` [PATCH v2 08/14] util: Add iova_tree_alloc Eugenio Pérez
2022-02-28  6:39   ` Jason Wang
2022-02-28  6:39     ` Jason Wang
2022-03-01 10:06     ` Eugenio Perez Martin [this message]
2022-03-03  7:16       ` Jason Wang
2022-03-03  7:16         ` Jason Wang
2022-02-27 13:41 ` [PATCH v2 09/14] vhost: Add VhostIOVATree Eugenio Pérez
2022-02-28  7:06   ` Jason Wang
2022-02-28  7:06     ` Jason Wang
2022-03-03 16:32     ` Eugenio Perez Martin
2022-03-04  2:04       ` Jason Wang
2022-03-04  2:04         ` Jason Wang
2022-03-04  8:01         ` Eugenio Perez Martin
2022-03-07  3:41           ` Jason Wang
2022-03-07  3:41             ` Jason Wang
2022-03-07  8:56             ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 10/14] vdpa: Add custom IOTLB translations to SVQ Eugenio Pérez
2022-02-28  7:36   ` Jason Wang
2022-02-28  7:36     ` Jason Wang
2022-03-01  8:50     ` Eugenio Perez Martin
2022-03-03  7:33       ` Jason Wang
2022-03-03  7:33         ` Jason Wang
2022-03-03 11:35         ` Eugenio Perez Martin
2022-03-07  4:24           ` Jason Wang
2022-03-07  4:24             ` Jason Wang
2022-03-07  7:44             ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 11/14] vdpa: Adapt vhost_vdpa_get_vring_base " Eugenio Pérez
2022-02-28  7:38   ` Jason Wang
2022-02-28  7:38     ` Jason Wang
2022-03-01  7:51     ` Eugenio Perez Martin
2022-02-27 13:41 ` [PATCH v2 12/14] vdpa: Never set log_base addr if SVQ is enabled Eugenio Pérez
2022-02-27 13:41 ` [PATCH v2 13/14] vdpa: Expose VHOST_F_LOG_ALL on SVQ Eugenio Pérez
2022-02-27 13:41 ` [PATCH v2 14/14] vdpa: Add x-svq to NetdevVhostVDPAOptions Eugenio Pérez
2022-02-28  2:32 ` [PATCH v2 00/14] vDPA shadow virtqueue Jason Wang
2022-02-28  2:32   ` Jason Wang
2022-03-01 11:36   ` Eugenio Perez Martin
2022-02-28  7:41 ` Jason Wang
2022-02-28  7:41   ` Jason Wang
2022-03-02 20:30   ` Eugenio Perez Martin

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=CAJaqyWdNWqpdBQ-iTWLu7fH0prHPo8Uc1LXkEKvQ4X6cp7_TOA@mail.gmail.com \
    --to=eperezma@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=eli@mellanox.com \
    --cc=eric.fangyi@huawei.com \
    --cc=gdawar@xilinx.com \
    --cc=hanand@xilinx.com \
    --cc=jasowang@redhat.com \
    --cc=lingshan.zhu@intel.com \
    --cc=liuxiangdong5@huawei.com \
    --cc=lulu@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@mellanox.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=richard.henderson@linaro.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xiao.w.wang@intel.com \
    --cc=yebiaoxiang@huawei.com \
    /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.