Re: [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit

[Laszlo Ersek <lersek@redhat.com>]

On 12/13/17 10:29, Paolo Bonzini wrote:
> 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.

Hmmm, I'm not so sure about this, on a second thought. Reviewing the
OVMF code, I see that I added a comment (to all of the virtio drivers
actually):

>   //
>   // In virtio-1.0, feature negotiation is expected to complete before queue
>   // discovery, and the device can also reject the selected set of features.
>   //

I added this because of the following sections in the 1.0 spec:
- 3.1.1 Driver Requirements: Device Initialization
- 3.1.2 Legacy Interface: Device Initialization

In particular 3.1.2 writes, "The result was [...] steps 4, 7 and 8 were
conflated.".

(When I added virtio-1.0 support to OVMF, I paid attention to conform to
the new ordering for modern transports, and to keep the ordering
unchanged otherwise.)

I think this is a problem then; if a 1.0 driver is required to finish
feature negotiation (steps 4-6) before configuring the queues (step 7),
then the host side cannot derive any clues from the state of the queues
when the guest completes step 5 (= set FEATURES_OK).

Am I wrong?

... On the other hand, when the driver sets DRIVER_OK (step 8), then the
host *can* derive clues from the state of the queues; I think.

Thanks
Laszlo