Re: [PATCH 1/1] Skip flatview_simplify() for cpu vendor zhaoxin

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 21 Oct 2020 09:37:53 +0200
Paolo Bonzini <pbonzini@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