[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree
From: |
Eugenio Perez Martin |
Subject: |
Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree |
Date: |
Wed, 20 Oct 2021 09:54:02 +0200 |
On Tue, Oct 19, 2021 at 11:23 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Tue, Oct 19, 2021 at 4:32 PM Jason Wang <jasowang@redhat.com> wrote:
> >
> >
> > 在 2021/10/1 下午3:06, Eugenio Pérez 写道:
> > > This tree is able to look for a translated address from an IOVA address.
> > >
> > > At first glance is similar to util/iova-tree. However, SVQ working on
> > > devices with limited IOVA space need more capabilities, like allocating
> > > IOVA chunks or perform reverse translations (qemu addresses to iova).
> >
> >
> > I don't see any reverse translation is used in the shadow code. Or
> > anything I missed?
>
> Ok, it looks to me that it is used in the iova allocator. But I think
> it's better to decouple it to an independent allocator instead of
> vhost iova tree.
>
Reverse translation is used every time a buffer is made available,
since buffers content are not copied, only the descriptors to SVQ
vring.
At this point all the limits are copied to vhost iova tree in the next
revision I will send, defined at its creation at
vhost_iova_tree_new(). They are outside of util/iova-tree, only sent
to the latter at allocation time.
Since vhost_iova_tree has its own vhost_iova_tree_alloc(), that wraps
the iova_tree_alloc() [1], limits could be kept in vhost-vdpa and make
them an argument of vhost_iova_tree_alloc. But I'm not sure if it's
what you are proposing or I'm missing something.
Either way, I think it is harder to talk about this specific case
without code, since this one still does not address the limits. Would
you prefer me to send another RFC in WIP quality, with *not* all
comments addressed? I would say that there is not a lot of pending
work to send the next one, but it might be easier for all of us.
Thanks!
[1] This util/iova-tree method will be proposed in the next series,
and vhost_iova_tree wraps it since it needs to keep in sync both
trees: iova->qemu vaddr for iova allocation and the reverse one to
translate available buffers.
> Thanks
>
- Re: [RFC PATCH v4 15/20] vhost: Shadow virtqueue buffers forwarding, (continued)
- [RFC PATCH v4 16/20] vhost: Check for device VRING_USED_F_NO_NOTIFY at shadow virtqueue kick, Eugenio Pérez, 2021/10/01
- [RFC PATCH v4 17/20] vhost: Use VRING_AVAIL_F_NO_INTERRUPT at device call on shadow virtqueue, Eugenio Pérez, 2021/10/01
- [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Eugenio Pérez, 2021/10/01
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/19
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/19
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree,
Eugenio Perez Martin <=
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/20
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Eugenio Perez Martin, 2021/10/20
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/20
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Eugenio Perez Martin, 2021/10/21
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/21
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Eugenio Perez Martin, 2021/10/21
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Jason Wang, 2021/10/26
- Re: [RFC PATCH v4 18/20] vhost: Add VhostIOVATree, Eugenio Perez Martin, 2021/10/20
[RFC PATCH v4 19/20] vhost: Use a tree to store memory mappings, Eugenio Pérez, 2021/10/01
[RFC PATCH v4 20/20] vdpa: Add custom IOTLB translations to SVQ, Eugenio Pérez, 2021/10/01