From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=pbonzini@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F0659220EE136 for ; Wed, 13 Dec 2017 01:25:20 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 061B2C0587E4; Wed, 13 Dec 2017 09:30:00 +0000 (UTC) Received: from [10.36.117.15] (ovpn-117-15.ams2.redhat.com [10.36.117.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4EA015C66F; Wed, 13 Dec 2017 09:29:55 +0000 (UTC) To: Laszlo Ersek , Zheng Xiang Cc: edk2-devel@lists.01.org, Ard Biesheuvel , Jordan Justen , Shannon Zhao , Maxime Coquelin References: <20171213031632.11856-1-zhengxiang9@huawei.com> <06533b91-8ff0-1ad2-56fa-5f2c4f56bb19@redhat.com> From: Paolo Bonzini Message-ID: <7161de6e-99c2-ed81-bbf6-c7a89336c36d@redhat.com> Date: Wed, 13 Dec 2017 10:29:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <06533b91-8ff0-1ad2-56fa-5f2c4f56bb19@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 13 Dec 2017 09:30:00 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:25:21 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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