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 5BD4FC433EF for ; Tue, 31 May 2022 22:37:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2D3D6B0072; Tue, 31 May 2022 18:37:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB3DC6B0073; Tue, 31 May 2022 18:37:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C761A6B0074; Tue, 31 May 2022 18:37:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B297E6B0072 for ; Tue, 31 May 2022 18:37:38 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8B4D62074D for ; Tue, 31 May 2022 22:37:38 +0000 (UTC) X-FDA: 79527501396.28.158DECA Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf23.hostedemail.com (Postfix) with ESMTP id 06B5814005E for ; Tue, 31 May 2022 22:37:12 +0000 (UTC) Received: by mail-yb1-f182.google.com with SMTP id g4so12703508ybf.12 for ; Tue, 31 May 2022 15:37:37 -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; bh=FfNxPSwvvtl6wehB3Oyl3yDc8V6txCK/zNgYUwA1YSo=; b=R5dq7MaUknJ2ZTVy6mIG7+asmORf6TLS2cfW0HWXF3n0C6QNtmHBczRqf7Mt97PxT7 Q7kARROr7a4JF1KDOQ7doACug2MgSQUmRlgdFGUXoOzdoW/lS2PxVmqzuMgqlhgYsNbx hD8a5fxHO0E2z9vOURFKlA8uNbGrpBA5SxIcoJ0tYvZW+d3Pkc/e03PL/63NW6CxVO5N FMdZAKBpWxfOUNq0AGIFaRQYxPynm9AG5QJwef+s09rWUcKDKhkZgDY6ZYolno0Q6sz0 1oyTgXyhmBxn2h5+KiKFtoKDqhOVwsxpcs/wJ9vFRetw2vgUiZP0uFRYSQgMfpJS9Lcp FDbA== 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; bh=FfNxPSwvvtl6wehB3Oyl3yDc8V6txCK/zNgYUwA1YSo=; b=trRRUIExX2pascnMgeu/HkVQqpo2J3/tdg4zNT7X/EBKh5M/x28kTqkkCvRKZiEkPf LuZn0eceTRDXixvqgnO/aYKMp3IH0dIlvHNY+UwnvvhoV4mCwnAIq6UXkwnIxRyH4/+Q K5c2kuUkjwoh+MT1ncK6/XUK+lE9RAfl+cH4o5N4/7Sx7CC9jOKCn0CkCIaCPlgIKLAR ZfM5HP1d0Mf/9v59ijphy7oiHlhvVVVtq67RsMyQigMsvBzTsm/Iq935w+h9FV7GLYkf 4VTG3knBPqadqc3x870JUxajiYM83vbqtQuzXbwBkDxWfAcgATZbTQWwendKC6RLXvgO K/Ng== X-Gm-Message-State: AOAM531w5/RX7jZDEnc+c2wHuq1C7nOam3Nn8EqfbnqxjQK1qRE1bw1w NQEM/PUrsSjlmChm2HeRm9li1htVW6tg6W5vR2mn3g== X-Google-Smtp-Source: ABdhPJxIZX2tHOLtiCNEvzfRdU48w3GEN7bVS0nw/vFiayackNye8PqvTucE7Fu+4cFfws1HXx3azxwmStB4OeTWFWU= X-Received: by 2002:a5b:411:0:b0:65c:d336:ddf7 with SMTP id m17-20020a5b0411000000b0065cd336ddf7mr13804236ybp.321.1654036657175; Tue, 31 May 2022 15:37:37 -0700 (PDT) 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:37:26 -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: multipart/alternative; boundary="00000000000065fbd805e0566b58" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 06B5814005E X-Stat-Signature: tzcgp7ifhc5iomgmwzihp6ckjdj4431k X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=R5dq7MaU; spf=pass (imf23.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1654036632-665127 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: --00000000000065fbd805e0566b58 Content-Type: text/plain; charset="UTF-8" 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. 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 the > > > > 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 different > > > > 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_UNACCEPTED > in PI spec. This is proposed in > https://github.com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237, > according to UEFI-Code-First. The proposal was approved in 2021 in UEFI > Mantis, and will be added to the new PI.next specification. (Till now it > has not been added in the latest PI spec.) > So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it > 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 > PI.next spec. > > Thanks > Min > -- -Dionna Glaze, PhD (she/her) --00000000000065fbd805e0566b58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi y'all, I've made minimal changes to OVMF to pre= validate only up to 4GB and leave the rest unaccepted, as Thomas Lendacky r= ecommended=C2=A0https://github.com/AMDESE/ovmf/pull/4#issuecomment-113860627= 5 and ran a memtouch=C2=A0test to see if this change behaves as expecte= d. 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= .

On Sun, May 15, 2022 at 11:47 PM Xu, Min M <min.m.xu@intel.com> wrote:
On May 13, 2022 10:45 PM, Kirill A. Shutemov w= rote:
> 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 wro= te:
> > > Kirill, I've been tracking these changes to see if we ca= n handle the
> > > unaccepted memory type for SEV-SNP, but testing has been an = issue.
> > > The proposed patch in Ovmf to introduce unaccepted memory se= ems to
> > > have stalled out last September
> > > (https://www.mail-arch= ive.com/devel@edk2.groups.io/msg35842.html)
> > > and is particularly difficult to adapt to SEV-SNP since it d= oesn't
> > > follow the TDVF way of initializing all memory. Is there a d= ifferent
> > > 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 o= ur 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_UNACCEPTED = in PI spec. This is proposed in https://github.= com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4b= af52069efadf2e2546cdd2eb663d80c9e4R237, according to UEFI-Code-First. T= he proposal was approved in 2021 in UEFI Mantis, and will be added to the n= ew PI.next specification. (Till now it has not been added in the latest PI = spec.)
So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it = 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 di= fferent from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)

I will submit the patch-set once the new definition is added in the new PI.= next spec.

Thanks
Min


--
-Dionna Glaze, PhD (she/her)
--00000000000065fbd805e0566b58--