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

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

[Catalin Vasile]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 963 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Catalin Vasile]

Yes it is.

Thanks
________________________________________
From: Stefan Hajnoczi <stefanha@gmail.com>
Sent: Thursday, May 5, 2016 9:00:33 PM
To: Catalin Vasile
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] virtio-net and vhost-net init, virtio-scsi and vhost-scsi init

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