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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1480C433EF for ; Sat, 9 Apr 2022 19:40:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87B56B0071; Sat, 9 Apr 2022 15:40:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0E746B0073; Sat, 9 Apr 2022 15:40:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C61EE6B0074; Sat, 9 Apr 2022 15:40:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id B00F36B0071 for ; Sat, 9 Apr 2022 15:40:09 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 823A860A6A for ; Sat, 9 Apr 2022 19:40:09 +0000 (UTC) X-FDA: 79338356538.05.7F50C45 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf04.hostedemail.com (Postfix) with ESMTP id 1DFEB40005 for ; Sat, 9 Apr 2022 19:40:08 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id o16so9592412ljp.3 for ; Sat, 09 Apr 2022 12:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=LRK5NCYhQ3Fmmdu1Nq/r6lgNA/het1WCzf4tV6aXNNc=; b=rlKEJbZpAwy8y3TZiwpi3c3SwsbVjgoFxEqjcACdj/mOh4cfZri7DmsaMJPvpV0cio QpRL1BHjj6CXRt2yW94jjtWHvG5uoCoPWnaiixTb9kDlKgeglHpMB9P8jPSj0116hqSH zjZVGR5j13019vnHrS7oOeLOdeD6WLovtUdXUPySrb8s5/iL987igaUaowCX+zP/zIv6 FUR4e5T+qm5tWF5RBKW+oJ2DEx6sCpGc6NGkbS+fXWfFWa8XfZKPI+wCRUcObFmUwmE6 4ikdDMOUmMnap6wChuC1gmROJhGeiJ1MT3Jf26uaPPYu6X+hhPKsO7ECxfO8PC16iBXT mFRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LRK5NCYhQ3Fmmdu1Nq/r6lgNA/het1WCzf4tV6aXNNc=; b=IyfS5aaoUwLa1ICFDy1k+Y2jptbDsWMrwC0jaRcGb+5eCI8UpAsDYbheCm9T/aAdme QIXVYQv2DY9Qyo2we9LhbcLFgfckS3H2j0o/QaJu26s4Qj7b6DxSVXJTf//OokkhUCWP XT1JAh0BBHDxRpfSb0wk7AGfALoCILc4zk+W+6kPCNevFr5iwsPecMX/CW7Kc3WZb6RB DUik7EbepjMy7W+InPebTnwJFTjU9YwPyfXjwtUn97DBkPJUa7Egc1dN+vC6/G93J1vZ QtnaYa0VxiZaybAkwdi53s0F+LYPaIchNcbBGbXlH3wwhKiyZAkVMgmz0DfrjFCRVrP2 kU/w== X-Gm-Message-State: AOAM530/yGNft+Tjjk03EnOzO9xD68EJbHL4ZatyjB8hK2r7r2VKNGFX +SusgO+VchKE32hSUtTu827OCw== X-Google-Smtp-Source: ABdhPJxeKGBViGlrj5LsAbQbGRDtUjUXzGUPQv/lXHzeqUlJMXodiQjFo1rWxw8q5suEmdOPa+PGVw== X-Received: by 2002:a05:651c:1a21:b0:249:8ccf:65eb with SMTP id by33-20020a05651c1a2100b002498ccf65ebmr16035500ljb.166.1649533206875; Sat, 09 Apr 2022 12:40:06 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id i23-20020a198c57000000b0045dcb4816d3sm1621742lfj.35.2022.04.09.12.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Apr 2022 12:40:05 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 0C2EA1039DB; Sat, 9 Apr 2022 22:41:37 +0300 (+03) Date: Sat, 9 Apr 2022 22:41:37 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory Message-ID: <20220409194137.yui73qnno5bd45xn@box.shutemov.name> References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-4-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1DFEB40005 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=rlKEJbZp; dmarc=none; spf=none (imf04.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.180) smtp.mailfrom=kirill@shutemov.name X-Stat-Signature: butqogyzwsfk7jzcddbjjb6ayr64h3rj X-HE-Tag: 1649533208-824591 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 Fri, Apr 08, 2022 at 10:26:14AM -0700, Dave Hansen wrote: > On 4/5/22 16:43, Kirill A. Shutemov wrote: > > +void mark_unaccepted(struct boot_params *params, u64 start, u64 end) > > +{ > > + /* > > + * The accepted memory bitmap only works at PMD_SIZE granularity. > > + * If a request comes in to mark memory as unaccepted which is not > > + * PMD_SIZE-aligned, simply accept the memory now since it can not be > > + * *marked* as unaccepted. > > + */ > > + > > + /* > > + * Accept small regions that might not be able to be represented > > + * in the bitmap: > > + */ > > + if (end - start < 2 * PMD_SIZE) { > > + __accept_memory(start, end); > > + return; > > + } > > This is not my first time looking at this code and I still had to think > about this a bit. That's not good. That pathological case here is > actually something like this: > > | 4k | 2044k + 2044k | 4k | > ^ 0x0 ^ 2MB ^ 4MB > > Where we have a 2MB-aligned 4k accepted area, a 4088k unaccepted area, > then another 4k accepted area. That will not result in any bits being > set in the accepted memory bitmap because no 2MB region is fully accepted. > > The one oddball case is this: > > | 4k | 2044k | 2048k | > ^ 0x0 ^ 2MB ^ 4MB > > Which would fall into the if() above, but *can* have part of its range > marked in the bitmap. > > Maybe we need something more like this: > > /* > * Accept small regions that might not be able to be represented > * in the bitmap. This is a bit imprecise and may accept some > * areas that could have been represented in the bitmap instead. > * But, the imprecision makes the code simpler by ensuring that > * at least one bit will be set int the bitmap below. > */ Okay, will change. > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > > index 2c3dac5ecb36..b17ceec757d0 100644 > > --- a/drivers/firmware/efi/Kconfig > > +++ b/drivers/firmware/efi/Kconfig > > @@ -243,6 +243,21 @@ config EFI_DISABLE_PCI_DMA > > options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" > > may be used to override this option. > > > > +config UNACCEPTED_MEMORY > > + bool > > + depends on EFI_STUB > > + depends on !KEXEC_CORE > > The changelog should probably say something about how the kexec() > incompatibility is going to be rectified in the future. Okay. > > + help > > + Some Virtual Machine platforms, such as Intel TDX, require > > + some memory to be "accepted" by the guest before it can be used. > > + This mechanism helps prevent malicious hosts from making changes > > + to guest memory. > > + > > + UEFI specification v2.9 introduced EFI_UNACCEPTED_MEMORY memory type. > > + > > + This option adds support for unaccepted memory and makes such memory > > + usable by kernel. > > + > > endmenu > > BTW, what happens if this is compiled out? Do TDX guests just lose all > the unaccepted memory? No. It will not have access to unaccepted memory and will only use memory accepted by BIOS. > Should TDX be selecting this or something? Yes, it should and we do this. > > @@ -504,6 +506,13 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s > > e820_type = E820_TYPE_PMEM; > > break; > > > > + case EFI_UNACCEPTED_MEMORY: > > + if (!IS_ENABLED(CONFIG_UNACCEPTED_MEMORY)) > > + continue; > > This seems worthy of a pr_info(). We're effectively throwing away > memory with this "continue", right? Yes. In this case we threat unaccepted as reserved and inaccessible to kernel. Maybe pr_warn() is more appropriate. -- Kirill A. Shutemov