[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
Re: [Qemu-devel] virtio-net and vhost-net init, virtio-scsi and vhost-scsi init
Fri, 6 May 2016 07:59:35 +0000
Yes it is.
From: Stefan Hajnoczi <address@hidden>
Sent: Thursday, May 5, 2016 9:00:33 PM
To: Catalin Vasile
Subject: Re: [Qemu-devel] virtio-net and vhost-net init, virtio-scsi and
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
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?