Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to instance_finalize

[Paolo Bonzini]

Il 17/09/2013 18:29, Michael S. Tsirkin ha scritto:
> > BTW, qemu_del_nic is another one that I forgot to mention.  You could
> > have MMIO that triggers a transmit while the device is going down, for
> > example.
> 
> Wait a second.  This API simply does not make sense.
> If region is not visible it's MMIO really mustn't trigger,
> exit or no exit.  Disabling region and still getting op callbacks
> afterwards is not what any caller of this API expects.
> 
> I'm not sure what to do about the bounce buffer thing
> but it needs to be fixed some other way without
> breaking API.

I don't think it's breaking the API.  The very same thing can happen
with RAM.  The only difference is that MMIO calls ops.

Also, this problem is subject to race conditions from buggy or
misbehaving guests.  If you want to have any hope of breaking devices
free of the BQL and do "simple" register I/O without taking a lock,
there is simply no precise moment to stop MMIO at.

All these problems do not happen in real hardware because real hardware
has buffers between the PHY and DMA circuitries, and because bus master
transactions transfer few bytes at a time (for example in PCI even when
a device does burst transactions, the other party can halt them with
such a small granularity).  A device can be quiesced in a matter of
microseconds, and other times (the time for the OS to react to hotplug
requests, the time for the driver to shut down, the time for the human
to physically unplug the connector) can be several order of magnitudes
larger.

Instead we have the opposite scenario, because we want to have as few
buffers as possible and map large amounts of memory (even 4K used by the
bounce buffer is comparatively large) for the host OS's benefit.  When
we do so, and the host backend fails (e.g. a disk is on NFS and there is
a networking problem), memory can remain mapped for a long time.

DMA-to-MMIO may be a theoretical problems only, but if we don't cover it
we have a bogus solution to the problem, because exactly the same thing
can and will happen for memory hot-unplug.

Paolo