Message ID | 1705519403-255169-1-git-send-email-steven.sistare@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:30f:b0:101:a8e8:374 with SMTP id ia15csp130959dyb; Wed, 17 Jan 2024 11:23:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IGNOS4kCwJbmHPnpqTgxdFBWLKQ1EQHXCXu/KhbDCIrSyzSbdv0bx9rEImG2HJ/eT+lyVmH X-Received: by 2002:a05:620a:200b:b0:783:34d4:715a with SMTP id c11-20020a05620a200b00b0078334d4715amr8362555qka.31.1705519429640; Wed, 17 Jan 2024 11:23:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705519429; cv=pass; d=google.com; s=arc-20160816; b=oOA3hiZle5wxDifq3z8aVKPYeE1eMpLbgWco/ReLhTM+vhdkh3v1vhmuk5FJ7ld5dO wpTg8Vc8/p14/UoK5Ep4wkDiMm3zDvaO3bfirKcX5CN8FY5DQUkgWaROZ6I89z3m5CY+ HwAGiJ38I8DI8YO5LaQWne78rrUHqUhaafOVkWoEq6dDjYwI3JYrNiFoe8f+QJj88Q79 ggA5dBIChhf8UTOvtUjwpwdJVz2q1UvmMJFmetNhvt8caRwse7+szObxWqVEAN0AsLop qf0VLTq9qLXVeR/LqMbM+fpyh6ImAJ77sdEYS52SkR1jEnMX0qUn3NZjS74M59WOoHx6 FDkA== 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=1F1h/D8LY/Y+1NEma8ji2AuKUSI4RrgJpl+4EbcQmBw=; fh=km4Bc+ziWb/3oA8756vl35/i7455HKKFSM4D8VUGOYQ=; b=vL+qt1TERfdBwlpq6mDkXRkIJBcCJr3anKQnE5RR0lCdV+52LRG88tL+eRgbqZ+KrH kvMZfIqcO+zIVBi3jdYuPkdeQNpGEnxDkFPnmx+KsTnpKQ6Xupr6tcoCVNwWAegHv+mY 52gL7P3MQRvKCODGCrjtU/tcUYAg1KRxZ31cxH+pp9ez7E1GOnB7olZ+BuofnZLMSXR4 f+XN9GINIsWidwCB0879iKxK4gfqQwB6bEqSjeTSwxOGf6jLCIbwnubMcNTLJtLW0+Pg aTc2LHCSHrzPm/6FsdF6FHWsuoRBjtDGLRIUVfshH3gn2aK7L7DpIZ2HR3jZVi0BVE30 8XXA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=MTp+AzDc; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id op53-20020a05620a537500b0078366e7d32esi4149465qkn.269.2024.01.17.11.23.49 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 11:23:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=MTp+AzDc; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-29361-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 6DDD01C21C21 for <ouuuleilei@gmail.com>; Wed, 17 Jan 2024 19:23:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A183A24A08; Wed, 17 Jan 2024 19:23:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="MTp+AzDc" Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (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 33988249E0 for <linux-kernel@vger.kernel.org>; Wed, 17 Jan 2024 19:23:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705519417; cv=none; b=OZyzhav1L6nA757ub2us5CFQbLSpkXcn0BVokprKHrE+0yp7+5Rt/Tm7F40WHUu2AZJa2sfsnpFCpg8L9QnrY9DOC9aULO6/+Hb0tqtBaezyp/t6jO5hZ5oZo31pnkhrRaSH+q00M+8T2IcDWorpVQKSVk1LFSrWPzd0muIvjMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705519417; c=relaxed/simple; bh=0fv+js9Ew/OTGfUYa+DH+CiU24lWx9f36G6rrkUfZ3Y=; h=Received:DKIM-Signature:Received:Received:Received:Received: Received:From:To:Cc:Subject:Date:Message-Id:X-Mailer:MIME-Version: Content-Type:Content-Transfer-Encoding:X-Proofpoint-Virus-Version: X-Proofpoint-Spam-Details:X-Proofpoint-GUID: X-Proofpoint-ORIG-GUID; b=Kwqehen5eDSG8wScZMkGPmxs0vH3v7wEJTd62gvIkXQVITD9EkqwF4hUgY+VZiSgtQUgsSC8mlN54nGdPhn3kGhdbGYpK88akRr8Ch1EcGSjEk0Z1E6QODXoIykMbfkHZGREckIUvO4me+Ds/v8Ry91YW7XU6sHjhNlhNgxKHOk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=MTp+AzDc; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40HFxD5c029237; Wed, 17 Jan 2024 19:23:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : mime-version : content-type : content-transfer-encoding; s=corp-2023-11-20; bh=1F1h/D8LY/Y+1NEma8ji2AuKUSI4RrgJpl+4EbcQmBw=; b=MTp+AzDcOvpBseUjiPQLpAM3Y0Lk3pa7KbOQbFBlajVh/L4hOW3O7lq7tH8m/zBdP3l6 HK11YX8rFt0HzJob5wCtDYEq0LdP+5Ei/tiXvgwMkTdQ3kn0hQkRfNJKgFdzX1LBd444 KJBUXGfPccv6AVJ0FlgPdPS9L2EK+SABDo9UZ1boe0Sxyd2zFO+Jfwa37ew6VTFmwZd5 nq8YYi9XrwgDFYlBaGmeVQijLR2Leu+Jr40Ee9GWAKZoPMS06f4Yvov7+pWdTO5ZOtCO oe31viNVnAeu/o2GEszuQWSVj+5Mh82OTZi09okViyykp+iXReF9YzvGRbX81kBPBm6m zw== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vkha3gtfc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jan 2024 19:23:31 +0000 Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 40HIPjZW020404; Wed, 17 Jan 2024 19:23:30 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3vkgyaxk7p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jan 2024 19:23:29 +0000 Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 40HJNPUk009185; Wed, 17 Jan 2024 19:23:27 GMT Received: from ca-dev63.us.oracle.com (ca-dev63.us.oracle.com [10.211.8.221]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 3vkgyaxk4u-1; Wed, 17 Jan 2024 19:23:27 +0000 From: Steve Sistare <steven.sistare@oracle.com> To: virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org Cc: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Eugenio Perez Martin <eperezma@redhat.com>, Si-Wei Liu <si-wei.liu@oracle.com>, Stefano Garzarella <sgarzare@redhat.com>, Steve Sistare <steven.sistare@oracle.com> Subject: [PATCH V1] vdpa_sim: reset must not run Date: Wed, 17 Jan 2024 11:23:23 -0800 Message-Id: <1705519403-255169-1-git-send-email-steven.sistare@oracle.com> X-Mailer: git-send-email 1.8.3.1 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; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-17_12,2024-01-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401170141 X-Proofpoint-GUID: IotjSuzEKsbpCZn2C3_nMGOXBDpen5g5 X-Proofpoint-ORIG-GUID: IotjSuzEKsbpCZn2C3_nMGOXBDpen5g5 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788366741052046268 X-GMAIL-MSGID: 1788366741052046268 |
Series |
[V1] vdpa_sim: reset must not run
|
|
Commit Message
Steven Sistare
Jan. 17, 2024, 7:23 p.m. UTC
vdpasim_do_reset sets running to true, which is wrong, as it allows vdpasim_kick_vq to post work requests before the device has been configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK is set. Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Thu, Jan 18, 2024 at 3:23 AM Steve Sistare <steven.sistare@oracle.com> wrote: > > vdpasim_do_reset sets running to true, which is wrong, as it allows > vdpasim_kick_vq to post work requests before the device has been > configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK > is set. > > Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") > Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Thanks
On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote: >vdpasim_do_reset sets running to true, which is wrong, as it allows >vdpasim_kick_vq to post work requests before the device has been >configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK >is set. > >Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") >Signed-off-by: Steve Sistare <steven.sistare@oracle.com> >Reviewed-by: Eugenio Pérez <eperezma@redhat.com> >--- > drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >index be2925d0d283..6304cb0b4770 100644 >--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >@@ -160,7 +160,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags) > } > } > >- vdpasim->running = true; >+ vdpasim->running = false; > spin_unlock(&vdpasim->iommu_lock); > > vdpasim->features = 0; >@@ -483,6 +483,7 @@ static void vdpasim_set_status(struct vdpa_device *vdpa, u8 status) > > mutex_lock(&vdpasim->mutex); > vdpasim->status = status; >+ vdpasim->running = (status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; > mutex_unlock(&vdpasim->mutex); Should we do something similar also in vdpasim_resume() ? I mean something like this: diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c index be2925d0d283..55e4633d5442 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c @@ -520,7 +520,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa) int i; mutex_lock(&vdpasim->mutex); - vdpasim->running = true; + vdpasim->running = (vdpasim->status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; if (vdpasim->pending_kick) { /* Process pending descriptors */ Thanks, Stefano
On Mon, Jan 22, 2024 at 11:22 AM Stefano Garzarella <sgarzare@redhat.com> wrote: > > On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote: > >vdpasim_do_reset sets running to true, which is wrong, as it allows > >vdpasim_kick_vq to post work requests before the device has been > >configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK > >is set. > > > >Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") > >Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > >Reviewed-by: Eugenio Pérez <eperezma@redhat.com> > >--- > > drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c > >index be2925d0d283..6304cb0b4770 100644 > >--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c > >+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c > >@@ -160,7 +160,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags) > > } > > } > > > >- vdpasim->running = true; > >+ vdpasim->running = false; > > spin_unlock(&vdpasim->iommu_lock); > > > > vdpasim->features = 0; > >@@ -483,6 +483,7 @@ static void vdpasim_set_status(struct vdpa_device *vdpa, u8 status) > > > > mutex_lock(&vdpasim->mutex); > > vdpasim->status = status; > >+ vdpasim->running = (status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; > > mutex_unlock(&vdpasim->mutex); > > Should we do something similar also in vdpasim_resume() ? > > I mean something like this: > > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c > index be2925d0d283..55e4633d5442 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c > @@ -520,7 +520,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa) > int i; > > mutex_lock(&vdpasim->mutex); > - vdpasim->running = true; > + vdpasim->running = (vdpasim->status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; > > if (vdpasim->pending_kick) { > /* Process pending descriptors */ > > Thanks, > Stefano > The suspend and resume operation should not be called before DRIVER_OK, so maybe we should add that protection at drivers/vhost/vdpa.c actually? Thanks!
On Mon, Jan 22, 2024 at 11:47:22AM +0100, Eugenio Perez Martin wrote: >On Mon, Jan 22, 2024 at 11:22 AM Stefano Garzarella <sgarzare@redhat.com> wrote: >> >> On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote: >> >vdpasim_do_reset sets running to true, which is wrong, as it allows >> >vdpasim_kick_vq to post work requests before the device has been >> >configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK >> >is set. >> > >> >Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") >> >Signed-off-by: Steve Sistare <steven.sistare@oracle.com> >> >Reviewed-by: Eugenio Pérez <eperezma@redhat.com> >> >--- >> > drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> >diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> >index be2925d0d283..6304cb0b4770 100644 >> >--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >> >+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> >@@ -160,7 +160,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags) >> > } >> > } >> > >> >- vdpasim->running = true; >> >+ vdpasim->running = false; >> > spin_unlock(&vdpasim->iommu_lock); >> > >> > vdpasim->features = 0; >> >@@ -483,6 +483,7 @@ static void vdpasim_set_status(struct vdpa_device *vdpa, u8 status) >> > >> > mutex_lock(&vdpasim->mutex); >> > vdpasim->status = status; >> >+ vdpasim->running = (status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; >> > mutex_unlock(&vdpasim->mutex); >> >> Should we do something similar also in vdpasim_resume() ? >> >> I mean something like this: >> >> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> index be2925d0d283..55e4633d5442 100644 >> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >> @@ -520,7 +520,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa) >> int i; >> >> mutex_lock(&vdpasim->mutex); >> - vdpasim->running = true; >> + vdpasim->running = (vdpasim->status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; >> >> if (vdpasim->pending_kick) { >> /* Process pending descriptors */ >> >> Thanks, >> Stefano >> > >The suspend and resume operation should not be called before >DRIVER_OK, so maybe we should add that protection at >drivers/vhost/vdpa.c actually? Yeah, I think so! Anyway, IMHO we should at least return an error in vdpa_sim if vdpasim_suspend/resume are called before DRIVER_OK (in another patch of course). Stefano
On 1/22/2024 5:59 AM, Stefano Garzarella wrote: > On Mon, Jan 22, 2024 at 11:47:22AM +0100, Eugenio Perez Martin wrote: >> On Mon, Jan 22, 2024 at 11:22 AM Stefano Garzarella <sgarzare@redhat.com> wrote: >>> >>> On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote: >>> >vdpasim_do_reset sets running to true, which is wrong, as it allows >>> >vdpasim_kick_vq to post work requests before the device has been >>> >configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK >>> >is set. >>> > >>> >Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op") >>> >Signed-off-by: Steve Sistare <steven.sistare@oracle.com> >>> >Reviewed-by: Eugenio Pérez <eperezma@redhat.com> >>> >--- >>> > drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++- >>> > 1 file changed, 2 insertions(+), 1 deletion(-) >>> > >>> >diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> >index be2925d0d283..6304cb0b4770 100644 >>> >--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> >+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> >@@ -160,7 +160,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags) >>> > } >>> > } >>> > >>> >- vdpasim->running = true; >>> >+ vdpasim->running = false; >>> > spin_unlock(&vdpasim->iommu_lock); >>> > >>> > vdpasim->features = 0; >>> >@@ -483,6 +483,7 @@ static void vdpasim_set_status(struct vdpa_device *vdpa, u8 status) >>> > >>> > mutex_lock(&vdpasim->mutex); >>> > vdpasim->status = status; >>> >+ vdpasim->running = (status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; >>> > mutex_unlock(&vdpasim->mutex); >>> >>> Should we do something similar also in vdpasim_resume() ? >>> >>> I mean something like this: >>> >>> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> index be2925d0d283..55e4633d5442 100644 >>> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>> @@ -520,7 +520,7 @@ static int vdpasim_resume(struct vdpa_device *vdpa) >>> int i; >>> >>> mutex_lock(&vdpasim->mutex); >>> - vdpasim->running = true; >>> + vdpasim->running = (vdpasim->status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; >>> >>> if (vdpasim->pending_kick) { >>> /* Process pending descriptors */ >>> >>> Thanks, >>> Stefano >>> >> >> The suspend and resume operation should not be called before >> DRIVER_OK, so maybe we should add that protection at >> drivers/vhost/vdpa.c actually? > > Yeah, I think so! > > Anyway, IMHO we should at least return an error in vdpa_sim if vdpasim_suspend/resume are called before DRIVER_OK (in another patch of course). I submitted "vdpa: suspend and resume require DRIVER_OK" to check this in vdpa.c so there is no need to check it in the leaf drivers. I also submitted V2 of this patch, "vdpa_sim: reset must not run". It checks for DRIVER_OK, instead of FEATURES_OK. - Steve
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c index be2925d0d283..6304cb0b4770 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c @@ -160,7 +160,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags) } } - vdpasim->running = true; + vdpasim->running = false; spin_unlock(&vdpasim->iommu_lock); vdpasim->features = 0; @@ -483,6 +483,7 @@ static void vdpasim_set_status(struct vdpa_device *vdpa, u8 status) mutex_lock(&vdpasim->mutex); vdpasim->status = status; + vdpasim->running = (status & VIRTIO_CONFIG_S_FEATURES_OK) != 0; mutex_unlock(&vdpasim->mutex); }