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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 D6A11CA9EC9 for ; Tue, 5 Nov 2019 00:02:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A634E20717 for ; Tue, 5 Nov 2019 00:02:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="A/SrpqmE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730142AbfKEACd (ORCPT ); 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-Google-Smtp-Source: APXvYqxDpgmQ9n/cnDstvJ7riCGFej5xZ9eZp7xC3KSVKRHhU1yTfVmSiCTnVQNCB9cZ2N32DJmU1C4HUXLbveOO274= 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 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=-0.7 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 23F5ECA9EC9 for ; Tue, 5 Nov 2019 00:02:38 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC80620717 for ; Tue, 5 Nov 2019 00:02:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Tqh9PmZV"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="A/SrpqmE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC80620717 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bxoKuOtsRQCRbzZTFceinTnWXmbJFBNkrtAVLChQflk=; b=Tqh9PmZVMVCxNY ihPIrTY7qAf9ABAU4O0WIrBY8UW/QKFKKV1Ptcm27QJGDc8peGnsWHFvdT3bqfMOA7Um8fg0FM45E uuFrQKR0x8R3X/AEiL8F2W2vpMvCeLrsK2s8My9KLZRqSKDPb7nxyx/c2xMaQvM1bThMx5CDTgMgE Pd6bDWwpScHyFw+YrGfsoVeRLF6WsIlLbeT8Ms/eTMnTOMIkmSYAvBHdCWIOj/wmbrT1FvaWyLTeP e4Sg7Vu0NVi1gdUQl2WS8hiUU9YxzU/9nJ4WXfaLwUE7eQyBiQ6Ac2YqqI6uz1FwOAe7bE/tcPRlZ GkOImRN9s6+jA7odQOeQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iRmIv-0007RN-1m; Tue, 05 Nov 2019 00:02:37 +0000 Received: from mail-ua1-x942.google.com ([2607:f8b0:4864:20::942]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iRmIr-0007Ql-4V for linux-arm-kernel@lists.infradead.org; Tue, 05 Nov 2019 00:02:34 +0000 Received: by mail-ua1-x942.google.com with SMTP id s25so1192092uap.1 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=bYIW0OfKTk0fskKgHO1/t6XsgX2XwhFoN7ct4VINFYkZdtFZPcqbOt81w3exw0y2Bo 7NEBed+7OqSIGIMN1z7h5a0q2V58btQBYaJHU+kBet+1bWra2ho9YL3SCOt+e7ERRRfd kPBxqMvrxdIjS7zhYHOMXGDjbPg/AeM4mo7FKAqKVc7M/2zLRKiiuqqsWBwEo4soaxmo bt79Z19NKYTQyPnUeQ0kzkpTbXBNqVeUyB466A4dxnb4iAO1QFjUDIP5A5SXIH7yJxNz RKcDu/zEzYk8+oU1qfyvEn9ly6Cr27jIQu2pH1HdaG6RIr20/5cfH87D9BamCOlQFcYA D18g== X-Gm-Message-State: APjAAAVJDiP1bk3E+jnUsSVHqBPrErZTCPXk2vS13MGgYMZSA+inJ/sC v/jDI9/7XLZfy8wgQAbZyInoQcvgxpVRP2UtzP3+eQ== X-Google-Smtp-Source: APXvYqxDpgmQ9n/cnDstvJ7riCGFej5xZ9eZp7xC3KSVKRHhU1yTfVmSiCTnVQNCB9cZ2N32DJmU1C4HUXLbveOO274= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191104_160233_398340_84680A23 X-CRM114-Status: GOOD ( 15.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kees Cook , Ard Biesheuvel , Masahiro Yamada , Marc Zyngier , Jann Horn , LKML , Steven Rostedt , Miguel Ojeda , clang-built-linux , Masami Hiramatsu , Catalin Marinas , Kernel Hardening , Laura Abbott , Will Deacon , Dave Martin , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C5BB0CA9EC9 for ; Tue, 5 Nov 2019 00:02:50 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 168F320848 for ; Tue, 5 Nov 2019 00:02:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="A/SrpqmE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 168F320848 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17281-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 9892 invoked by uid 550); 5 Nov 2019 00:02:44 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 9872 invoked from network); 5 Nov 2019 00:02:43 -0000 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=G4f97cpvZPl4bZpyDkc1mIvoi0xvLw4IBxYRr6U+DndF5uSdEqcgJ/TVjS6N2s2ANu mnwjjzkGkrMsLDjaMC1KSzXeLhmWNOColEQthc2y7cFxoI1ibeeQUZia9LA4AD5yE4dn jiTlsW9SPVFNSI4sTJRy3Ja8mD9C7JzU52MiQX1qNdcwsJdp3LZkaKKZOhWDSzGJZEe0 btsSn7tp4rEjqju1Alfvj6TjZeM2LhrNxxnmmiUk35veybkXT/S+MrVGOQa8cUx9SRCk AkzTI1MBKHudbvmN7al1D32LJn93LXoMuxYBpNq0uDhKBQ/Bj3EiWTwQxf2vIMx4/CA0 xGiA== X-Gm-Message-State: APjAAAXj196niryKHGESeOhN4dbzzNa32GfYE7EQkBLlYpxNtwziMo53 Qnq65+QKPmjv5sBjPoRuz5VPgat1XvlW4Qh40/1SaA== X-Google-Smtp-Source: APXvYqxDpgmQ9n/cnDstvJ7riCGFej5xZ9eZp7xC3KSVKRHhU1yTfVmSiCTnVQNCB9cZ2N32DJmU1C4HUXLbveOO274= 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" 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