On 2012-09-11 14:20, Avi Kivity wrote: > On 09/11/2012 02:08 PM, Jan Kiszka wrote: >> On 2012-09-11 13:03, Avi Kivity wrote: >>> On 09/11/2012 01:04 PM, Jan Kiszka wrote: >>> >>>>> DMA is inherently asynchronous, so we already drop the lock between >>>>> initiation and completion; we need to find a way to make it easy to use >>>>> the API without taking the lock while the transfer takes place. >>>> >>>> We will have to review/rework device models that want to use the new >>>> locking scheme in a way that they can drop their own lock while issuing >>>> DMA. But that is surely non-trivial. >>> >>> Most DMA today happens without the big qemu lock. We only need to >>> convert the paths that actually access memory, these are the block and >>> network layers (for the respective devices). >> >> ...and the devices themselves, of course. > > Right, for descriptors and stuff. So a guest can set a DMA address to > point at its own BAR, and cause qemu to deadlock. > > The problem is not limited to locking. A guest can also cause a write > to a BAR to initiate a synchronous write with the same address and data, > triggering infinite recursion. > > Perhaps one fix is the mythical DMA API, which will provide each DMA > initiator with its own view of memory (a private MemoryRegion root > node). Even that can be worked around with a pair of devices accessing > each other.
Hmm, don't see an alternative to runtime loop detection yet. > >> >>> >>>> The other option is to keep DMA requests issued by devices synchronous >>>> but let them fail if we are about to lock up. Still requires changes, >>>> but is probably more comprehensible for device model developers. >>> >>> How do you handle failures? >> >> By not sending a network frame or dropping an incoming one, e.g., and >> signaling this in a device specific way. > > Doesn't work for block devices. Because the block layer API cannot report errors to the devices? What happens if there is a real I/O error? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
