From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A3FCC433E3 for ; Tue, 21 Jul 2020 00:04:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1BE5A208E4 for ; Tue, 21 Jul 2020 00:04:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="YoEScPGp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BE5A208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8CCAA8D0006; Mon, 20 Jul 2020 20:04:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8547A8D0002; Mon, 20 Jul 2020 20:04:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 743308D0006; Mon, 20 Jul 2020 20:04:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 5DD8A8D0002 for ; Mon, 20 Jul 2020 20:04:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C916718023421 for ; Tue, 21 Jul 2020 00:04:12 +0000 (UTC) X-FDA: 77060135544.03.sun22_2f0241a26f28 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 982AC1998D for ; Tue, 21 Jul 2020 00:04:12 +0000 (UTC) X-HE-Tag: sun22_2f0241a26f28 X-Filterd-Recvd-Size: 9052 Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Jul 2020 00:04:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1595289852; x=1626825852; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=UsYCfB4vUXuGXUfz5NputLMtDzKXoyLRAcqjcS/oV1U=; b=YoEScPGpspk+hsSLrYN6O/Vne0yIAckAtaKpC2QnKpiYEIoFVLSNtiKK 80uNmwlCGzeMGYNatf/yyZTx/FDUuUQOiOc5CbaggNqf7Y3OcMpj0t6zr dZAFuPRHBqaT8ZFeLulUOu9RXUv6+1WyUVukRIz24SkeNeWGSl2+VN25O g=; IronPort-SDR: tZK50MAqoODz1iBYxa4vWL5exodTTwRmcIhymTRjjXO2FMSE1DvQe+l0hCyjOlwb8BWlXHn/1m DLjLzCD/UXHg== X-IronPort-AV: E=Sophos;i="5.75,375,1589241600"; d="scan'208";a="53134259" Subject: Re: [PATCH v2 01/11] xen/manage: keep track of the on-going suspend mode Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 21 Jul 2020 00:04:07 +0000 Received: from EX13MTAUEE002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (Postfix) with ESMTPS id EECCBA1D1D; Tue, 21 Jul 2020 00:04:00 +0000 (UTC) Received: from EX13D08UEE004.ant.amazon.com (10.43.62.182) by EX13MTAUEE002.ant.amazon.com (10.43.62.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Jul 2020 00:03:48 +0000 Received: from EX13MTAUEA002.ant.amazon.com (10.43.61.77) by EX13D08UEE004.ant.amazon.com (10.43.62.182) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Jul 2020 00:03:48 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.61.169) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 21 Jul 2020 00:03:48 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 16C9240844; Tue, 21 Jul 2020 00:03:48 +0000 (UTC) Date: Tue, 21 Jul 2020 00:03:48 +0000 From: Anchal Agarwal To: Boris Ostrovsky CC: , , , , , , , , , , , , , , , , , , , , , , , , , , Message-ID: <20200721000348.GA19610@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <20200702182136.GA3511@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <50298859-0d0e-6eb0-029b-30df2a4ecd63@oracle.com> <20200715204943.GB17938@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <0ca3c501-e69a-d2c9-a24c-f83afd4bdb8c@oracle.com> <20200717191009.GA3387@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <5464f384-d4b4-73f0-d39e-60ba9800d804@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <5464f384-d4b4-73f0-d39e-60ba9800d804@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 982AC1998D X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Jul 18, 2020 at 09:47:04PM -0400, Boris Ostrovsky wrote: > CAUTION: This email originated from outside of the organization. Do not= click links or open attachments unless you can confirm the sender and kn= ow the content is safe. >=20 >=20 >=20 > (Roger, question for you at the very end) >=20 > On 7/17/20 3:10 PM, Anchal Agarwal wrote: > > On Wed, Jul 15, 2020 at 05:18:08PM -0400, Boris Ostrovsky wrote: > >> CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you can confirm the sender and= know the content is safe. > >> > >> > >> > >> On 7/15/20 4:49 PM, Anchal Agarwal wrote: > >>> On Mon, Jul 13, 2020 at 11:52:01AM -0400, Boris Ostrovsky wrote: > >>>> CAUTION: This email originated from outside of the organization. D= o not click links or open attachments unless you can confirm the sender a= nd know the content is safe. > >>>> > >>>> > >>>> > >>>> On 7/2/20 2:21 PM, Anchal Agarwal wrote: > >>>>> + > >>>>> +bool xen_is_xen_suspend(void) > >>>> Weren't you going to call this pv suspend? (And also --- is this s= uspend > >>>> or hibernation? Your commit messages and cover letter talk about f= ixing > >>>> hibernation). > >>>> > >>>> > >>> This is for hibernation is for pvhvm/hvm/pv-on-hvm guests as you ma= y call it. > >>> The method is just there to check if "xen suspend" is in progress. > >>> I do not see "xen_suspend" differentiating between pv or hvm > >>> domain until later in the code hence, I abstracted it to xen_is_xen= _suspend. > >> > >> I meant "pv suspend" in the sense that this is paravirtual suspend, = not > >> suspend for paravirtual guests. Just like pv drivers are for both pv= and > >> hvm guests. > >> > >> > >> And then --- should it be pv suspend or pv hibernation? > >> > >> > > Ok so I think I am lot confused by this question. Here is what this > > function for, function xen_is_xen_suspend() just tells us whether > > the guest is in "SHUTDOWN_SUSPEND" state or not. This check is needed > > for correct invocation of syscore_ops callbacks registered for guest'= s > > hibernation and for xenbus to invoke respective callbacks[suspend/res= ume > > vs freeze/thaw/restore]. > > Since "shutting_down" state is defined static and is not directly ava= ilable > > to other parts of the code, the function solves the purpose. > > > > I am having hard time understanding why this should be called pv > > suspend/hibernation unless you are suggesting something else? > > Am I missing your point here? >=20 >=20 >=20 > I think I understand now what you are trying to say --- it's whether we > are going to use xen_suspend() routine, right? If that's the case then > sure, you can use "xen_suspend" term. (I'd probably still change > xen_is_xen_suspend() to is_xen_suspend()) > I think so too. Will change it. >=20 > >>>>> +{ > >>>>> + return suspend_mode =3D=3D XEN_SUSPEND; > >>>>> +} > >>>>> + > >>>> +static int xen_setup_pm_notifier(void) > >>>> +{ > >>>> + if (!xen_hvm_domain()) > >>>> + return -ENODEV; > >>>> > >>>> I forgot --- what did we decide about non-x86 (i.e. ARM)? > >>> It would be great to support that however, its out of > >>> scope for this patch set. > >>> I=E2=80=99ll be happy to discuss it separately. > >> > >> I wasn't implying that this *should* work on ARM but rather whether = this > >> will break ARM somehow (because xen_hvm_domain() is true there). > >> > >> > > Ok makes sense. TBH, I haven't tested this part of code on ARM and th= e series > > was only support x86 guests hibernation. > > Moreover, this notifier is there to distinguish between 2 PM > > events PM SUSPEND and PM hibernation. Now since we only care about PM > > HIBERNATION I may just remove this code and rely on "SHUTDOWN_SUSPEND= " state. > > However, I may have to fix other patches in the series where this che= ck may > > appear and cater it only for x86 right? >=20 >=20 > I don't know what would happen if ARM guest tries to handle hibernation > callbacks. The only ones that you are introducing are in block and net > fronts and that's arch-independent. >=20 >=20 > You do add a bunch of x86-specific code though (syscore ops), would > something similar be needed for ARM? >=20 >=20 I don't expect this to work out of the box on ARM. To start with somethin= g similar will be needed for ARM too. We may still want to keep the driver code as-is. I understand the concern here wrt ARM, however, currently the support is = only proposed for x86 guests here and similar work could be carried out for AR= M. Also, if regular hibernation works correctly on arm, then all is needed i= s to fix Xen side of things. I am not sure what could be done to achieve any assurances on arm side as= far as this series is concerned. > >>>> And PVH dom0. > >>> That's another good use case to make it work with however, I still > >>> think that should be tested/worked upon separately as the feature i= tself > >>> (PVH Dom0) is very new. > >> > >> Same question here --- will this break PVH dom0? > >> > > I haven't tested it as a part of this series. Is that a blocker here? >=20 >=20 > I suspect dom0 will not do well now as far as hibernation goes, in whic= h > case you are not breaking anything. >=20 >=20 > Roger? >=20 >=20 > -boris Thanks, Anchal >=20 >=20 >=20