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
