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. > >> 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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
