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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 22072C4338F for ; Wed, 11 Aug 2021 12:19:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 00A616023B for ; Wed, 11 Aug 2021 12:19:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237453AbhHKMTp (ORCPT ); Wed, 11 Aug 2021 08:19:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237382AbhHKMTe (ORCPT ); Wed, 11 Aug 2021 08:19:34 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3D26C06179B for ; Wed, 11 Aug 2021 05:19:07 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id w20so5259617lfu.7 for ; Wed, 11 Aug 2021 05:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=QRfjFOudnOiwA+M7/UAaVDTJpihSFBYjea6mHo6NSYA=; b=FrdABWFOYFHYVQYvsn9eIFG1XXIqUnaFBCPEPrWXTbkImjcaYqnfbbDKJbjXTj8n2z XKpeeMl+HDYMaw1njH7BCzSmXb2GWH1pBn4+E1w1Zkax9zqjTCMN0ceFLpN0oNSL7p4h tTOYo06jVnb3EuSp9CAkw3RajLjCGRh5DcWWOVaUC3oCLa3fiXHjMHrKiPKxkbd9MHf4 XWiG9YDES/j+Q6K8AbBgatHhy3Ey7EF4Mw9l8egNLjOvPiIJBkLqlDJHfGJd1OD2IwY9 /Dj5oeYRUTA55X3eykWwXtvq+RdRhaXu8H17iGSYXfRtDXdJr3ACYPa147h4M5kexh1Q 1YFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=QRfjFOudnOiwA+M7/UAaVDTJpihSFBYjea6mHo6NSYA=; b=OHbfiXm8OYwNFVQY1q4kGPboAOjuHq/B2vlca7CUtLP3roKB/cIzKN1IUcZgmeH70M heVaIJYrgrXdGvcNjh9OCS4jdScaDJHXZ34DGiP/LU7RKtdDpMUjsMVKln9C5GhYrvtm GFpN9JUPdRLU2T5nKezAks7bfHZUL5LNs1w+KtapGjlk/5uc6y6z39S2RN0ZzrLopgjR NSD2mhkoW4HrAVhjwzgMumxcqksZ2rnCQ10lPHYF18DKoFK+S4sZEAOBsMvxW9Ss3PwI 8A40DhH8R4+mnsPK1EhItuDrJ/pT6CaqpGkCvBuAIp4XPrqM6TKezRLnD313ScH0XZUT xYmA== X-Gm-Message-State: AOAM531athbcn7OrTQC/F+zV3TmqWtMkoy2CgSdHqhiaDgG46dsacERQ 7isDK9iYCyEXpJc5MCHdBZq2mg== X-Google-Smtp-Source: ABdhPJwYqCmmrayYkwT8dKOh/tHUuUvcGTl6bQD02skpgV77PxIfPFHOo1k2HSgXk2Z2qwWhaj6ksA== X-Received: by 2002:ac2:50d8:: with SMTP id h24mr4762329lfm.631.1628684346244; Wed, 11 Aug 2021 05:19:06 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id w7sm2337599lft.285.2021.08.11.05.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 05:19:05 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id A68EB102A2E; Wed, 11 Aug 2021 15:19:17 +0300 (+03) Date: Wed, 11 Aug 2021 15:19:17 +0300 From: "Kirill A. Shutemov" To: Tom Lendacky Cc: "Kuppuswamy, Sathyanarayanan" , linux-kernel@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, iommu@lists.linux-foundation.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-graphics-maintainer@vmware.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, Borislav Petkov , Brijesh Singh , Joerg Roedel , Andi Kleen , Tianyu Lan , Thomas Gleixner , Ingo Molnar , Dave Hansen , Andy Lutomirski , Peter Zijlstra , David Airlie , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Will Deacon , Dave Young , Baoquan He Subject: Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has() Message-ID: <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> References: <029791b24c6412f9427cfe6ec598156c64395964.1627424774.git.thomas.lendacky@amd.com> <166f30d8-9abb-02de-70d8-6e97f44f85df@linux.intel.com> <4b885c52-f70a-147e-86bd-c71a8f4ef564@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4b885c52-f70a-147e-86bd-c71a8f4ef564@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote: > On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote: > > > > > > On 7/27/21 3:26 PM, Tom Lendacky wrote: > >> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > >> index de01903c3735..cafed6456d45 100644 > >> --- a/arch/x86/kernel/head64.c > >> +++ b/arch/x86/kernel/head64.c > >> @@ -19,7 +19,7 @@ > >>   #include > >>   #include > >>   #include > >> -#include > >> +#include > >>   #include > >>     #include > >> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long > >> physaddr, > >>        * there is no need to zero it after changing the memory encryption > >>        * attribute. > >>        */ > >> -    if (mem_encrypt_active()) { > >> +    if (prot_guest_has(PATTR_MEM_ENCRYPT)) { > >>           vaddr = (unsigned long)__start_bss_decrypted; > >>           vaddr_end = (unsigned long)__end_bss_decrypted; > > > > > > Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT with > > prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in > > TDX. > > This is a direct replacement for now. With current implementation of prot_guest_has() for TDX it breaks boot for me. Looking at code agains, now I *think* the reason is accessing a global variable from __startup_64() inside TDX version of prot_guest_has(). __startup_64() is special. If you access any global variable you need to use fixup_pointer(). See comment before __startup_64(). I'm not sure how you get away with accessing sme_me_mask directly from there. Any clues? Maybe just a luck and complier generates code just right for your case, I donno. A separate point is that TDX version of prot_guest_has() relies on cpu_feature_enabled() which is not ready at this point. I think __bss_decrypted fixup has to be done if sme_me_mask is non-zero. Or just do it uncoditionally because it's NOP for sme_me_mask == 0. > I think the change you're requesting > should be done as part of the TDX support patches so it's clear why it is > being changed. > > But, wouldn't TDX still need to do something with this shared/unencrypted > area, though? Or since it is shared, there's actually nothing you need to > do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not > configured)? AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in TDX at the moment. It may change in the future. -- Kirill A. Shutemov