From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7147C2562 for ; Tue, 31 May 2022 22:40:26 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id f34so13305651ybj.6 for ; Tue, 31 May 2022 15:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iSXfdXWQRyUCbk0G9o7KyBhlDTpNCnQev8nhR/I/TdY=; b=HsksBcqdyPpSCCWP1DiXPiE1a14eVxR7MRHdI7Z5cpzZAy9lO7ruMphxUv9jF2C2sw /pgCZCCeJVk9cxgvTdmK1FsevcWFWH/+i8JgrsxFWUScnpMihGH6PE+aKcXA03iPeJdj dZ4Fy8JMSO77H9VgxNZVjTS2CE7+rjPwOQ1nkywPuJ4OjM7zlIgYglNeD5R5RdHU9TQd ZGEbQvqw79MCww+sZgynuaRCvhUuCusnjWfYIg9yFNCv09hwSDywXkSSafnIp55ACSaP 7kfB7e7yTdJwIGcs5EiZYEHjSftx3J+hMbbAJxZGkLLhtDcVt5vIiRiCUs6uyPTV7LFu JzIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iSXfdXWQRyUCbk0G9o7KyBhlDTpNCnQev8nhR/I/TdY=; b=YlNctJGSaNs1xm9VL7/MALRe5nB+6Mne32wA7yHuH1MC1yR5VSI6AVRsC5RMCrZqw/ YXs3eSHpsmfw8sdOhr48w++Db6dVEWxZii3THxy3awII1Mf5KZyLoCncm3RU/2VE1Kw7 RRleOECmzhqKB3O79enpDvAUXiScLSk6xtxoKNhCIGCWF+UHNOlmfgG5wdju1yQaJoSz 8p/qdD8G43VHmn93Ku8pjwKBZzM936oViZ5cdzTkULLvrIfsn8+DIg+uSCQ33NsCfu2/ D+WT5Bx1IgcTM0SmLgnhykFyLUrhnJyGrMgeuh258FxDe4acTqmnDwUtlqmfAlqj74ey dD2w== X-Gm-Message-State: AOAM533hDF9qoIzSoj89diM9l711Ha8WbuGf5Cd+NIEuGwxAg78g6Hb4 xU4IofaTIKec4sFhjyQydmCR2xyLAKY8gLZ9uFfFeQ== X-Google-Smtp-Source: ABdhPJzmrJqSRhhHz6N0GieGJg5FYLwCAVR0BwL5OtlM2bEaoCxd7rSGbpFZm9hJ3VmDFMNfIbaxRaCkI7t+1HHGplQ= X-Received: by 2002:a5b:411:0:b0:65c:d336:ddf7 with SMTP id m17-20020a5b0411000000b0065cd336ddf7mr13814723ybp.321.1654036825375; Tue, 31 May 2022 15:40:25 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220425033934.68551-1-kirill.shutemov@linux.intel.com> <20220425033934.68551-7-kirill.shutemov@linux.intel.com> <20220506153013.e6v4q2qhuhqumfiu@box.shutemov.name> <20220513144515.fx2cvo3rjued3vy5@black.fi.intel.com> In-Reply-To: From: Dionna Amalie Glaze Date: Tue, 31 May 2022 15:40:14 -0700 Message-ID: Subject: Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory To: "Xu, Min M" Cc: "Kirill A. Shutemov" , Borislav Petkov , "Gao, Jiaqi" , Michael Roth , Borislav Petkov , "Kirill A. Shutemov" , "Lutomirski, Andy" , "Christopherson,, Sean" , Andrew Morton , "Rodel, Jorg" , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , "Hansen, Dave" , 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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi y'all, I've made minimal changes to OVMF to prevalidate only up to 4GB and leave the rest unaccepted, as Thomas Lendacky recommended https://github.com/AMDESE/ovmf/pull/4#issuecomment-1138606275 and ran a memtouch test to see if this change behaves as expected. One thing that struck me is that an 8GB machine reports 2044MB free with this change (free -k) whereas without it, I see 7089MB free. I think that unaccepted memory should be classified as free in meminfo, no? I'm not familiar enough with that code to say what specific change needs to be made. (resent in text mode) On Sun, May 15, 2022 at 11:47 PM Xu, Min M wrote: > > On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote: > > On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote: > > > + mroth > > > - brijesh > > > > > > On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote: > > > > Kirill, I've been tracking these changes to see if we can handle th= e > > > > unaccepted memory type for SEV-SNP, but testing has been an issue. > > > > The proposed patch in Ovmf to introduce unaccepted memory seems to > > > > have stalled out last September > > > > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html) > > > > and is particularly difficult to adapt to SEV-SNP since it doesn't > > > > follow the TDVF way of initializing all memory. Is there a differen= t > > > > development I might have missed so that we might test these cases? > > > > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any > > kernel > > > > uses are essentially dead code. > > > > + Min, Jiaqi. > > > > I don't follow firmware development. Min, Jiaqi, could you comment? > > > We have prepared the patch for unaccepted memory and it is now working in= our internal release. > But there is an obstacle to upstream it to edk2 master branch. > The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTE= D in PI spec. This is proposed in https://github.com/microsoft/mu_basecore/= pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb66= 3d80c9e4R237, according to UEFI-Code-First. The proposal was approved in 20= 21 in UEFI Mantis, and will be added to the new PI.next specification. (Til= l now it has not been added in the latest PI spec.) > So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make i= t difficult to submit the patch to edk2 community for review. See this link= : https://edk2.groups.io/g/devel/message/87558 > > Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is = different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec) > > I will submit the patch-set once the new definition is added in the new P= I.next spec. > > Thanks > Min --=20 -Dionna Glaze, PhD (she/her)