On Fri, Jun 25, 2010 at 4:09 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: > On Thu, 24 Jun 2010 03:00:30 pm Stefan Hajnoczi wrote: >> On Wed, Jun 23, 2010 at 11:12 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: >> > Shouldn't it be possible to just drop the lock before invoking >> > virtqueue_kick() and reacquire it afterwards? There's nothing in that >> > virtqueue_kick() path that the lock is protecting AFAICT. >> >> No, that would lead to a race condition because vq->num_added is >> modified by both virtqueue_add_buf_gfp() and virtqueue_kick(). >> Without a lock held during virtqueue_kick() another vcpu could add >> bufs while vq->num_added is used and cleared by virtqueue_kick(): > > Right, this dovetails with another proposed change (was it Michael?) > where we would update the avail idx inside add_buf, rather than waiting > until kick. This means a barrier inside add_buf, but that's probably > fine. > > If we do that, then we don't need a lock on virtqueue_kick. That would be nice, we could push the change up into just virtio-blk. I did wonder if virtio-net can take advantage of unlocked kick, too, but haven't investigated yet. The virtio-net kick in start_xmit() happens with the netdev _xmit_lock held. Any ideas? Stefan -- 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
