On Tue, May 7, 2024 at 6:57 PM Eugenio Perez Martin <epere...@redhat.com> wrote: > > On Tue, May 7, 2024 at 9:29 AM Jason Wang <jasow...@redhat.com> wrote: > > > > On Fri, Apr 12, 2024 at 3:56 PM Eugenio Perez Martin > > <epere...@redhat.com> wrote: > > > > > > On Fri, Apr 12, 2024 at 8:47 AM Jason Wang <jasow...@redhat.com> wrote: > > > > > > > > On Wed, Apr 10, 2024 at 6:03 PM Eugenio Pérez <epere...@redhat.com> > > > > wrote: > > > > > > > > > > The guest may have overlapped memory regions, where different GPA > > > > > leads > > > > > to the same HVA. This causes a problem when overlapped regions > > > > > (different GPA but same translated HVA) exists in the tree, as looking > > > > > them by HVA will return them twice. > > > > > > > > I think I don't understand if there's any side effect for shadow > > > > virtqueue? > > > > > > > > > > My bad, I totally forgot to put a reference to where this comes from. > > > > > > Si-Wei found that during initialization this sequences of maps / > > > unmaps happens [1]: > > > > > > HVA GPA IOVA > > > ------------------------------------------------------------------------------------------------------------------------- > > > Map > > > [0x7f7903e00000, 0x7f7983e00000) [0x0, 0x80000000) [0x1000, 0x80000000) > > > [0x7f7983e00000, 0x7f9903e00000) [0x100000000, 0x2080000000) > > > [0x80001000, 0x2000001000) > > > [0x7f7903ea0000, 0x7f7903ec0000) [0xfeda0000, 0xfedc0000) > > > [0x2000001000, 0x2000021000) > > > > > > Unmap > > > [0x7f7903ea0000, 0x7f7903ec0000) [0xfeda0000, 0xfedc0000) [0x1000, > > > 0x20000) ??? > > > > > > The third HVA range is contained in the first one, but exposed under a > > > different GVA (aliased). This is not "flattened" by QEMU, as GPA does > > > not overlap, only HVA. > > > > > > At the third chunk unmap, the current algorithm finds the first chunk, > > > not the second one. This series is the way to tell the difference at > > > unmap time. > > > > > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2024-04/msg00079.html > > > > > > Thanks! > > > > Ok, I was wondering if we need to store GPA(GIOVA) to HVA mappings in > > the iova tree to solve this issue completely. Then there won't be > > aliasing issues. > > > > I'm ok to explore that route but this has another problem. Both SVQ > vrings and CVQ buffers also need to be addressable by VhostIOVATree, > and they do not have GPA. > > At this moment vhost_svq_translate_addr is able to handle this > transparently as we translate vaddr to SVQ IOVA. How can we store > these new entries? Maybe a (hwaddr)-1 GPA to signal it has no GPA and > then a list to go through other entries (SVQ vaddr and CVQ buffers).
This seems to be tricky. As discussed, it could be another iova tree. Thanks > > Thanks! > > > Thanks > > > > > > > > > Thanks > > > > > > > > > > > > > > To solve this, track GPA in the DMA entry that acs as unique > > > > > identifiers > > > > > to the maps. When the map needs to be removed, iova tree is able to > > > > > find the right one. > > > > > > > > > > Users that does not go to this extra layer of indirection can use the > > > > > iova tree as usual, with id = 0. > > > > > > > > > > This was found by Si-Wei Liu <si-wei....@oracle.com>, but I'm having > > > > > a hard > > > > > time to reproduce the issue. This has been tested only without > > > > > overlapping > > > > > maps. If it works with overlapping maps, it will be intergrated in > > > > > the main > > > > > series. > > > > > > > > > > Comments are welcome. Thanks! > > > > > > > > > > Eugenio Pérez (2): > > > > > iova_tree: add an id member to DMAMap > > > > > vdpa: identify aliased maps in iova_tree > > > > > > > > > > hw/virtio/vhost-vdpa.c | 2 ++ > > > > > include/qemu/iova-tree.h | 5 +++-- > > > > > util/iova-tree.c | 3 ++- > > > > > 3 files changed, 7 insertions(+), 3 deletions(-) > > > > > > > > > > -- > > > > > 2.44.0 > > > > > > > > > > > > > > >
