On 2015-03-18 15:52, Paolo Bonzini wrote: > > > On 18/03/2015 15:33, Jan Kiszka wrote: >> Just in time: I'm planning to rebase our queue soon, specifically to >> benefit from RCU support. Will let you know if it works on top of this >> series. > > Great. FWIW, this is the most similar version to the one we played with > in 2013. > > I have an alternative one that keeps the single address_space_rw API, > and checks if you have the iothread mutex using thread-local storage.
qemu_mutex_iothread_is_locked() with a qemu_global_mutex-specific flag or qemu_mutex_is_locked(&qemu_global_mutex)? > The reason for that is that I would have to introduce > address_space_map/unmap_unlocked too, which I didn't really like. Also, > in the not-so-long term we want the same code (e.g. SCSI layer) to run > in both locked and unlocked mode. > > What do you think? I cannot envision the code differences yet as we didn't have the need to play with lockless MMIO or even DMA so far (will probably happen soon, though - for networking). For me it boils down to the code impact as well, how much we can reuse by hiding locked vs. unlocked mode, and how much we may make more fragile and harder to design correctly by doing so. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
