On Tue, Sep 17, 2013 at 06:58:37PM +0200, Paolo Bonzini wrote: > 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.
We can argue about RAM but getting callback after disable is not really sane. > 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. I don't see why can't disable MR flush whatever is outstanding. > 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. They don't happen on real hardware because once you disable memory in a PCI device, it does not accept memory transactions. > 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. I don't see why is this a problem. So memory disable will take a long time. Who cares? It's not data path. > 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 We need to cover it without breaking APIs. After memory_region_del_subregion returns, it's a promise that there will not be accesses to the region. So I'm not even sure we really need to move destroy to finalize anymore ... -- MST
