On Wed, Sep 19, 2012 at 5:50 PM, Avi Kivity <a...@redhat.com> 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