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 B497CC4338F for ; Thu, 12 Aug 2021 10:07:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 320636109F for ; Thu, 12 Aug 2021 10:07:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236034AbhHLKHz (ORCPT ); Thu, 12 Aug 2021 06:07:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235500AbhHLKHm (ORCPT ); Thu, 12 Aug 2021 06:07:42 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AED80C06179B for ; Thu, 12 Aug 2021 03:07:13 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id n6so9735466ljp.9 for ; Thu, 12 Aug 2021 03:07:13 -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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=i5pl2dc+IIZq62s73J165t7SbTE/a6uwhQcs74jwe9KmwHHHprhV6B7adGgzY2ul5F h3ad9IJiBKNdQ1Yy+0atN7ISXCxsrMGXnfmJsO6X4rAencCuDMvqer1gR8DISUT+MUdX mFWLcuQYXLFjOzlL0+b+7kJuGkuB4wCN/YMkw/r+eyS6zgywYe+L6amtdlG3N+EOpGsE J1HMLNEKBn3QeV3/WPSCpmI5s5ySDG9/4fJ+UJO1H5Xch03iP3WdOduEdYUt1pTqbuK7 XsqkYhAszn/r202BsWcaBlPgkZHQ5nFUcQEBqetJcuzusrxc9TEefXgeJD4qBlDR12PM /RWw== 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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=h8nSUi7HY+pRhextmtHtr93xs/MEopdjRZv9mnyEZmkR803X2RD4u0PfitqYxFKPje jwaaepXZnvQRWQ8AKgkklv4gp6clxOwSiAcsqo+wWJHikflVfwstBjwzwdSqUbCvf0FC iD8lpXuXIuJwfmi+W9aGYldtnd2lpab1j2BM2XwtIQpiIr7Av4/7qSIeTxW7KRLGRhRA whAa2lE4vcgqxlFWscRXqAFTmzZQQolLpcg5mT7YxEmuJ269Hm/WjJjmIKmuSfvfAyr7 GAB1E65FuX4X99antm8JLGHDYbFn3Nklph64yK3OEQXK/5jne7sH/oH45x7J0mlyq/Qq FQ8A== X-Gm-Message-State: AOAM531YdCXfK9xoParUFTWBJaU4296M6M5ClmhtjQvIvHihkCA+v+/f 4l8PltxnBiHOSoDZjOwRbIeYIw== X-Google-Smtp-Source: ABdhPJzegmFCE5odxbsD4HArsZ9uuMjN7H8TkJnoN55vikWCUHEpo/5436B3LFAXNhCNvYbyx3Wtvw== X-Received: by 2002:a2e:814a:: with SMTP id t10mr2410500ljg.318.1628762831975; Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o8sm212528lfo.292.2021.08.12.03.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B75B41028BC; Thu, 12 Aug 2021 13:07:24 +0300 (+03) Date: Thu, 12 Aug 2021 13:07:24 +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: <20210812100724.t4cdh7xbkuqgnsc3@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> <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > 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. > > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > 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. > > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- Kirill A. Shutemov 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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 EE758C4338F for ; Thu, 12 Aug 2021 10:08:05 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 5C286610A7 for ; Thu, 12 Aug 2021 10:08:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5C286610A7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Glj76587yz3cKc for ; Thu, 12 Aug 2021 20:08:02 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=i5pl2dc+; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=shutemov.name (client-ip=2a00:1450:4864:20::229; helo=mail-lj1-x229.google.com; envelope-from=kirill@shutemov.name; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=i5pl2dc+; dkim-atps=neutral Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Glj6K25pLz2xy4 for ; Thu, 12 Aug 2021 20:07:19 +1000 (AEST) Received: by mail-lj1-x229.google.com with SMTP id x7so9754846ljn.10 for ; Thu, 12 Aug 2021 03:07:19 -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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=i5pl2dc+IIZq62s73J165t7SbTE/a6uwhQcs74jwe9KmwHHHprhV6B7adGgzY2ul5F h3ad9IJiBKNdQ1Yy+0atN7ISXCxsrMGXnfmJsO6X4rAencCuDMvqer1gR8DISUT+MUdX mFWLcuQYXLFjOzlL0+b+7kJuGkuB4wCN/YMkw/r+eyS6zgywYe+L6amtdlG3N+EOpGsE J1HMLNEKBn3QeV3/WPSCpmI5s5ySDG9/4fJ+UJO1H5Xch03iP3WdOduEdYUt1pTqbuK7 XsqkYhAszn/r202BsWcaBlPgkZHQ5nFUcQEBqetJcuzusrxc9TEefXgeJD4qBlDR12PM /RWw== 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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=ebUj0Orvg5+W0+C55lWyiJFmnuBHzz9dbh7q0+/NhEhi2kAePT2b2o+1XcT+HmbEDD XebDjNCnBCDw5gv8ZGk/Sa1l3Q+NeRJvMu96R9v0dDcg4Js86XAvYh4DKpUWWYkLQNr6 vDyZfS1iGGxnywcfibklNr9b99y0g+Iz8HlxrTfSfWphmGoCQ5BEtBTmarhzIaVueesn /x9Bi0faBzVbhbBMey1u20gx0dTLGcweRqfpSI4esmLlGz6BOFb+BYqoZGnCKQpyfNKL DS4+xjkOi/Askrw6bzWasALr4mB0ZGKAhyRtE9rMGHk0DTgqG4TLTA9iNrhgLzM5QfuB 8dag== X-Gm-Message-State: AOAM5326aCVm4m906FOjYCYuCqRxkpWug6mRzmiQgC8svt0qcpR3z+r0 t6DuYeX0vSs+3jBPdI9EF6bq8Q== X-Google-Smtp-Source: ABdhPJzegmFCE5odxbsD4HArsZ9uuMjN7H8TkJnoN55vikWCUHEpo/5436B3LFAXNhCNvYbyx3Wtvw== X-Received: by 2002:a2e:814a:: with SMTP id t10mr2410500ljg.318.1628762831975; Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o8sm212528lfo.292.2021.08.12.03.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B75B41028BC; Thu, 12 Aug 2021 13:07:24 +0300 (+03) Date: Thu, 12 Aug 2021 13:07:24 +0300 From: "Kirill A. Shutemov" To: Tom Lendacky Subject: Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has() Message-ID: <20210812100724.t4cdh7xbkuqgnsc3@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> <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Kuppuswamy, Sathyanarayanan" , linux-efi@vger.kernel.org, Brijesh Singh , kvm@vger.kernel.org, Peter Zijlstra , Dave Hansen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Will Deacon , linux-s390@vger.kernel.org, Andi Kleen , Baoquan He , Joerg Roedel , x86@kernel.org, amd-gfx@lists.freedesktop.org, David Airlie , Ingo Molnar , linux-graphics-maintainer@vmware.com, Dave Young , Tianyu Lan , Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Daniel Vetter , linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > 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. > > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > 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. > > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- Kirill A. Shutemov 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 00850C432BE for ; Thu, 12 Aug 2021 10:07:22 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.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 8CAF960FC4 for ; Thu, 12 Aug 2021 10:07:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8CAF960FC4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 456DB400E9; Thu, 12 Aug 2021 10:07:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL2_N-5R5gco; Thu, 12 Aug 2021 10:07:17 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 11EF040732; Thu, 12 Aug 2021 10:07:17 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id D5344C001A; Thu, 12 Aug 2021 10:07:16 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BDBE1C000E for ; Thu, 12 Aug 2021 10:07:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A7557405E3 for ; Thu, 12 Aug 2021 10:07:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IDNYcQ8MMFQ for ; Thu, 12 Aug 2021 10:07:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by smtp4.osuosl.org (Postfix) with ESMTPS id 464C8405E0 for ; Thu, 12 Aug 2021 10:07:14 +0000 (UTC) Received: by mail-lj1-x235.google.com with SMTP id x9so9816781ljj.2 for ; Thu, 12 Aug 2021 03:07:14 -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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=i5pl2dc+IIZq62s73J165t7SbTE/a6uwhQcs74jwe9KmwHHHprhV6B7adGgzY2ul5F h3ad9IJiBKNdQ1Yy+0atN7ISXCxsrMGXnfmJsO6X4rAencCuDMvqer1gR8DISUT+MUdX mFWLcuQYXLFjOzlL0+b+7kJuGkuB4wCN/YMkw/r+eyS6zgywYe+L6amtdlG3N+EOpGsE J1HMLNEKBn3QeV3/WPSCpmI5s5ySDG9/4fJ+UJO1H5Xch03iP3WdOduEdYUt1pTqbuK7 XsqkYhAszn/r202BsWcaBlPgkZHQ5nFUcQEBqetJcuzusrxc9TEefXgeJD4qBlDR12PM /RWw== 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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=ntLDhkbGUF9YmyO06uOfdENLrSHD7yx1+SvSFG7mKzo8SQrInpoAWnuXdNe6HY3m1+ x9DxYji0BpNVH/AKOS/gXWvtVBN4BeaNwxHydLTAHV1e+NXaNlNticCorVcSo/NaZDg6 5qxcatlhx205AshgdwtqG0CDeR07HpG5vio5w5JPQ8uQ4DIhijS6mNWQOKVXlbi7Yi15 yNFJvvWz5PVOSKo5ugKzylAeKLoICVUvRJVBtNzhagu9gJ+DgcGWRO5+pXnJhOazaliK gGwBZeiAEqz2b1C5RjD6UKU3SfLOM1AYUNz2L2Z+lPySZnVJHZm240zyMmb+0SyBtPiH Iskg== X-Gm-Message-State: AOAM5325ZPoDtdQ1jTcCXWi2nmMP+Ed+v2q4PVXuipXWW6bS0NyGrVzJ rJebE7I7aWAxvwjZEf6FwTXyJw== X-Google-Smtp-Source: ABdhPJzegmFCE5odxbsD4HArsZ9uuMjN7H8TkJnoN55vikWCUHEpo/5436B3LFAXNhCNvYbyx3Wtvw== X-Received: by 2002:a2e:814a:: with SMTP id t10mr2410500ljg.318.1628762831975; Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o8sm212528lfo.292.2021.08.12.03.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B75B41028BC; Thu, 12 Aug 2021 13:07:24 +0300 (+03) Date: Thu, 12 Aug 2021 13:07:24 +0300 From: "Kirill A. Shutemov" To: Tom Lendacky Subject: Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has() Message-ID: <20210812100724.t4cdh7xbkuqgnsc3@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> <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> Cc: linux-efi@vger.kernel.org, Brijesh Singh , kvm@vger.kernel.org, Peter Zijlstra , Dave Hansen , dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, Will Deacon , linux-s390@vger.kernel.org, Andi Kleen , x86@kernel.org, amd-gfx@lists.freedesktop.org, David Airlie , Ingo Molnar , linux-graphics-maintainer@vmware.com, Dave Young , Tianyu Lan , Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Daniel Vetter , linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > 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 @@ > >>>> =A0 #include > >>>> =A0 #include > >>>> =A0 #include > >>>> -#include > >>>> +#include > >>>> =A0 #include > >>>> =A0 =A0 #include > >>>> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long > >>>> physaddr, > >>>> =A0=A0=A0=A0=A0=A0 * there is no need to zero it after changing the = memory encryption > >>>> =A0=A0=A0=A0=A0=A0 * attribute. > >>>> =A0=A0=A0=A0=A0=A0 */ > >>>> -=A0=A0=A0 if (mem_encrypt_active()) { > >>>> +=A0=A0=A0 if (prot_guest_has(PATTR_MEM_ENCRYPT)) { > >>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 vaddr =3D (unsigned long)__start_bss_dec= rypted; > >>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 vaddr_end =3D (unsigned long)__end_bss_d= ecrypted; > >>> > >>> > >>> Since this change is specific to AMD, can you replace PATTR_MEM_ENCRY= PT with > >>> prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not use= d 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 ri= ght > > for your case, I donno. > = > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > = > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > 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 =3D=3D 0. > = > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- = Kirill A. Shutemov _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=ham 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 E92E5C4338F for ; Thu, 12 Aug 2021 10:07:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 94E1C60FC4 for ; Thu, 12 Aug 2021 10:07:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 94E1C60FC4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3A90F6E057; Thu, 12 Aug 2021 10:07:15 +0000 (UTC) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by gabe.freedesktop.org (Postfix) with ESMTPS id C0A436E057 for ; Thu, 12 Aug 2021 10:07:13 +0000 (UTC) Received: by mail-lj1-x234.google.com with SMTP id h11so9740194ljo.12 for ; Thu, 12 Aug 2021 03:07:13 -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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=i5pl2dc+IIZq62s73J165t7SbTE/a6uwhQcs74jwe9KmwHHHprhV6B7adGgzY2ul5F h3ad9IJiBKNdQ1Yy+0atN7ISXCxsrMGXnfmJsO6X4rAencCuDMvqer1gR8DISUT+MUdX mFWLcuQYXLFjOzlL0+b+7kJuGkuB4wCN/YMkw/r+eyS6zgywYe+L6amtdlG3N+EOpGsE J1HMLNEKBn3QeV3/WPSCpmI5s5ySDG9/4fJ+UJO1H5Xch03iP3WdOduEdYUt1pTqbuK7 XsqkYhAszn/r202BsWcaBlPgkZHQ5nFUcQEBqetJcuzusrxc9TEefXgeJD4qBlDR12PM /RWw== 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=MYArfwyoBo3dGsKUJMsxwhHgYqZKbCcsgh7gGUNtDK4=; b=m13GpyPogIH5EnP5ma1gl8OHevJSI82TuRBVqBPenknqlb3I42teFtRrUyTK2maXbb LzEx5gHtsQZKbAU/dGkC/aZjVoCaLDgJ/AbGY0IBVdpQ5XYGhiAJtEdoIviCn73TXjN3 inbN+7Bmw2XaE2UnGh06IX01BwesNaIqAhaFUiSrP2G3VnPngE8aa98eW8Ri2E9k1LuW cI0iD0jxl50JV7VB4m977BkK+ysWeDyUAy1ogRB4JF05sBrYj0kYttx9csSV+jk1OBnR BEInBfEfs+QZ0cMBatns0zN5MJtdzvZpl48cBq/fQlnDk3uj6WtasVp5f/EWPuKVxS1S bmqQ== X-Gm-Message-State: AOAM532pMePwigNUYa0PDh2HkgZM6Ntqc3RkZ2N57nnqhqsOjv3QgJN8 QMyXPAHogGju5cLn9wB4i5RCxQ== X-Google-Smtp-Source: ABdhPJzegmFCE5odxbsD4HArsZ9uuMjN7H8TkJnoN55vikWCUHEpo/5436B3LFAXNhCNvYbyx3Wtvw== X-Received: by 2002:a2e:814a:: with SMTP id t10mr2410500ljg.318.1628762831975; Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o8sm212528lfo.292.2021.08.12.03.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Aug 2021 03:07:11 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id B75B41028BC; Thu, 12 Aug 2021 13:07:24 +0300 (+03) Date: Thu, 12 Aug 2021 13:07:24 +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: <20210812100724.t4cdh7xbkuqgnsc3@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> <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > 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. > > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > 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. > > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- Kirill A. Shutemov From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mE7cH-009brJ-WB for kexec@lists.infradead.org; Thu, 12 Aug 2021 10:07:15 +0000 Received: by mail-lj1-x22f.google.com with SMTP id n6so9735465ljp.9 for ; Thu, 12 Aug 2021 03:07:13 -0700 (PDT) Date: Thu, 12 Aug 2021 13:07:24 +0300 From: "Kirill A. Shutemov" Subject: Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has() Message-ID: <20210812100724.t4cdh7xbkuqgnsc3@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> <20210811121917.ghxi7g4mctuybhbk@box.shutemov.name> <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a819549-e481-c004-7da8-82ba427b13ce@amd.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org 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 On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote: > On 8/11/21 7:19 AM, Kirill A. Shutemov wrote: > > 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 @@ > >>>> =A0 #include > >>>> =A0 #include > >>>> =A0 #include > >>>> -#include > >>>> +#include > >>>> =A0 #include > >>>> =A0 =A0 #include > >>>> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long > >>>> physaddr, > >>>> =A0=A0=A0=A0=A0=A0 * there is no need to zero it after changing the = memory encryption > >>>> =A0=A0=A0=A0=A0=A0 * attribute. > >>>> =A0=A0=A0=A0=A0=A0 */ > >>>> -=A0=A0=A0 if (mem_encrypt_active()) { > >>>> +=A0=A0=A0 if (prot_guest_has(PATTR_MEM_ENCRYPT)) { > >>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 vaddr =3D (unsigned long)__start_bss_dec= rypted; > >>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 vaddr_end =3D (unsigned long)__end_bss_d= ecrypted; > >>> > >>> > >>> Since this change is specific to AMD, can you replace PATTR_MEM_ENCRY= PT with > >>> prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not use= d 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 ri= ght > > for your case, I donno. > = > Hmm... yeah, could be that the compiler is using rip-relative addressing > for it because it lives in the .data section? I guess. It has to be fixed. It may break with complier upgrade or any random change around the code. BTW, does it work with clang for you? > For the static variables in mem_encrypt_identity.c I did an assembler rip > relative LEA, but probably could have passed physaddr to sme_enable() and > used a fixup_pointer() style function, instead. Sounds like a plan. > > A separate point is that TDX version of prot_guest_has() relies on > > cpu_feature_enabled() which is not ready at this point. > = > Does TDX have to do anything special to make memory able to be shared with > the hypervisor? Yes. But there's nothing that required any changes in early boot. It handled in ioremap/set_memory. > You might have to use something that is available earlier > than cpu_feature_enabled() in that case (should you eventually support > kvmclock). Maybe. > > 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 =3D=3D 0. > = > For SNP, we'll have to additionally call the HV to update the RMP to make > the memory shared. But that could also be done unconditionally since the > early_snp_set_memory_shared() routine will check for SNP before doing > anything. -- = Kirill A. Shutemov _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec