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 E4E6EC43334 for ; Mon, 18 Jul 2022 23:32:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4320D6B0071; Mon, 18 Jul 2022 19:32:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E26C8E0001; Mon, 18 Jul 2022 19:32:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A97B6B0074; Mon, 18 Jul 2022 19:32:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1B50B6B0071 for ; Mon, 18 Jul 2022 19:32:30 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E321534BF2 for ; Mon, 18 Jul 2022 23:32:29 +0000 (UTC) X-FDA: 79701822018.09.97BB3B1 Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf09.hostedemail.com (Postfix) with ESMTP id 88853140092 for ; Mon, 18 Jul 2022 23:32:29 +0000 (UTC) Received: by mail-yb1-f180.google.com with SMTP id 75so23711766ybf.4 for ; Mon, 18 Jul 2022 16:32:29 -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=hfhcfJEtIEOv5/RbP8aWxiUol5MH91cRjA0pRO3p2Do=; b=E8GPGArYRequLjAGkGzJuo7mmPtrq2YvlPe8RRaQ8b8rHsTNcJ8RfueX4LgVDgm4aB iO9UmGQn2mkxNk75LsxjucgwIuj7WI7+50bQj4vRV7NWIgEJ25kU4RkKRLX/qW9+H+td SuNhtFNytaFKBe644W3MoZryHUqLCIcz8SW/Qqq/KlVak4gkMqO7GM9zsRXI2zoVgdTJ qc9r/Whf+qyeEeohUc+mvkoClakUllk5GMENmp9gPNkIv8k/q3mimTiabzRrUIC6nY4i ri43dSa+JABF0B+eibe17SQ0ixXgj6uuTesCdN0QN+7Ncsv70PQvaX9oxjrYuglZQD25 Q/og== 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=hfhcfJEtIEOv5/RbP8aWxiUol5MH91cRjA0pRO3p2Do=; b=OuMTR220Q5MMbbCWXr9zhOWA0XsbhkQbGEQKqEOZvDpXJ0Wn5ziYOknT/ToLqsdQAm RpTdKTPNJ+A9hckGFWxYONeQl+seTHINtmZc1Kd0CuPYeCu5l3bAo0G4uXZDPs2S6LzB I45eCCwx+kZrHmx/xQgnQbCArBbVu5EdGw4ITZjMRjaovdQI2rRMP6qYQs9KcN4mVHMC 0lp9PjFb3l5tGonMOuZfkhhiS3B0h/7oqXdk57lIndQcOZGD0yyjj7sdqsgzSIuPIOBG mctAEfXLBOKrJ246viQQf/GuQeRVk8IwSgIazF0gCxqpjDfAiwjKEH4ufgNGSSHNbEAa FJew== X-Gm-Message-State: AJIora88vUJKIHFgffJd0JcU98ANGSI2Ywg6OrHYvJvxXkTzKvckNlJQ 3pgrEEktN7XpBQCMOyg5/lrHT3kJYsS5SJrSZ48gmQ== X-Google-Smtp-Source: AGRyM1uDqGJkW/LK2CJC2GR49ze3EpqjvilYu7i365psCPTzr/cZIWgOxjMR3E5AbePYdQJr4Xq1laFNiwWUOrzg3oE= X-Received: by 2002:a25:3b95:0:b0:66e:316c:159 with SMTP id i143-20020a253b95000000b0066e316c0159mr30295992yba.297.1658187148646; Mon, 18 Jul 2022 16:32:28 -0700 (PDT) MIME-Version: 1.0 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220627113019.3q62luiay7izhehr@black.fi.intel.com> <20220627122230.7eetepoufd5w3lxd@black.fi.intel.com> <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> In-Reply-To: <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> From: Dionna Amalie Glaze Date: Mon, 18 Jul 2022 16:32:17 -0700 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: "Kirill A. Shutemov" Cc: Ard Biesheuvel , Peter Gonda , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, "the arch/x86 maintainers" , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , "Yao, Jiewen" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658187149; a=rsa-sha256; cv=none; b=w2i/UdbWxikQTb+wsbtMEjBHx4IkDwfADisXI0KZXxDcncQU8AjhqokF4sELkcus4A5LZ4 h2vM2C2k+SilgNOainhEWMvxgysg0U2ceOffX/jxGj6TVAcwVp9egJxj7zb9viVK1aCgn0 XU2DHLuiwoH/uqxqa80HIhvE2moRpFI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=E8GPGArY; spf=pass (imf09.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658187149; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hfhcfJEtIEOv5/RbP8aWxiUol5MH91cRjA0pRO3p2Do=; b=XyvrYjUYO2WMFFoAdZXLdGFFRbgS4mhcYlm6wHgTOeB+/tFwB7rpS9JdUZoqODozGkmuA/ zQRRFBotgvDjnnKmihfxJyzAIHFxHPaSw2jZotU2I723FFTKs46x8VzaPMzZjLr32lfrcc zYIiAiWsJgihY+kN+1SVGN8u0fTYRsQ= X-Rspamd-Queue-Id: 88853140092 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=E8GPGArY; spf=pass (imf09.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: mghb8zy6xp5mmx79aqixwrwiycfu7d3x X-HE-Tag: 1658187149-320170 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: > I've talked with our firmware expert today and I think we have a problem > with the approach when kernel declaries support of unaccepted memory. > Is this Jiewen Yao? I've been trying to design the UEFI spec change with him. The bootloader problem he commented with this morning was something I wasn't fully considering. > This apporach doesn't work if we include bootloader into the picture: if > EBS() called by bootloader we still cannot know if target kernel supports > unaccepted memory and we return to the square 1. > > I think we should make it obvious from a kernel image if it supports > unaccepted memory (with UTS_VERSION or other way). > > Any comments? Is this binary parsing trick already used in EDK2? If not, I wouldn't want to introduce an ABI-solidifying requirement like that. A bit more cumbersome, but more flexible way to enable the feature is an idea I had in a meeting today: Make unaccepted memory support a feature-enabling EFI driver installed to the EFI system partition. * The first time you boot (setup mode), you install an EFI driver that just sets a feature Pcd to true (using a custom protocol as Ard had suggested above). * The second time you boot, if the feature Pcd is true, then the UEFI is free to not accept memory and use the unaccepted memory type. The bootloader will run after unaccepted memory has been allowed already, so there is no accept-all event. The default behavior will be to accept all memory when GetMemoryMap is called unless the feature pcd is set to true. We can then say this driver isn't needed once some new generation of this technology comes along and we can require unaccepted memory support as part of that technology's baseline, or we manage to update the UEFI spec to have GetMemoryMapEx which has unaccepted memory support baked in and the bootloaders all know to use it. The cloud experience will be, "is boot slow? Install this EFI driver from the cloud service provider" to tell the UEFI to enable unaccepted memory. -- -Dionna Glaze, PhD (she/her)