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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DC056C4338F for ; Mon, 26 Jul 2021 19:13:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5324F60F91 for ; Mon, 26 Jul 2021 19:13:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5324F60F91 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id ABA246B0033; Mon, 26 Jul 2021 15:13:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6A016B0036; Mon, 26 Jul 2021 15:13:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 959B18D0001; Mon, 26 Jul 2021 15:13:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id 77F2F6B0033 for ; Mon, 26 Jul 2021 15:13:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 24B93181F0FEA for ; Mon, 26 Jul 2021 19:13:20 +0000 (UTC) X-FDA: 78405687360.25.F2CA563 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by imf14.hostedemail.com (Postfix) with ESMTP id A1E8460022C4 for ; Mon, 26 Jul 2021 19:13:19 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 5701E296; Mon, 26 Jul 2021 21:13:18 +0200 (CEST) Date: Mon, 26 Jul 2021 21:13:17 +0200 From: Joerg Roedel To: "Kirill A. Shutemov" 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: References: <20210722195130.beazbb5blvj3mruo@box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20210722195130.beazbb5blvj3mruo@box> Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of joro@8bytes.org designates 81.169.241.247 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (policy=none) header.from=8bytes.org X-Rspamd-Server: rspam02 X-Stat-Signature: bayuz795db6nqarzzfcar7pcjezxp6wk X-Rspamd-Queue-Id: A1E8460022C4 X-HE-Tag: 1627326799-34988 Content-Transfer-Encoding: quoted-printable 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: Hi Kirill, On Thu, Jul 22, 2021 at 10:51:30PM +0300, Kirill A. Shutemov wrote: > Okay, below is my first take on the topic. Thanks, I havn't looked deeply into the patch yet, but will do so tomorrow and reply separatly. > I ended up combing your idea with bitmap with PageOffline(): early boot > code uses bitmap, but on page allocator init I mark unaccepted pages wi= th > PageOffline(). This way page allocator need to touch the bitmap only wh= en > it steps on PageOffline() which shouldn't be often once things settle > after boot. I still need to understand the benefit of having this information in the memmap, but I also don't object to it. For AMD-SNP the bitmap needs to stay around at least, unless there is another way to implement kexec/kdump. > One bit in the bitmap represents 2M region. Any unaligned chunks gets > accepted when we construct the bitmap. This way one 4K page can represe= nt > 64 GiB of physical address space. Yeah, a 2MB chunk size makes sense when it comes to how much we validate at once. I think it will be good choice for AMD too. On the other side there is a need for SNP to track shared pages on a 4k granularity. There are a couple of shared (or at least not valid) pages (GHCB, #HV shared pa= ge, VMSA page) per vCPU which are 4k in size. Oh, and then there is the .bss_decrypted section, which is also not 2M aligend. In case of kexec/kdump this information needs to be passed on to the next kernel. Regards, J=F6rg