Message ID | 1707517799-137286-1-git-send-email-steven.sistare@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-60110-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp1167895dyd; Fri, 9 Feb 2024 14:32:26 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXFVDoRcC5E26/6RSI5BqBYegV1gFYGRhgElTYdQ/aED3aBnckrR2wLbYAengbyGehiyCS1qTWZ30nx5Kafy+ddgIx+MA== X-Google-Smtp-Source: AGHT+IFcvLFAJZsU97+asO8KNI8ey3uFZX3s5yptQ7UBlBM/0H5pc6fhTvyKo7q9QFlu8CfZhX8y X-Received: by 2002:a50:ec96:0:b0:561:aa3:f9e7 with SMTP id e22-20020a50ec96000000b005610aa3f9e7mr201782edr.6.1707517946307; Fri, 09 Feb 2024 14:32:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707517946; cv=pass; d=google.com; s=arc-20160816; b=RyyTyhPgz/nqKhM00LouNK8AzgqubsOpiaYw8KbylkU2BO36lwMP90/gWvmCk+zFTd zat8CEDn46jcvZcY1L0Ae3/yJOJSjZSQGQVGiEVzYX93VJjAmWzr7ue8lrKyjnhJYOjs lQKnExAt8DS5hZsNp7ABNmCk9jyhscWkZL1LjyvlMFLDQMkPA3IDUld5cn4jjX2rKC9p F+iKDdhm6vxAWlzc0Y883uCeUYK4meFOHpAl5oKo95oa+dBvjlko2mPzuKub9nLrqIOc cikVyYeikliFDLv59on9eEivLW7hup3RuVBkr+aMvJJWc4w3xCbpkX2eP9SRSuh1dfOp WzMw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-id:precedence:message-id:date :subject:cc:to:from:dkim-signature; bh=s0m3RONhBuuYD1488q0tsj2Vaijgp+sUXmdY6l8Ots8=; fh=QBEGF6N76uBMs+BQtsQnCp47nT3IyK9XHaWy3l4/H6E=; b=ppPSyoATkXV0KQkrRn4lrgMKWWZyhP/E05unXZASaRJmxtKj863dUquOjh1FG5yQFW e7HPvRuppRWhJJZ9oBzcXFu3tO4xBISrhsonEke37hG7pnCzA1uNJ43r32sRjpis55N/ z61HCiwK5VDQz/Pe0MdUahqB08E6zj5vU7uF4shnAqTvvmfUTK0kSQ6tN4gR3QJtszmm ivRZdB1MgnbUM3J10knGVKQg3VNpqsYpQb8e8Xhz7cmIcNt6dioPTqSknWNy4LQcphWz Dp3tNuDn9AmgQQYNqRKXt2hZyZLJ8w27rlZ4MsWWaewZy8ZaZovFjnXwzk7QwfJ8dPVX pfTg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=OE55qmYS; 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-60110-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-60110-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com X-Forwarded-Encrypted: i=2; AJvYcCW5MlqXpIm879GeIFIYzDtzZ0LLZyjd/T96ic2k559AbQeANQbHSj0uMfEVeA/NgUv09zRqABGMLj7XTvFxjZ/nfwAfBQ== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id o28-20020a509b1c000000b00561607e800csi144279edi.262.2024.02.09.14.32.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 14:32:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-60110-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=OE55qmYS; 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-60110-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-60110-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 am.mirrors.kernel.org (Postfix) with ESMTPS id 4A7321F21C0E for <ouuuleilei@gmail.com>; Fri, 9 Feb 2024 22:32:21 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 70B5038FA5; Fri, 9 Feb 2024 22:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="OE55qmYS" 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 D51AA374C6 for <linux-kernel@vger.kernel.org>; Fri, 9 Feb 2024 22:30:06 +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=1707517809; cv=none; b=uaszx7p08UzNOx8FxwqO15sXVA/L9y/MXzPdDBmoHQrPD2a6d7QsKLVeLmyOg6czFqTZn3zOHWX57iOksmj9muio5mc5hwtFv1X3XAB+BTbsjkhqMSSEG/bio7TA6tQKXeh5Mazo9pHoN70QDEs44mfUUitLIIoyqdH93u2HPsE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707517809; c=relaxed/simple; bh=ooUz90FvJ7Ve9JtszMBy/Igkiq4pVXCMiFPkjlO56gY=; h=From:To:Cc:Subject:Date:Message-Id; b=AZ13i4JFo+1uEaAkX7KmU82YvqY1sEgbFKaifqLnybR6hI+ATXclryntjNUrchoAJKE4auab2QND+ipvxovMo6V4ScD2s6MGNrNg/7SEWPaJwAE4GAsz8gjBZXcpkesN8PtS86bl16wwdoyzy0TMmMAk4JfYpy9euKC0uPjoOJE= 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=OE55qmYS; 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 (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 419MTKZd010579; Fri, 9 Feb 2024 22:30:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2023-11-20; bh=s0m3RONhBuuYD1488q0tsj2Vaijgp+sUXmdY6l8Ots8=; b=OE55qmYSiGTrZaoWFoc7rlvMso6YEb3gF8ktcFDFCVqVrGluR0srYN5rSMoP+Koan5AD CQsWAC2SzQQhiROSFTpEHS++rNx5gVPX5f5WGfiw7xMusud3gUj33StwxFeAOCBFBMQb BPaO0kBS4TjmpPQhPN/djU/qDneBHhATVh14T8UO4AW0TUa0jYqg3MiYjLL7nQ+tUT0a uTRxyXm73/u/JvBSIW9Kj3cEbTHUluMJhtw/RZATp+lfFLIW7SvpmSoF5I8qz/xgFsAM lKzJ8ZCSPYr7o/mzuHqeJ6MpF31mUxeymsb+g6OXM/CdgDiBtxAjCfxrXveax8sGwXQb qQ== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3w5vvtr01p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 09 Feb 2024 22:30:02 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 419L4QXO019970; Fri, 9 Feb 2024 22:30:01 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3w1bxk3485-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 09 Feb 2024 22:30:01 +0000 Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 419MU0us010656; Fri, 9 Feb 2024 22:30:00 GMT Received: from ca-dev63.us.oracle.com (ca-dev63.us.oracle.com [10.211.8.221]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 3w1bxk347k-1; Fri, 09 Feb 2024 22:30:00 +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>, Si-Wei Liu <si-wei.liu@oracle.com>, Eugenio Perez Martin <eperezma@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, Steve Sistare <steven.sistare@oracle.com> Subject: [PATCH V1] vdpa: suspend and resume require DRIVER_OK Date: Fri, 9 Feb 2024 14:29:59 -0800 Message-Id: <1707517799-137286-1-git-send-email-steven.sistare@oracle.com> X-Mailer: git-send-email 1.8.3.1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-09_18,2024-02-08_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402090165 X-Proofpoint-GUID: UF_PWOtqDGzOFjyBCkXV-8xHPbfQRzOT X-Proofpoint-ORIG-GUID: UF_PWOtqDGzOFjyBCkXV-8xHPbfQRzOT 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> X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790462337685179171 X-GMAIL-MSGID: 1790462337685179171 |
Series |
[V1] vdpa: suspend and resume require DRIVER_OK
|
|
Commit Message
Steven Sistare
Feb. 9, 2024, 10:29 p.m. UTC
Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all
vdpa devices.
Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>"
Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
---
drivers/vhost/vdpa.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: > Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all > vdpa devices. > > Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" > Signed-off-by: Steve Sistare <steven.sistare@oracle.com> I don't think failing suspend or resume makes sense though - e.g. practically failing suspend will just prevent sleeping I think - why should guest not having driver loaded prevent system suspend? there's also state such as features set which does need to be preserved. I think the thing to do is to skip invoking suspend/resume callback, and in fact checking suspend/resume altogether. > --- > drivers/vhost/vdpa.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index bc4a51e4638b..ce1882acfc3b 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) > if (!ops->suspend) > return -EOPNOTSUPP; > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > + return -EINVAL; > + > ret = ops->suspend(vdpa); > if (!ret) > v->suspended = true; > @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) > if (!ops->resume) > return -EOPNOTSUPP; > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > + return -EINVAL; > + > ret = ops->resume(vdpa); > if (!ret) > v->suspended = false; > -- > 2.39.3
On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote: > On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: >> Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all >> vdpa devices. >> >> Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" >> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > > I don't think failing suspend or resume makes sense though - > e.g. practically failing suspend will just prevent sleeping I think - > why should guest not having driver loaded prevent system suspend? Got it, my fix is too heavy handed. > there's also state such as features set which does need to be > preserved. > > I think the thing to do is to skip invoking suspend/resume callback OK. > and in > fact checking suspend/resume altogether. Currently ops->suspend, vhost_vdpa_can_suspend(), and VHOST_BACKEND_F_SUSPEND are equivalent. Hence if !ops->suspend, then then the driver does not support it, and indeed may break if suspend is used, so system suspend must be blocked, AFAICT. Yielding: vhost_vdpa_suspend() if (!ops->suspend) return -EOPNOTSUPP; if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) return 0; - Steve >> --- >> drivers/vhost/vdpa.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c >> index bc4a51e4638b..ce1882acfc3b 100644 >> --- a/drivers/vhost/vdpa.c >> +++ b/drivers/vhost/vdpa.c >> @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) >> if (!ops->suspend) >> return -EOPNOTSUPP; >> >> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >> + return -EINVAL; >> + >> ret = ops->suspend(vdpa); >> if (!ret) >> v->suspended = true; >> @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) >> if (!ops->resume) >> return -EOPNOTSUPP; >> >> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >> + return -EINVAL; >> + >> ret = ops->resume(vdpa); >> if (!ret) >> v->suspended = false; >> -- >> 2.39.3 >
On Mon, Feb 12, 2024 at 09:56:31AM -0500, Steven Sistare wrote: > On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote: > > On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: > >> Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all > >> vdpa devices. > >> > >> Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" > >> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > > > > I don't think failing suspend or resume makes sense though - > > e.g. practically failing suspend will just prevent sleeping I think - > > why should guest not having driver loaded prevent system suspend? > > Got it, my fix is too heavy handed. > > > there's also state such as features set which does need to be > > preserved. > > > > I think the thing to do is to skip invoking suspend/resume callback > > OK. > > > and in > > fact checking suspend/resume altogether. > > Currently ops->suspend, vhost_vdpa_can_suspend(), and VHOST_BACKEND_F_SUSPEND > are equivalent. Hence if !ops->suspend, then then the driver does not support > it, and indeed may break if suspend is used, so system suspend must be blocked, > AFAICT. Yielding: If DRIVER_OK is not set then there's nothing to be done for migration. So callback not needed. > vhost_vdpa_suspend() > if (!ops->suspend) > return -EOPNOTSUPP; > > if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > return 0; > > - Steve > > >> --- > >> drivers/vhost/vdpa.c | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > >> index bc4a51e4638b..ce1882acfc3b 100644 > >> --- a/drivers/vhost/vdpa.c > >> +++ b/drivers/vhost/vdpa.c > >> @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) > >> if (!ops->suspend) > >> return -EOPNOTSUPP; > >> > >> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > >> + return -EINVAL; > >> + > >> ret = ops->suspend(vdpa); > >> if (!ret) > >> v->suspended = true; > >> @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) > >> if (!ops->resume) > >> return -EOPNOTSUPP; > >> > >> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > >> + return -EINVAL; > >> + > >> ret = ops->resume(vdpa); > >> if (!ret) > >> v->suspended = false; > >> -- > >> 2.39.3 > >
On 2/12/2024 10:56 AM, Michael S. Tsirkin wrote: > On Mon, Feb 12, 2024 at 09:56:31AM -0500, Steven Sistare wrote: >> On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote: >>> On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: >>>> Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all >>>> vdpa devices. >>>> >>>> Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" >>>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> >>> >>> I don't think failing suspend or resume makes sense though - >>> e.g. practically failing suspend will just prevent sleeping I think - >>> why should guest not having driver loaded prevent system suspend? >> >> Got it, my fix is too heavy handed. >> >>> there's also state such as features set which does need to be >>> preserved. >>> >>> I think the thing to do is to skip invoking suspend/resume callback >> >> OK. >> >>> and in >>> fact checking suspend/resume altogether. >> >> Currently ops->suspend, vhost_vdpa_can_suspend(), and VHOST_BACKEND_F_SUSPEND >> are equivalent. Hence if !ops->suspend, then then the driver does not support >> it, and indeed may break if suspend is used, so system suspend must be blocked, >> AFAICT. Yielding: > > If DRIVER_OK is not set then there's nothing to be done for migration. > So callback not needed. OK, I missed your point. Next attempt: vhost_vdpa_suspend() if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) return 0; if (!ops->suspend) return -EOPNOTSUPP; - Steve >> vhost_vdpa_suspend() >> if (!ops->suspend) >> return -EOPNOTSUPP; >> >> if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >> return 0; >> >> - Steve >> >>>> --- >>>> drivers/vhost/vdpa.c | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c >>>> index bc4a51e4638b..ce1882acfc3b 100644 >>>> --- a/drivers/vhost/vdpa.c >>>> +++ b/drivers/vhost/vdpa.c >>>> @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) >>>> if (!ops->suspend) >>>> return -EOPNOTSUPP; >>>> >>>> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >>>> + return -EINVAL; >>>> + >>>> ret = ops->suspend(vdpa); >>>> if (!ret) >>>> v->suspended = true; >>>> @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) >>>> if (!ops->resume) >>>> return -EOPNOTSUPP; >>>> >>>> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) >>>> + return -EINVAL; >>>> + >>>> ret = ops->resume(vdpa); >>>> if (!ret) >>>> v->suspended = false; >>>> -- >>>> 2.39.3 >>> >
On Mon, Feb 12, 2024 at 11:37:12AM -0500, Steven Sistare wrote: > On 2/12/2024 10:56 AM, Michael S. Tsirkin wrote: > > On Mon, Feb 12, 2024 at 09:56:31AM -0500, Steven Sistare wrote: > >> On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote: > >>> On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: > >>>> Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all > >>>> vdpa devices. > >>>> > >>>> Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" > >>>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > >>> > >>> I don't think failing suspend or resume makes sense though - > >>> e.g. practically failing suspend will just prevent sleeping I think - > >>> why should guest not having driver loaded prevent system suspend? > >> > >> Got it, my fix is too heavy handed. > >> > >>> there's also state such as features set which does need to be > >>> preserved. > >>> > >>> I think the thing to do is to skip invoking suspend/resume callback > >> > >> OK. > >> > >>> and in > >>> fact checking suspend/resume altogether. > >> > >> Currently ops->suspend, vhost_vdpa_can_suspend(), and VHOST_BACKEND_F_SUSPEND > >> are equivalent. Hence if !ops->suspend, then then the driver does not support > >> it, and indeed may break if suspend is used, so system suspend must be blocked, > >> AFAICT. Yielding: > > > > If DRIVER_OK is not set then there's nothing to be done for migration. > > So callback not needed. > > OK, I missed your point. Next attempt: > > vhost_vdpa_suspend() > if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > return 0; > > if (!ops->suspend) > return -EOPNOTSUPP; right > - Steve > >> vhost_vdpa_suspend() > >> if (!ops->suspend) > >> return -EOPNOTSUPP; > >> > >> if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > >> return 0; > >> > >> - Steve > >> > >>>> --- > >>>> drivers/vhost/vdpa.c | 6 ++++++ > >>>> 1 file changed, 6 insertions(+) > >>>> > >>>> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > >>>> index bc4a51e4638b..ce1882acfc3b 100644 > >>>> --- a/drivers/vhost/vdpa.c > >>>> +++ b/drivers/vhost/vdpa.c > >>>> @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) > >>>> if (!ops->suspend) > >>>> return -EOPNOTSUPP; > >>>> > >>>> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > >>>> + return -EINVAL; > >>>> + > >>>> ret = ops->suspend(vdpa); > >>>> if (!ret) > >>>> v->suspended = true; > >>>> @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) > >>>> if (!ops->resume) > >>>> return -EOPNOTSUPP; > >>>> > >>>> + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > >>>> + return -EINVAL; > >>>> + > >>>> ret = ops->resume(vdpa); > >>>> if (!ret) > >>>> v->suspended = false; > >>>> -- > >>>> 2.39.3 > >>> > >
On Mon, Feb 12, 2024 at 9:20 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: > > Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all > > vdpa devices. > > > > Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" > > Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > > I don't think failing suspend or resume makes sense though - > e.g. practically failing suspend will just prevent sleeping I think - > why should guest not having driver loaded prevent > system suspend? > In the QEMU case the vhost device has not started, so QEMU should allow the system suspension. I haven't tested the QEMU behavior on suspend (not poweroff) with the guest driver loaded, but I think QEMU should indeed block the suspension, as there is no way to recover the device after that without the guest cooperation? > there's also state such as features set which does need to be > preserved. > That's true if the device does not support resuming. Well, in the particular case of features, maybe we need to keep it, as userspace could call VHOST_GET_FEATURES. But maybe we can clean some things, right. > I think the thing to do is to skip invoking suspend/resume callback, and in > fact checking suspend/resume altogether. > I don't follow this. What should be done in this cases by QEMU? 1) The device does not support suspend 2) The device support suspend but not resume In my opinion 1) should be forbidden, as we don't support to resume the device properly, and 2) can be allowed by fetching all the state. Thanks! > > --- > > drivers/vhost/vdpa.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > > index bc4a51e4638b..ce1882acfc3b 100644 > > --- a/drivers/vhost/vdpa.c > > +++ b/drivers/vhost/vdpa.c > > @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) > > if (!ops->suspend) > > return -EOPNOTSUPP; > > > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > > + return -EINVAL; > > + > > ret = ops->suspend(vdpa); > > if (!ret) > > v->suspended = true; > > @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) > > if (!ops->resume) > > return -EOPNOTSUPP; > > > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > > + return -EINVAL; > > + > > ret = ops->resume(vdpa); > > if (!ret) > > v->suspended = false; > > -- > > 2.39.3 > >
On Tue, Feb 13, 2024 at 8:49 AM Eugenio Perez Martin <eperezma@redhat.com> wrote: > > On Mon, Feb 12, 2024 at 9:20 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote: > > > Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all > > > vdpa devices. > > > > > > Suggested-by: Eugenio Perez Martin <eperezma@redhat.com>" > > > Signed-off-by: Steve Sistare <steven.sistare@oracle.com> > > > > I don't think failing suspend or resume makes sense though - > > e.g. practically failing suspend will just prevent sleeping I think - > > why should guest not having driver loaded prevent > > system suspend? > > > > In the QEMU case the vhost device has not started, so QEMU should > allow the system suspension. > > I haven't tested the QEMU behavior on suspend (not poweroff) with the > guest driver loaded, but I think QEMU should indeed block the > suspension, as there is no way to recover the device after that > without the guest cooperation? > > > there's also state such as features set which does need to be > > preserved. > > > > That's true if the device does not support resuming. Well, in the > particular case of features, maybe we need to keep it, as userspace > could call VHOST_GET_FEATURES. But maybe we can clean some things, > right. > > > I think the thing to do is to skip invoking suspend/resume callback, and in > > fact checking suspend/resume altogether. > > > > I don't follow this. What should be done in this cases by QEMU? > 1) The device does not support suspend > 2) The device support suspend but not resume > > In my opinion 1) should be forbidden, as we don't support to resume > the device properly, and 2) can be allowed by fetching all the state. > Ok I missed the whole other thread, everything is clear now. Thanks! > Thanks! > > > > --- > > > drivers/vhost/vdpa.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > > > index bc4a51e4638b..ce1882acfc3b 100644 > > > --- a/drivers/vhost/vdpa.c > > > +++ b/drivers/vhost/vdpa.c > > > @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) > > > if (!ops->suspend) > > > return -EOPNOTSUPP; > > > > > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > > > + return -EINVAL; > > > + > > > ret = ops->suspend(vdpa); > > > if (!ret) > > > v->suspended = true; > > > @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) > > > if (!ops->resume) > > > return -EOPNOTSUPP; > > > > > > + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) > > > + return -EINVAL; > > > + > > > ret = ops->resume(vdpa); > > > if (!ret) > > > v->suspended = false; > > > -- > > > 2.39.3 > > > >
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index bc4a51e4638b..ce1882acfc3b 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -598,6 +598,9 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v) if (!ops->suspend) return -EOPNOTSUPP; + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) + return -EINVAL; + ret = ops->suspend(vdpa); if (!ret) v->suspended = true; @@ -618,6 +621,9 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v) if (!ops->resume) return -EOPNOTSUPP; + if (!(ops->get_status(vdpa) & VIRTIO_CONFIG_S_DRIVER_OK)) + return -EINVAL; + ret = ops->resume(vdpa); if (!ret) v->suspended = false;