Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp71855ybx; Mon, 4 Nov 2019 16:03:40 -0800 (PST) X-Google-Smtp-Source: APXvYqwlHZZJaFPszd+u0zle03yX76FqdmU/BXRdoXM8/AOj9dynRNeBiabvxNvtdAJdI/MLUq4F X-Received: by 2002:a17:906:6993:: with SMTP id i19mr26733165ejr.259.1572912220127; Mon, 04 Nov 2019 16:03:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572912220; cv=none; d=google.com; s=arc-20160816; b=M0WlyMt+ZadsTgtVfY1Ex2+pbtfoPzKEcTwV1zxKgMyLwP1FqN8rHjvHdl5Mc5Xjv0 1lrA9xy07N39oA6wSxfWqFgwc4rHPhTSsQI3Fbqys3zMbpw60AnTYPA4QcI6x0Ce5hAc anAPy6Uz7KO525nh1yeUsefZs6mC1tY6qv6b+fyM6MiucVbB2m8u4gnp5V2m7eFZhvJF rLrRb7QjnsnC061HmrN+asYDQQ25YHBscxM+QdmIV7+8gE8L1qNIwI9kB2vFJISgmeFz Ep1oShOG3ARwarzx4fyMovGOLd5n7lXZszaPMHt93JRgqKeKpHgF0rUilP83ykolpKTt o3Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wgpWA2jEqJlvczDoO9RtXFfmusK0XNDziQd8UVfs11k=; b=X0SH2gjm0hS7U7nryw3FAYMMTAaBgkGVzjD6G6mV0Ef6YLN6qDzbv6IOSIJY094vlz bV5xfUE+QkU6yrW2cJdnSEw/lrNXuRcrqGAmvyDKhRhSRc1jSPD538ZC1WY4mUPckQu2 Vpuar3h5cnfn7N+hI+UbaBgMHBCHNArrgzntOWsTcZErN6raBqK6DfEV2UKyNIdbnYjp nPRdr2GSjzZvM+zQWYj8eA/y8u6cyikPGraNM3qS3nnLcSVCQAg/VDyUK2OlJgtRjJu5 f89E8GMT37OvZW/GMtVlxP2xLRWmFXP7Lg4IBqc5aL0uVhwCFYPwrlJhzAR+MN+Cen1B p60g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="A/SrpqmE"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1si593543ejr.427.2019.11.04.16.03.15; Mon, 04 Nov 2019 16:03:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="A/SrpqmE"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730124AbfKEACd (ORCPT + 99 others); Mon, 4 Nov 2019 19:02:33 -0500 Received: from mail-ua1-f66.google.com ([209.85.222.66]:46205 "EHLO mail-ua1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728234AbfKEACd (ORCPT ); Mon, 4 Nov 2019 19:02:33 -0500 Received: by mail-ua1-f66.google.com with SMTP id i31so4095892uae.13 for ; Mon, 04 Nov 2019 16:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wgpWA2jEqJlvczDoO9RtXFfmusK0XNDziQd8UVfs11k=; b=A/SrpqmEvJhiTvT76G/tSSPqak6qEdOAyAD0F4wbDPWu94/+f0jv3efhmZsUUXe6qq CybWZB2b/qOXaj/r1Nbyes7WY8VgUjIelgdCzOnhxzWtIMGBD3T63FRfkZ2BE6eRGZIr i+vb47qqghQKbHOImu5dkJFEY1uT2BH1eHjRTifgfw5MuC7sgilYydbBLxES9g+KuSIL L1WK07dG7pk4sigbooRRP48Y+8xvQtnMOXhJZ3I7J9ghmadqrbCv75YuBU7BR9vJzSEx yswAlaOaltIuwCoBGp+vRv4vjVT08L2K0P3ry0DuYv+zs81b3l/ZkUjrhpODm7ydYXfj xzig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wgpWA2jEqJlvczDoO9RtXFfmusK0XNDziQd8UVfs11k=; b=cuS+wOu7t7L+G9z8O6dCzwVf89BXY9VO2gY6V8iONTWMsgcIc0u2NrSUUW8ijzDOxQ aFnFOvv28bo78z/n0ieEIxXdRY9BTgrVzn+CKu8cNwD7R0GMrVheozFqlRXCrBNAb2Po SQcmmBfPmDBlr9mKbQuUox7dWtZgeE+ZS5YTpWUq0egiUJpJ4KMi7/SoPMoHM+DfEHA/ b14Rgq3E4Y3DyL1ASoU06F1avcoAZhgebxFTavbUjlhLCpjxZeWpT3MyY7v6eHTXIvvf YOuI6Dy8ge0KEvK5jngspTPwydZuXYTl+5x67xMNr0JxvIgUc+Af4hDgH3SlehgxNlde ot9g== X-Gm-Message-State: APjAAAViUa4YJeUjcTD18YGEvum22H2Jjm7cFsOYsvNJ/xPX9AMKqTaE Jm4/ci2LO2Z2hVSba8BG37MgD1GxEXKryRYvg8KI+g== X-Received: by 2002:a9f:3772:: with SMTP id a47mr13452102uae.53.1572912151471; Mon, 04 Nov 2019 16:02:31 -0800 (PST) MIME-Version: 1.0 References: <20191018161033.261971-1-samitolvanen@google.com> <20191101221150.116536-1-samitolvanen@google.com> <20191101221150.116536-14-samitolvanen@google.com> <02c56a5273f94e9d832182f1b3cb5097@www.loen.fr> In-Reply-To: From: Sami Tolvanen Date: Mon, 4 Nov 2019 16:02:16 -0800 Message-ID: Subject: Re: [PATCH v4 13/17] arm64: preserve x18 when CPU is suspended To: Nick Desaulniers Cc: Marc Zyngier , Will Deacon , Catalin Marinas , Steven Rostedt , Masami Hiramatsu , Ard Biesheuvel , Dave Martin , Kees Cook , Laura Abbott , Mark Rutland , Jann Horn , Miguel Ojeda , Masahiro Yamada , clang-built-linux , Kernel Hardening , linux-arm-kernel , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 4, 2019 at 1:59 PM Nick Desaulniers wrote: > > On Mon, Nov 4, 2019 at 1:38 PM Sami Tolvanen wrote: > > > > On Mon, Nov 4, 2019 at 5:20 AM Marc Zyngier wrote: > > > > ENTRY(cpu_do_suspend) > > > > mrs x2, tpidr_el0 > > > > @@ -73,6 +75,9 @@ alternative_endif > > > > stp x8, x9, [x0, #48] > > > > stp x10, x11, [x0, #64] > > > > stp x12, x13, [x0, #80] > > > > +#ifdef CONFIG_SHADOW_CALL_STACK > > > > + str x18, [x0, #96] > > > > +#endif > > > > > > Do we need the #ifdefery here? We didn't add that to the KVM path, > > > and I'd feel better having a single behaviour, specially when > > > NR_CTX_REGS is unconditionally sized to hold 13 regs. > > > > I'm fine with dropping the ifdefs here in v5 unless someone objects to this. > > Oh, yeah I guess it would be good to be consistent. Rather than drop > the ifdefs, would you (Marc) be ok with conditionally setting > NR_CTX_REGS based on CONFIG_SHADOW_CALL_STACK, and doing so in KVM? > (So 3 ifdefs, rather than 0)? > > Without any conditionals or comments, it's not clear why x18 is being > saved and restored (unless git blame survives, or a comment is added > in place of the ifdefs in v6). True. Clearing the sleep state buffer in cpu_do_resume is also pointless without CONFIG_SHADOW_CALL_STACK, so if the ifdefs are removed, some kind of an explanation is needed there. Sami