On Wed, 21 Oct 2020 09:37:53 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 21/10/20 00:44, Alex Williamson wrote: > > Do we necessarily need a memory map ioctl for this or could it be the > > QEMU code that compares the old and new maps to trigger map and unmap > > ioctls? For example (aiui) our race is that if we have contiguous > > memory regions A and B and flatview_simplify() tries to expand A and > > delete B we'll see a series of listener notifications deleting A and B > > and adding A'. But the vfio QEMU code could parse the memory map to > > determine that old A + B is functionally equivalent to A' and do > > nothing. > > I think the issue is a bit different, and in fact there are two sides of > the same issue. Say you have A (large) and it is replaced by A' > (smaller) + B, then: > > * the first part of A disappears for a moment before A' appears. This > is something that QEMU can work around, by not doing anything > > * the second part of A disappears for a moment before B appears. This > is the root API issue and not something that QEMU can work around; and > in fact it is not even fixed by removing flatview_simplify. Right, our current uAPI does not support a mechanism to atomically change a mapping, but likewise we're probably not going to have devices performing DMA to regions that are being remapped. We know that removing flatview_simplify() resolves this issue and FelixCui's update suggests we do have a case where the permission changes of an adjacent range is triggering a range consolidation, which we see as the range being removed and added as something else, larger or smaller. I can understand the general benefit of flatview_simplify(), but I wonder if the best short term solution is to skip operating on the x86 PAM range, which I understand to be a small number of memory chunks below 1MB. I might also wonder why the EHCI controller on this platform is choosing that range for DMA. Thanks, Alex
