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 CF010C4338F for ; Fri, 23 Jul 2021 16:30:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7DFD560F47 for ; Fri, 23 Jul 2021 16:30:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7DFD560F47 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1BE276B0033; Fri, 23 Jul 2021 12:30:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16E266B005D; Fri, 23 Jul 2021 12:30:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05BE66B006C; Fri, 23 Jul 2021 12:30:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id DCE0E6B0033 for ; Fri, 23 Jul 2021 12:30:03 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 91028253A5 for ; Fri, 23 Jul 2021 16:30:03 +0000 (UTC) X-FDA: 78394389486.10.90E5390 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf18.hostedemail.com (Postfix) with ESMTP id 2BBCF40073D7 for ; Fri, 23 Jul 2021 16:30:03 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id u20so2076447ljo.0 for ; Fri, 23 Jul 2021 09:30:02 -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:in-reply-to; bh=dXQgyTXJsqiah7vHpQmXpgPxUDEXb2uiJiep4QJ23GQ=; b=fKvXt5EiWqrOM4ls4tg4E264uTkSLdtg6RCvpgx2joforvO5ArfN9sc7HzfS8GABBe qVFyxqGz+c2TYD5HUlr0YMrRmNA4PLtfKDkJUKBSS0usMGmYUj0Yikz96tH/gXFFfydc 9WoAp3LoLTkxdNiykxoo4XLwpEgczpRA9qmA/jEb6ephHmvAJexsubxMOMC5i/eBRifL Nf1qDeCvoXJ69FYOq397Fs5rgJzKnrDnO2p4qtJMIa7Apc4WAb8SORdQSfeqwrA9L7ZO w5wNOq/A5ovAaR+lv1TplBXbQUIQOO8c1tJmddSFv/zzSwnDFhHI88C5R1ppVUGjLc3B qykw== 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:in-reply-to; bh=dXQgyTXJsqiah7vHpQmXpgPxUDEXb2uiJiep4QJ23GQ=; b=mcJHZcojpfRCqzGCgcSZEvpKJDXOssqtLKar8v44UdEeNgr/J3IaqgamjebJNHEZOA zoFcAQ1081EEzFsUAcvaINwk9IL32eN4n7i417v8sYkYWtEqm8GJ33ycUiVa0mZgYND6 pHLu8psqeyaG37rJu4+iiwLcoGPLtMRLpR4SICgS+9KDZBlP2DhyrdrXzXmkfJwoPZ5I hjCYZ8tFXFy68VomuB/EeTyF2l1+nxsBoKArY9WR1DdR4ecLnp2azPQeadlsRWreHF2b sAY/VWcoNcf2sp+XJOfvA3PPPs09xuxY4q1munysvXvXs+oFL033mfEzp3l2/KSG5hSi uhFg== X-Gm-Message-State: AOAM531yWYdVZ029mqyHl4aBizLE++GHEXK8/sCc0p/BfSEtZgnoAwjp M8FOkPQyfDAZFQWUM86Rupx2Ww== X-Google-Smtp-Source: ABdhPJwXWjxpnHRaY6MSBF6ZTckUkjUMR2LBd7leUi+mMN/8sp7OzVCGASWzq26PrJUwd5Mkg1SI6w== X-Received: by 2002:a2e:3c0d:: with SMTP id j13mr3836053lja.414.1627057801304; Fri, 23 Jul 2021 09:30:01 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id m25sm2286194lfq.209.2021.07.23.09.30.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jul 2021 09:30:00 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 292B4102674; Fri, 23 Jul 2021 19:29:59 +0300 (+03) Date: Fri, 23 Jul 2021 19:29:59 +0300 From: "Kirill A. Shutemov" To: Mike Rapoport Cc: Joerg Roedel , Andi Kleen , David Rientjes , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <20210723162959.uczshxmj2izxocw3@box.shutemov.name> References: <20210722195130.beazbb5blvj3mruo@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=fKvXt5Ei; spf=none (imf18.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.182) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2BBCF40073D7 X-Stat-Signature: j3a11bq3pc8x8n6q6ht5eyjw5idzjdzh X-HE-Tag: 1627057803-450948 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, Jul 23, 2021 at 06:23:39PM +0300, Mike Rapoport wrote: > > @@ -1318,9 +1327,14 @@ void __init e820__memblock_setup(void) > > if (entry->type == E820_TYPE_SOFT_RESERVED) > > memblock_reserve(entry->addr, entry->size); > > > > - if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN) > > + if (entry->type != E820_TYPE_RAM && > > + entry->type != E820_TYPE_RESERVED_KERN && > > + entry->type != E820_TYPE_UNACCEPTED) > > continue; > > If I understand correctly, you assume that > > * E820_TYPE_RAM and E820_TYPE_RESERVED_KERN regions are already accepted by > firmware/booloader > * E820_TYPE_UNACCEPTED would have been E820_SYSTEM_RAM if we'd disabled > encryption > > What happens with other types? Particularly E820_TYPE_ACPI and > E820_TYPE_NVS that may reside in memory and might have been accepted by > BIOS. Any accessible memory that not marked as UNACCEPTED has to be accepted before kernel gets control. > > > > + if (entry->type == E820_TYPE_UNACCEPTED) > > + mark_unaccepted(entry->addr, end); > > + > > memblock_add(entry->addr, entry->size); > > } > > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 72920af0b3c0..db9d1bcac9ed 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -944,6 +944,8 @@ void __init setup_arch(char **cmdline_p) > > if (movable_node_is_enabled()) > > memblock_set_bottom_up(true); > > #endif > > + /* TODO: make conditional */ > > + memblock_set_bottom_up(true); > > If memory is accepted during memblock allocations this should not really > matter. > Bottom up would be preferable if we'd like to reuse as much of already > accepted memory as possible before page allocator is up. One of the main reason for this feature is to speed up boot time and re-usinging preaccepted memory fits the goal. > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -814,6 +814,7 @@ int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size) > > memblock_dbg("%s: [%pa-%pa] %pS\n", __func__, > > &base, &end, (void *)_RET_IP_); > > > > + accept_pages(base, base + size); > > Hmm, I'm not sure memblock_reserve() is the right place to accept pages. It > can be called to reserve memory owned by firmware which not necessarily > would be encrypted. Besides, memblock_reserve() may be called for absent > memory, could be it'll confuse TDX/SEV? Such memory will not be marked as unaccepted and accept_pages() will do nothing. > Ideally, the call to accept_pages() should live in > memblock_alloc_range_nid(), but unfortunately there still stale > memblock_find_in_range() + memblock_reserve() pairs in x86 setup code. memblock_reserve() is the root of memory allocation in the early boot and it is natual place to do the trick. Unless we have a good reason to move it somewhere I would keep it here. -- Kirill A. Shutemov