On Thu, Jun 28, 2012 at 09:10:39AM -0500, Anthony Liguori wrote: > > > >1. read_lock(memmap_lock) > >2. MemoryRegionSection mrs = lookup(addr) > >3. qom_ref(mrs.mr->dev) > >4. read_unlock(memmap_lock) > > > >5. mutex_lock(dev->lock) > >6. dispatch(&mrs, addr, data, size) > >7. mutex_unlock(dev->lock) > > Just a detail, I don't think we should acquire a device specific > lock in global code. Rather, I think we should acquire the global > lock before dispatch unless a MemoryRegion is marked as being > unlocked. "The basic plan is introduce granular locking starting at the KVM dispatch level until we can get to MemoryRegion dispatch. We'll then have some way to indicate that a MemoryRegion's callbacks should be invoked without holding the qemu global mutex." Before that is possible, the callback must not make use of data structures currently protected by qemu_global_mutex, such as timers, interrupts (that is, you would have to split locks for each individual service invoked from inside callbacks, which is a recipe for disaster). With lock_device() below you can have mutex_lock(dev->lock) device specific work mutex_lock(qemu_global_mutex) raise irq, send packet, etc mutex_unlock(qemu_global_mutex) mutex_unlock(dev->lock) and iothread doing the select() pseudocode in the previous email. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
