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=maxime.coquelin@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 EB5DE2205B923 for ; Thu, 11 Jan 2018 05:18:21 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 32EEB642; Thu, 11 Jan 2018 13:23:34 +0000 (UTC) Received: from [10.36.112.28] (ovpn-112-28.ams2.redhat.com [10.36.112.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F32567644; Thu, 11 Jan 2018 13:23:29 +0000 (UTC) To: "zhengxiang (A)" , Paolo Bonzini , Laszlo Ersek Cc: edk2-devel@lists.01.org, Ard Biesheuvel , Jordan Justen , Shannon Zhao References: <20171213031632.11856-1-zhengxiang9@huawei.com> <06533b91-8ff0-1ad2-56fa-5f2c4f56bb19@redhat.com> <7161de6e-99c2-ed81-bbf6-c7a89336c36d@redhat.com> <835f9103-1892-4963-9bbb-1fa9b417af60@huawei.com> From: Maxime Coquelin Message-ID: <8940cc0e-64e7-c253-a8e0-5081eab4efbe@redhat.com> Date: Thu, 11 Jan 2018 14:23:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <835f9103-1892-4963-9bbb-1fa9b417af60@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 11 Jan 2018 13:23:34 +0000 (UTC) X-Mailman-Approved-At: Thu, 11 Jan 2018 05:58:48 -0800 Subject: Re: [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 13:18:22 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Xiang, On 12/14/2017 02:25 PM, zhengxiang (A) wrote: > > > On 2017/12/14 17:06, Paolo Bonzini wrote: >> On 14/12/2017 07:55, zhengxiang (A) wrote: >>> Hello Laszlo and Paolo, >>> >>> Thanks for your review! >>> >>> On 2017/12/13 19:16, Laszlo Ersek wrote: >>>> On 12/13/17 10:29, Paolo Bonzini wrote: >>>>> On 13/12/2017 09:35, Laszlo Ersek wrote: >>>>>> 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. >>> >>> I would try this solution! However, is there any possibility that the allocated >>> descriptor address is exactly equal to zero and the queue is in use? >> >> That would break QEMU's virtio implementation, so it's pretty unlikely. >> >> Paolo >> > > So could I judge the not-in-use queues by adding the below sentence in order > to skip calling vhost_virtqueue_start? > > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c > index e4290ce..05c3322 100644 > --- a/hw/virtio/vhost.c > +++ b/hw/virtio/vhost.c > @@ -1532,6 +1532,7 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev) > goto fail_mem; > } > for (i = 0; i < hdev->nvqs; ++i) { > + if (virtio_queue_get_desc_addr(vdev, i) == 0) continue; > r = vhost_virtqueue_start(hdev, > vdev, > hdev->vqs + i, > I think it should work, or you could detect it by checking that desc, used and avail rings have the same address. We would need this also for virtio-net, as Windows guest only setup as much queue pairs as vcpus, but vhost_virtqueue_start is called for all queue pairs declred in QEMU. With DPDK Vhost-user backend, it turns out that it uses these uninitialized queues, corrupting guest's physical address 0. Do you plan to post the fix, or you'd like me to propose it? Thanks, Maxime > Thanks, > Xiang >