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