public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Zheng Xiang <zhengxiang9@huawei.com>
Cc: edk2-devel@lists.01.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit
Date: Wed, 13 Dec 2017 10:29:54 +0100	[thread overview]
Message-ID: <7161de6e-99c2-ed81-bbf6-c7a89336c36d@redhat.com> (raw)
In-Reply-To: <06533b91-8ff0-1ad2-56fa-5f2c4f56bb19@redhat.com>

On 13/12/2017 09:35, Laszlo Ersek wrote:
> I consider the lack of a "VIRTIO_SCSI_F_MQ" feature bit an issue with
> the virtio specification (and consequently with vhost-scsi), not with
> the guest driver(s).

VIRTIO_SCSI_F_MQ does not exist because virtio-scsi has _always_
supported multiqueue and has always had a "num_queues" field in the
configuration space.  For virtio-net, VIRTIO_NET_F_MQ does not say "the
device or driver knows about multiqueue", it says "the device or driver
wants to read max_virtqueue_pairs" from configuration space.  It's
perfectly fine for a device to propose VIRTIO_NET_F_MQ and set
max_virtqueue_pairs=1, or for a driver to negotiate VIRTIO_NET_F_MQ and
then skip initialization of some virtqueues.

This also means that Maxime's patch to DPDK is also not enough. :)
Virtio-net actually does have a configuration mechanism for multiqueue,
namely the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command; the driver sends
that command specifying the number of the transmit and receive queues to
use.  However, in my understanding, that command is only needed for the
device to configure receive flow steering, so virtio-scsi doesn't need
that either.

> Perhaps you can update vhost-scsi similarly to the last patch of
> Maxime's v4 series, even without "VIRTIO_SCSI_F_MQ" -- in the
> SET_FEATURES request handler, just destroy the unused virtqueues that
> have not been configured by the guest driver until that time?

Yes, this is the right solution.  We can assume that if the descriptor
address is equal to zero, the queue is not in use.  This is not in the
spec as far as I can see, but it is QEMU's assumption.  I will send a
patch to the virtio specification.

Paolo


  reply	other threads:[~2017-12-13  9:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13  3:16 [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit Zheng Xiang
2017-12-13  8:35 ` Laszlo Ersek
2017-12-13  9:29   ` Paolo Bonzini [this message]
2017-12-13 11:04     ` Laszlo Ersek
2017-12-13 11:16     ` Laszlo Ersek
2017-12-14  6:55       ` zhengxiang (A)
2017-12-14  9:06         ` Paolo Bonzini
2017-12-14 13:25           ` zhengxiang (A)
2018-01-11 13:23             ` Maxime Coquelin
2018-01-11 14:46               ` Maxime Coquelin
2018-01-12  1:35                 ` zhengxiang (A)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7161de6e-99c2-ed81-bbf6-c7a89336c36d@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox