qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virtio-net and vhost-net init, virtio-scsi and vhost-sc


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] virtio-net and vhost-net init, virtio-scsi and vhost-scsi init
Date: Thu, 5 May 2016 19:00:33 +0100
User-agent: Mutt/1.6.0 (2016-04-01)

On Thu, May 05, 2016 at 11:05:27AM +0000, Catalin Vasile wrote:
> When the virtio-net and virtio-scsi drivers have done the probe() primitive 
> they set the DRIVER_OK flag.
> 
> If the vhost kernel backend is used, the set_status() primitive in qemu will 
> be triggered with DRIVER_OK status and it will trigger vhost_XXX_start().
> 
> How does the net and scsi solutions ensure that the vhost_XXX_start() 
> primitive has finished before sending jobs to through the virtqueues? Because 
> if vhost_XXX_start() has not finished, jobs might get to the qemu dummy 
> virtqueue handles, instead of getting to the vhost server in the host kernel.

The trick is to explicitly signal the ioeventfd.  See QEMU's
virtio_pci_set_host_notifier_internal():

  r = event_notifier_init(notifier, 1);

The '1' means the notifier is initialized in a readable state so whoever
is monitoring the file descriptor will be able to read right away.

Whether vhost receives the kick from the guest or not, it will
definitely notice that the ioeventfd can be read.  And maybe the
virtqueue has no new available buffers.  That's okay too, then this was
just a spurious wakeup.

Is this what you were asking about?

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]