Message ID | 20240206145154.118044-1-sgarzare@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp1616291dyb; Tue, 6 Feb 2024 07:26:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IF5YLWX+yy7Q7R8XBV48AGClk2lT9WMTx+Fe3zoUM5G1XWg3zrc9h5xy/Rf+StOZ+7SAGO/ X-Received: by 2002:a05:6358:6e95:b0:178:6c79:6ccf with SMTP id q21-20020a0563586e9500b001786c796ccfmr3649053rwm.17.1707233182455; Tue, 06 Feb 2024 07:26:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707233182; cv=pass; d=google.com; s=arc-20160816; b=jIyOf+yWeSKuWrLrELcXfHFK+7RE2Et927xWGnLPe3JdpBQHK/XH0bzUqQFuQux/TL q7G9RdMtw8mNbpwBEdPqOLUgJGQRw7iAB3iAdQi2HfwE4ohDdw7jPuISkKyYA3+iv9de y6oueLa8HkWbMUq+0X9ihF4L5eie8vhK5RA73BVXqoFil+BlEbKODFvHMF4rrCPeD0t3 29b+94hkOaktsZS2lmluwdEUB2kBwIm3yNvQRjFwMGzixKl5iEMQOPmAXDy0MpizdY4d Dr12Z+MWOdIis5uCRyczMqUOcPFdJk5JE5C3q5Un5uWbLUYEj/NxvTKv84yv3i1E3Rxx +a9g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=dQIKoNOJmX8VRVk5/I0n1vx+OMQlaoxl3aigw5zkfn8=; fh=ba+NkZHia3Nzx5gpwIy4YFS02IZtVWGf19Rx6zCmmII=; b=bZmU+mTs8EPGrzMq/bNWY7cO90hyL/Fv8InvBvG5oseNN4gHhtQLdBm2Jtj5w094Os weGI24E8znvNJePvcgL8cbotxER4S+tNP+clG5eHEnYePzIzcMZ35g979/YOtzFIVJP8 kyKIofBXQYZl6/a3RNEeKrgDsgPdPeavtz+t69s3UhU3AdaioeD8dIwkz54+IDF9TOLP zINJLbOBi1DPPWtk1HFkOaFeB3HPPDJoStrubwTo6OtBO9JdIHrVt9GV9wfkE1g4bnkD K/epRGMQRAkyPYcrOBlSSCv/0cquyLkthpStqj1Aj5i3vuULjKxbKdlDbjJhBObUkv77 Fdxw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ErNxu78E; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Forwarded-Encrypted: i=1; AJvYcCVXdsdzl4/hT+YjD5wnD/joiBPu7Exv+0aFXN8MLxtJrHyBEB18YX2tY4AGSVVL01BrkrQsU/dKQhrlcNZmIJkkss2eXA== Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id c19-20020a6566d3000000b005d47eca0246si1804632pgw.378.2024.02.06.07.26.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 07:26:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ErNxu78E; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55144-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id B1CF0B2ACFC for <ouuuleilei@gmail.com>; Tue, 6 Feb 2024 14:52:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A83281332B7; Tue, 6 Feb 2024 14:52:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ErNxu78E" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 292C9132470 for <linux-kernel@vger.kernel.org>; Tue, 6 Feb 2024 14:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707231123; cv=none; b=JhO9WQL4hxBuFFYrTkK2Y5OFTBcCu9I2Qdw1jBVStbsPK0rqalCcvOS7ElSffxlo3bwgMLC3rrBYYnl3HTc+uVwnEvJZLSb9sJsUIzlNbNgXBZnZmCKS/ASjQOtZeMQX2jVrkazL+XMlU0vNNkEvvAYimlXpAVLbUwqOQNOSIYM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707231123; c=relaxed/simple; bh=R/o5EP7C+JnoxFgZaYwDA4ls6GyyKFxMVhJAZddFp0Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-type; b=aS2GzO+zuWBY1jM3f2/cz1PVH54pDda4btbEqp2E/yltdo/xn4Zlso8cvfqD9Rqgf5QSJYM5CJbDeXMMLbTafimNb9vjihTF06cjU7nD4BL+E6BQFjJydOWvWWyT9dK14W1TibDk7uLh1S8Y4Yvm40xCV/aiXMD15Y+QGUMam+Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ErNxu78E; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707231120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dQIKoNOJmX8VRVk5/I0n1vx+OMQlaoxl3aigw5zkfn8=; b=ErNxu78EpxHSqhM5CYw0jPtNlWw05ftYLVIjAlcCr4GZcQkdFgoF1fQceNOlq95Piwbx2O nMHAS3njwJLTy+Bm4IlXBilw/P9+sZmXVbPuCiS6ol/P7YHJ9+qhNwcM/pOpTxCcNHZwoQ wsNECiexjIPv1r7tQpW3mzB1yL6AQ+4= Received: from mail-oa1-f70.google.com (mail-oa1-f70.google.com [209.85.160.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-401-txHBQnjYOTupBFY5jqw8Fg-1; Tue, 06 Feb 2024 09:51:59 -0500 X-MC-Unique: txHBQnjYOTupBFY5jqw8Fg-1 Received: by mail-oa1-f70.google.com with SMTP id 586e51a60fabf-2195a9a8efaso3588867fac.2 for <linux-kernel@vger.kernel.org>; Tue, 06 Feb 2024 06:51:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707231119; x=1707835919; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dQIKoNOJmX8VRVk5/I0n1vx+OMQlaoxl3aigw5zkfn8=; b=f8KnH67cCA/IcOPQWi6GS52kmNQ0YqQIpfLcaV6MWMz4Ou3ka8itMMCIhleKFsNY4p uTKxQ0PCQGMbRQkCmhv4KL4nL7IkfbxgEvEcPazVwk/IqS61KnNNDq2hrS/XiBTjcUoZ 9zsb8BGVvbDXUwWn2yCD8wk3jXEJBnIf1fo3B0agWvqCbHYMzp2ZRIVNBYBnSiCUgtjp GM3ClMtaXRlr0CeHsUa1h1a+5fev2MuhlQIO+eM7u+t6G3Mlx4WQltTbNQaj5WaXQ660 XEx/2+xSru0aJ6FbnAXnn2IN1nSIT4pKH/xueuzdiK+4bBiRhZsFLacWYZnTNw2zVHjw UeAA== X-Gm-Message-State: AOJu0Yyjs6hUG49PC8nLRanRqAurt6VkI8kDriX/7vn9TqyevVk6FwYQ LFdnK8AY2GNNC2bWwkbNvfXyaUL49PNeeQoPzgS0GCMN7ckys+bkCUDQ4FDZd8TD2k5Ampgezyu shZJVRigdasXY+XNs6JzVeZfrUn/ZG4c9yedrJMM6cT6meNeTOtnM0jxQFupGeA== X-Received: by 2002:a05:6870:164d:b0:210:8802:786a with SMTP id c13-20020a056870164d00b002108802786amr3275741oae.53.1707231118960; Tue, 06 Feb 2024 06:51:58 -0800 (PST) X-Received: by 2002:a05:6870:164d:b0:210:8802:786a with SMTP id c13-20020a056870164d00b002108802786amr3275728oae.53.1707231118721; Tue, 06 Feb 2024 06:51:58 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCV6YVTF3BXfxD7oGuNc/5i4fJi9lzUP0v2EuV9vQ2uYj3WVgVJCvsEX8TROSCzAqDs5ebrmUOfU/S/j7kp3jXPim8rxZSbJKSJVXStktmV2oqMTXILCaFK8Q7/Dm4SdzEV1oi2ax7XvIFESMcCV8iCOJSstM1x0ffCK9wzkBPAe4UiZZyES5vihMsa0sRYoqZu0wDySrdl+bWTxhpQjZZsre7Rw5ZHednIiXPP1W399e2EE8jsT8XU9D+7TeQhQE87br0/am75tATSNqLHpbPwm+dZTE8klIcCGRw== Received: from step1.redhat.com (host-87-12-25-87.business.telecomitalia.it. [87.12.25.87]) by smtp.gmail.com with ESMTPSA id k19-20020ac84793000000b0042a9b28733fsm930742qtq.89.2024.02.06.06.51.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 06:51:58 -0800 (PST) From: Stefano Garzarella <sgarzare@redhat.com> To: virtualization@lists.linux.dev Cc: Shannon Nelson <shannon.nelson@amd.com>, =?utf-8?q?Eugenio_P=C3=A9rez?= <eperezma@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, kvm@vger.kernel.org, Kevin Wolf <kwolf@redhat.com>, Jason Wang <jasowang@redhat.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Stefano Garzarella <sgarzare@redhat.com> Subject: [PATCH] vhost-vdpa: fail enabling virtqueue in certain conditions Date: Tue, 6 Feb 2024 15:51:54 +0100 Message-ID: <20240206145154.118044-1-sgarzare@redhat.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790163741499476696 X-GMAIL-MSGID: 1790163741499476696 |
Series |
vhost-vdpa: fail enabling virtqueue in certain conditions
|
|
Commit Message
Stefano Garzarella
Feb. 6, 2024, 2:51 p.m. UTC
If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect
the driver to enable virtqueue before setting DRIVER_OK. If the driver
tries anyway, better to fail right away as soon as we get the ioctl.
Let's also update the documentation to make it clearer.
We had a problem in QEMU for not meeting this requirement, see
https://lore.kernel.org/qemu-devel/20240202132521.32714-1-kwolf@redhat.com/
Fixes: 9f09fd6171fe ("vdpa: accept VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK backend feature")
Cc: eperezma@redhat.com
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
include/uapi/linux/vhost_types.h | 3 ++-
drivers/vhost/vdpa.c | 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
Comments
better @subj: try late vq enable only if negotiated On Tue, Feb 06, 2024 at 03:51:54PM +0100, Stefano Garzarella wrote: > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail right away as soon as we get the ioctl. > Let's also update the documentation to make it clearer. > > We had a problem in QEMU for not meeting this requirement, see > https://lore.kernel.org/qemu-devel/20240202132521.32714-1-kwolf@redhat.com/ > > Fixes: 9f09fd6171fe ("vdpa: accept VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK backend feature") > Cc: eperezma@redhat.com > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> > --- > include/uapi/linux/vhost_types.h | 3 ++- > drivers/vhost/vdpa.c | 4 ++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h > index d7656908f730..5df49b6021a7 100644 > --- a/include/uapi/linux/vhost_types.h > +++ b/include/uapi/linux/vhost_types.h > @@ -182,7 +182,8 @@ struct vhost_vdpa_iova_range { > /* Device can be resumed */ > #define VHOST_BACKEND_F_RESUME 0x5 > /* Device supports the driver enabling virtqueues both before and after > - * DRIVER_OK > + * DRIVER_OK. If this feature is not negotiated, the virtqueues must be > + * enabled before setting DRIVER_OK. > */ > #define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 > /* Device may expose the virtqueue's descriptor area, driver area and > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index bc4a51e4638b..1fba305ba8c1 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -651,6 +651,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, > case VHOST_VDPA_SET_VRING_ENABLE: > if (copy_from_user(&s, argp, sizeof(s))) > return -EFAULT; > + if (!vhost_backend_has_feature(vq, > + VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK) && > + (ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > + return -EINVAL; > ops->set_vq_ready(vdpa, idx, s.num); > return 0; > case VHOST_VDPA_GET_VRING_GROUP: > -- > 2.43.0
On Tue, Feb 06, 2024 at 10:56:50AM -0500, Michael S. Tsirkin wrote:
>better @subj: try late vq enable only if negotiated
I rewrote it 3/4 times, and before sending it I was not happy with the
result.
Thank you, much better! I'll change it in v2.
Stefano
On Tue, Feb 6, 2024 at 3:52 PM Stefano Garzarella <sgarzare@redhat.com> wrote: > > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail right away as soon as we get the ioctl. > Let's also update the documentation to make it clearer. > > We had a problem in QEMU for not meeting this requirement, see > https://lore.kernel.org/qemu-devel/20240202132521.32714-1-kwolf@redhat.com/ > > Fixes: 9f09fd6171fe ("vdpa: accept VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK backend feature") > Cc: eperezma@redhat.com > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Thanks! > --- > include/uapi/linux/vhost_types.h | 3 ++- > drivers/vhost/vdpa.c | 4 ++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h > index d7656908f730..5df49b6021a7 100644 > --- a/include/uapi/linux/vhost_types.h > +++ b/include/uapi/linux/vhost_types.h > @@ -182,7 +182,8 @@ struct vhost_vdpa_iova_range { > /* Device can be resumed */ > #define VHOST_BACKEND_F_RESUME 0x5 > /* Device supports the driver enabling virtqueues both before and after > - * DRIVER_OK > + * DRIVER_OK. If this feature is not negotiated, the virtqueues must be > + * enabled before setting DRIVER_OK. > */ > #define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 > /* Device may expose the virtqueue's descriptor area, driver area and > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index bc4a51e4638b..1fba305ba8c1 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -651,6 +651,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, > case VHOST_VDPA_SET_VRING_ENABLE: > if (copy_from_user(&s, argp, sizeof(s))) > return -EFAULT; > + if (!vhost_backend_has_feature(vq, > + VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK) && > + (ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > + return -EINVAL; > ops->set_vq_ready(vdpa, idx, s.num); > return 0; > case VHOST_VDPA_GET_VRING_GROUP: > -- > 2.43.0 >
On Tue, Feb 6, 2024 at 10:52 PM Stefano Garzarella <sgarzare@redhatcom> wrote: > > If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect > the driver to enable virtqueue before setting DRIVER_OK. If the driver > tries anyway, better to fail right away as soon as we get the ioctl. > Let's also update the documentation to make it clearer. > > We had a problem in QEMU for not meeting this requirement, see > https://lore.kernel.org/qemu-devel/20240202132521.32714-1-kwolf@redhat.com/ Maybe it's better to only enable cvq when the backend supports VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK. Eugenio, any comment on this? > > Fixes: 9f09fd6171fe ("vdpa: accept VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK backend feature") > Cc: eperezma@redhat.com > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> > --- > include/uapi/linux/vhost_types.h | 3 ++- > drivers/vhost/vdpa.c | 4 ++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h > index d7656908f730..5df49b6021a7 100644 > --- a/include/uapi/linux/vhost_types.h > +++ b/include/uapi/linux/vhost_types.h > @@ -182,7 +182,8 @@ struct vhost_vdpa_iova_range { > /* Device can be resumed */ > #define VHOST_BACKEND_F_RESUME 0x5 > /* Device supports the driver enabling virtqueues both before and after > - * DRIVER_OK > + * DRIVER_OK. If this feature is not negotiated, the virtqueues must be > + * enabled before setting DRIVER_OK. > */ > #define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 > /* Device may expose the virtqueue's descriptor area, driver area and > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index bc4a51e4638b..1fba305ba8c1 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -651,6 +651,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, > case VHOST_VDPA_SET_VRING_ENABLE: > if (copy_from_user(&s, argp, sizeof(s))) > return -EFAULT; > + if (!vhost_backend_has_feature(vq, > + VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK) && > + (ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > + return -EINVAL; As discussed, without VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK, we don't know if parents can do vq_ready after driver_ok. So maybe we need to keep this behaviour to unbreak some "legacy" userspace? For example ifcvf did: static void ifcvf_vdpa_set_vq_ready(struct vdpa_device *vdpa_dev, u16 qid, bool ready) { struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev); ifcvf_set_vq_ready(vf, qid, ready); } And it did: void ifcvf_set_vq_ready(struct ifcvf_hw *hw, u16 qid, bool ready) { struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; vp_iowrite16(qid, &cfg->queue_select); vp_iowrite16(ready, &cfg->queue_enable); } Though it didn't advertise VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK? Adding LingShan for more thought. Thanks > ops->set_vq_ready(vdpa, idx, s.num); > return 0; > case VHOST_VDPA_GET_VRING_GROUP: > -- > 2.43.0 >
On Wed, Feb 07, 2024 at 11:27:14AM +0800, Jason Wang wrote: >On Tue, Feb 6, 2024 at 10:52 PM Stefano Garzarella <sgarzare@redhat.com> wrote: >> >> If VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not negotiated, we expect >> the driver to enable virtqueue before setting DRIVER_OK. If the driver >> tries anyway, better to fail right away as soon as we get the ioctl. >> Let's also update the documentation to make it clearer. >> >> We had a problem in QEMU for not meeting this requirement, see >> https://lore.kernel.org/qemu-devel/20240202132521.32714-1-kwolf@redhat.com/ > >Maybe it's better to only enable cvq when the backend supports >VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK. Eugenio, any comment on this? > >> >> Fixes: 9f09fd6171fe ("vdpa: accept VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK backend feature") >> Cc: eperezma@redhat.com >> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> >> --- >> include/uapi/linux/vhost_types.h | 3 ++- >> drivers/vhost/vdpa.c | 4 ++++ >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h >> index d7656908f730..5df49b6021a7 100644 >> --- a/include/uapi/linux/vhost_types.h >> +++ b/include/uapi/linux/vhost_types.h >> @@ -182,7 +182,8 @@ struct vhost_vdpa_iova_range { >> /* Device can be resumed */ >> #define VHOST_BACKEND_F_RESUME 0x5 >> /* Device supports the driver enabling virtqueues both before and after >> - * DRIVER_OK >> + * DRIVER_OK. If this feature is not negotiated, the virtqueues must be >> + * enabled before setting DRIVER_OK. >> */ >> #define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 >> /* Device may expose the virtqueue's descriptor area, driver area and >> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c >> index bc4a51e4638b..1fba305ba8c1 100644 >> --- a/drivers/vhost/vdpa.c >> +++ b/drivers/vhost/vdpa.c >> @@ -651,6 +651,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, >> case VHOST_VDPA_SET_VRING_ENABLE: >> if (copy_from_user(&s, argp, sizeof(s))) >> return -EFAULT; >> + if (!vhost_backend_has_feature(vq, >> + VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK) && >> + (ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >> + return -EINVAL; > >As discussed, without VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK, we don't >know if parents can do vq_ready after driver_ok. > >So maybe we need to keep this behaviour to unbreak some "legacy" userspace? I'm not sure it's a good idea, since "legacy" userspace are currently broken if used with VDUSE device. So we need to fix userspace in any case, and IMHO is better if we start to return an error, so the user understands what went wrong, because the problem in QEMU took us quite some time to figure out that we couldn't enable vq after DRIVER_OK. Since userspace is unable to understand if a vhost-vdpa device is VDUSE or not, I think we have only 2 options either merge this patch or fix VDUSE somehow. But the last one I think is more complicated/intrusive. Thanks, Stefano > >For example ifcvf did: > >static void ifcvf_vdpa_set_vq_ready(struct vdpa_device *vdpa_dev, > u16 qid, bool ready) >{ > struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev); > > ifcvf_set_vq_ready(vf, qid, ready); >} > >And it did: > >void ifcvf_set_vq_ready(struct ifcvf_hw *hw, u16 qid, bool ready) >{ > struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; > > vp_iowrite16(qid, &cfg->queue_select); > vp_iowrite16(ready, &cfg->queue_enable); >} > >Though it didn't advertise VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK? > >Adding LingShan for more thought. > >Thanks > >> ops->set_vq_ready(vdpa, idx, s.num); >> return 0; >> case VHOST_VDPA_GET_VRING_GROUP: >> -- >> 2.43.0 >> >
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h index d7656908f730..5df49b6021a7 100644 --- a/include/uapi/linux/vhost_types.h +++ b/include/uapi/linux/vhost_types.h @@ -182,7 +182,8 @@ struct vhost_vdpa_iova_range { /* Device can be resumed */ #define VHOST_BACKEND_F_RESUME 0x5 /* Device supports the driver enabling virtqueues both before and after - * DRIVER_OK + * DRIVER_OK. If this feature is not negotiated, the virtqueues must be + * enabled before setting DRIVER_OK. */ #define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 /* Device may expose the virtqueue's descriptor area, driver area and diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index bc4a51e4638b..1fba305ba8c1 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -651,6 +651,10 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd, case VHOST_VDPA_SET_VRING_ENABLE: if (copy_from_user(&s, argp, sizeof(s))) return -EFAULT; + if (!vhost_backend_has_feature(vq, + VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK) && + (ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) + return -EINVAL; ops->set_vq_ready(vdpa, idx, s.num); return 0; case VHOST_VDPA_GET_VRING_GROUP: