Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock

[Avi Kivity <avi@redhat.com>]

On 09/19/2012 12:34 PM, Jan Kiszka wrote:
> 
> What about the following:
> 
> What we really need to support in practice is MMIO access triggers RAM
> access of device model. Scenarios where a device access triggers another
> MMIO access could likely just be rejected without causing troubles.
> 
> So, when we dispatch a request to a device, we mark that the current
> thread is in a MMIO dispatch and reject any follow-up c_p_m_rw that does
> _not_ target RAM, ie. is another, nested MMIO request - independent of
> its destination. How much of the known issues would this solve? And what
> would remain open?

Various iommu-like devices re-dispatch I/O, like changing endianness or
bitband.  I don't know whether it targets I/O rather than RAM.

If they do, we can push the support into the memory API.  I think it's
acceptable as a short term solution (short term meaning as long as needed).



-- 
error compiling committee.c: too many arguments to function