From nobody Mon Apr 29 00:27:33 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; t=1577101153; cv=none; d=zohomail.com; s=zohoarc; b=NqV9LQf6eMVx03NYyP1WXkZm7RhNK/bJ1nZPJdzUwoRG1cWDVcQDrcR7TzBgUxJMgVAylloWpn3lX1Rch5ENRlfDvhzz28w5VJksbzOfclSCzZdkVTth5rbJdBHUlbtgpz8EsAWQGdcEPQrVbOum3aZt0pBWYjNGKmBhv7JC3GQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1577101153; h=Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:Sender:Subject:To; bh=4cYfY5xNrhd0HQNEbXGFgM3ulhOE4lkTpyGZwMBzMIU=; b=H49nwFH7QXkqC7FvptpVpjiuJD/gtTLGJGrVCJJZi8CejBSQ5aumAmHNiwpAB30TJq6NFH4IcfN0Z2QAVaf9pkgWtT/03InsqXrfvZPhLosmElG3CCLdjmmVs8zRTD4F6ELcrJ02Eca3OZB+CmkCh9nmb041qBirvfvCcmzZH+I= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1577101153187499.3467513746841; Mon, 23 Dec 2019 03:39:13 -0800 (PST) Received: from localhost ([::1]:55948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijM3K-0004mZ-TL for importer@patchew.org; Mon, 23 Dec 2019 06:39:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48639) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijM2Q-0004JL-0P for qemu-devel@nongnu.org; Mon, 23 Dec 2019 06:38:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ijM2N-0007yo-OG for qemu-devel@nongnu.org; Mon, 23 Dec 2019 06:38:12 -0500 Received: from relay.sw.ru ([185.231.240.75]:49100) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ijM2N-0007v2-Hc for qemu-devel@nongnu.org; Mon, 23 Dec 2019 06:38:11 -0500 Received: from dptest2.qa.sw.ru ([10.94.4.71]) by relay.sw.ru with esmtp (Exim 4.92.3) (envelope-from ) id 1ijM2H-0002Ur-Ip; Mon, 23 Dec 2019 14:38:05 +0300 From: Denis Plotnikov To: qemu-devel@nongnu.org Subject: [PATCH v1] virtio-pci: store virtqueue size directly to a device Date: Mon, 23 Dec 2019 14:37:58 +0300 Message-Id: <20191223113758.11951-1-dplotnikov@virtuozzo.com> X-Mailer: git-send-email 2.17.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 185.231.240.75 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: den@virtuozzo.com, rkagan@virtuozzo.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Currenly, the virtqueue size is saved to the proxy on pci writing and is read from the device pci reading. The virtqueue size is propagated later on form the proxy to the device on virqueue enabling stage. This could be a problem, if a guest, on the virtqueue configuration, sets the size and then re-read it immediatly before the queue enabling in order to check if the desiged size has been set. This happens in seabios: (sebios snippet) vp_find_vq() { ... /* check if the queue is available */ if (vp->use_modern) { num =3D vp_read(&vp->common, virtio_pci_common_cfg, queue_size); if (num > MAX_QUEUE_NUM) { vp_write(&vp->common, virtio_pci_common_cfg, queue_size, MAX_QUEUE_NUM); num =3D vp_read(&vp->common, virtio_pci_common_cfg, queue_size); } } else { num =3D vp_read(&vp->legacy, virtio_pci_legacy, queue_num); } if (!num) { dprintf(1, "ERROR: queue size is 0\n"); goto fail; } if (num > MAX_QUEUE_NUM) { dprintf(1, "ERROR: queue size %d > %d\n", num, MAX_QUEUE_NUM); goto fail; } ... } If the device queue num is greater then the max queue size supported by sea= bios, seabios tries to reduce the queue size, then re-read it again, I suppose to check if the setting actually happens, and then checks the virtqueue size a= gain, to deside whether it is satisfied with the vaule. In this case, if device's virtqueue size is 512 and seabios max supported q= ueue size is 256, seabios tries to set 256 but than read 512 again and can't pro= ceed with that vaule, preventing the guest from successful booting. The root case was investigated by Roman Kagan The patch fixes the problem, by propagating the queue size to the device ri= ght away, so the written value could be read on the next step, if the value was ok for the device. Suggested-by: Roman Kagan Suggested-by: Michael S. Tsirkin Signed-off-by: Denis Plotnikov --- hw/virtio/virtio-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index c6b47a9c73..e5c759e19e 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -1256,6 +1256,8 @@ static void virtio_pci_common_write(void *opaque, hwa= ddr addr, break; case VIRTIO_PCI_COMMON_Q_SIZE: proxy->vqs[vdev->queue_sel].num =3D val; + virtio_queue_set_num(vdev, vdev->queue_sel, + proxy->vqs[vdev->queue_sel].num); break; case VIRTIO_PCI_COMMON_Q_MSIX: msix_vector_unuse(&proxy->pci_dev, --=20 2.17.0