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

[liu ping fan]

On Wed, Sep 19, 2012 at 5:50 PM, Avi Kivity <address@hidden> 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.
>
Have not found the exact code. But I think the call chain may look
like this: dev mmio-handler --> c_p_m_rw() --> iommu mmio-handler -->
c_p_m_rw()
And I think you worry about the case for "c_p_m_rw() --> iommu
mmio-handler". Right? How about introduce an member can_nest for
MemoryRegionOps of iommu's mr?

Regards,
pingfan

> 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