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
