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 6F062C433E1 for ; Wed, 22 Jul 2020 18:03:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3409D2084D for ; Wed, 22 Jul 2020 18:03:05 +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="n3fKOZmR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3409D2084D 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 A74266B0002; Wed, 22 Jul 2020 14:03:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FD2D6B0005; Wed, 22 Jul 2020 14:03:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C5BE6B0006; Wed, 22 Jul 2020 14:03:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 6FED96B0002 for ; Wed, 22 Jul 2020 14:03:04 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 042F38248047 for ; Wed, 22 Jul 2020 18:03:04 +0000 (UTC) X-FDA: 77066483088.03.cough68_2a0234726f38 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 5EA702B84B for ; Wed, 22 Jul 2020 18:02:52 +0000 (UTC) X-HE-Tag: cough68_2a0234726f38 X-Filterd-Recvd-Size: 9014 Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jul 2020 18:02:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1595440971; x=1626976971; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=7S9G0j6WNk2lHQ1bZXQAcCjIdbziJxspgdHUPMMA6gA=; b=n3fKOZmRaWlxBxz8OeIFS/hlDM2E87OppNvfThGepfcaJqkjR7iQT9Dj dRT2IAFeAXGhT3jKEnn5cRRKjiWMcWmnPjGGG2AJ8a/nBplCMM1EvxDzO D/VBmBlpV94ZQ0ycDkUre0pLYhLg6dXIYwH3uZUaKisYOKOQ4IGRTHJKo I=; IronPort-SDR: gddspTBzn+Y+TFjJTeY9TdNlPFZ60AB2yNuYk5xuO/V+CC+LP+ZLXGVyt1ka9QWY+Qo+37Am9i sF1re8O1G5oQ== X-IronPort-AV: E=Sophos;i="5.75,383,1589241600"; d="scan'208";a="60802713" 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-1e-c7c08562.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 22 Jul 2020 18:02:46 +0000 Received: from EX13MTAUEB002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (Postfix) with ESMTPS id 51994240ABB; Wed, 22 Jul 2020 18:02:40 +0000 (UTC) Received: from EX13D08UEB004.ant.amazon.com (10.43.60.142) by EX13MTAUEB002.ant.amazon.com (10.43.60.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jul 2020 18:02:30 +0000 Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by EX13D08UEB004.ant.amazon.com (10.43.60.142) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jul 2020 18:02:29 +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.243) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 22 Jul 2020 18:02:29 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 8E7C44CA97; Wed, 22 Jul 2020 18:02:29 +0000 (UTC) Date: Wed, 22 Jul 2020 18:02:29 +0000 From: Anchal Agarwal To: Stefano Stabellini CC: Boris Ostrovsky , , , , , , , , , , , , , , , , , , , , , , , , , Message-ID: <20200722180229.GA32316@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> <20200721000348.GA19610@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <408d3ce9-2510-2950-d28d-fdfe8ee41a54@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 5EA702B84B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini 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 > On Tue, 21 Jul 2020, Boris Ostrovsky wrote: > > >>>>>> +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 whet= her 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 an= d the 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 abou= t PM > > >>> HIBERNATION I may just remove this code and rely on "SHUTDOWN_SUS= PEND" state. > > >>> However, I may have to fix other patches in the series where this= check may > > >>> appear and cater it only for x86 right? > > >> > > >> > > >> I don't know what would happen if ARM guest tries to handle hibern= ation > > >> callbacks. The only ones that you are introducing are in block and= net > > >> fronts and that's arch-independent. > > >> > > >> > > >> You do add a bunch of x86-specific code though (syscore ops), woul= d > > >> something similar be needed for ARM? > > >> > > >> > > > I don't expect this to work out of the box on ARM. To start with so= mething > > > 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 suppo= rt is only > > > proposed for x86 guests here and similar work could be carried out = for ARM. > > > Also, if regular hibernation works correctly on arm, then all is ne= eded is to > > > fix Xen side of things. > > > > > > I am not sure what could be done to achieve any assurances on arm s= ide as far as > > > this series is concerned. >=20 > Just to clarify: new features don't need to work on ARM or cause any > addition efforts to you to make them work on ARM. The patch series only > needs not to break existing code paths (on ARM and any other platforms)= . > It should also not make it overly difficult to implement the ARM side o= f > things (if there is one) at some point in the future. >=20 > FYI drivers/xen/manage.c is compiled and working on ARM today, however > Xen suspend/resume is not supported. I don't know for sure if > guest-initiated hibernation works because I have not tested it. >=20 >=20 >=20 > > If you are not sure what the effects are (or sure that it won't work)= on > > ARM then I'd add IS_ENABLED(CONFIG_X86) check, i.e. > > > > > > if (!IS_ENABLED(CONFIG_X86) || !xen_hvm_domain()) > > return -ENODEV; >=20 > That is a good principle to have and thanks for suggesting it. However, > in this specific case there is nothing in this patch that doesn't work > on ARM. From an ARM perspective I think we should enable it and > &xen_pm_notifier_block should be registered. >=20 This question is for Boris, I think you we decided to get rid of the noti= fier in V3 as all we need to check is SHUTDOWN_SUSPEND state which sounds pla= usible to me. So this check may go away. It may still be needed for sycore_ops callbacks registration. > Given that all guests are HVM guests on ARM, it should work fine as is. >=20 >=20 > I gave a quick look at the rest of the series and everything looks fine > to me from an ARM perspective. I cannot imaging that the new freeze, > thaw, and restore callbacks for net and block are going to cause any > trouble on ARM. The two main x86-specific functions are > xen_syscore_suspend/resume and they look trivial to implement on ARM (i= n > the sense that they are likely going to look exactly the same.) >=20 Yes but for now since things are not tested I will put this !IS_ENABLED(CONFIG_X86) on syscore_ops calls registration part just to be= safe and not break anything. >=20 > One question for Anchal: what's going to happen if you trigger a > hibernation, you have the new callbacks, but you are missing > xen_syscore_suspend/resume? >=20 > Is it any worse than not having the new freeze, thaw and restore > callbacks at all and try to do a hibernation? If callbacks are not there, I don't expect hibernation to work correctly. These callbacks takes care of xen primitives like shared_info_page, grant table, sched clock, runstate time which are important to save the c= orrect state of the guest and bring it back up. Other patches in the series, add= s all the logic to these syscore callbacks. Freeze/thaw/restore are just there = for at driver level. Thanks, Anchal