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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-09-19 11:50, Avi Kivity wrote:
> 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 such dispatching is lock-less and we validate it's not recursive,
then it should be fine even when not targeting RAM. And we could also
factor out generic dispatchers like MMIO->PIO.

> 
> 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).

We will always have to avoid loops. I think all we can improve is what
we still allow by better detecting what would be wrong.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux