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 9FEB7C433EF for ; Tue, 19 Jul 2022 18:29:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCB296B0071; Tue, 19 Jul 2022 14:29:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7BDA6B0073; Tue, 19 Jul 2022 14:29:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF5226B0074; Tue, 19 Jul 2022 14:29:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AF8686B0071 for ; Tue, 19 Jul 2022 14:29:45 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 720C5120300 for ; Tue, 19 Jul 2022 18:29:45 +0000 (UTC) X-FDA: 79704687930.30.A94C2DC Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf06.hostedemail.com (Postfix) with ESMTP id B3B6018005C for ; Tue, 19 Jul 2022 18:29:44 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-31d7db3e6e5so150085607b3.11 for ; Tue, 19 Jul 2022 11:29:44 -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=unVD5D8mS78cV9OKwyoa/aVTA3h/WCQeocLsIDcTU88=; b=rlMp77yoX+jT3kAt/7isGFNXeCnY0JRyS/SjLKC2TnslQLVrLpBU/diTiP/scVZ0nm q0bRaxcxP+Mw3rUeQJBRKBfqgUMpNSg3XvWlFlKvNVo1/RWzse/NtMZbHyTEyqasjVrE ZGBNQ1hsyidPWe5J3G/PRh3S45vmu9vyEYflq5nKzjNotlQ8A60EN+KadQHUJNKaMI5m RdH1zhZgjsxuejJO+HqHon93uFWcbZQH4s/hWG3Ziu2e73+SNwGoDAinIVeqRl2NiP6h ytUAXES0ePRtPCBE+XQbyBq5Yeg+Oos35Ho7JkeaArhRDyQ8KKTXOQ39iSfbw2ATJHZw t72w== 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=unVD5D8mS78cV9OKwyoa/aVTA3h/WCQeocLsIDcTU88=; b=7jJrQNgohvVAtuefut792BJwpWRyBY3NogJR1lx54dW+p/s3oBjl9IEgCYwTEuHN90 Byr91yEKwe9BlvGTkinJKp4CzdvptxGTPkfVaGHsfVgXVqKZj8k+6e9ZDLgrcP4hcRkm D7NSmnWEVGK2iEK85wE7ci/ze5MvvauIgxnhXr2AYcn8IrpHPbAChYFcArIcqPPM05wp 4JmO4/oJB1xnm79bQJ7Rg6CKmjwLu00FP1vpgfjfTUc+z5cqDzxMVrHBrG5B9uP2Tcow mvsRB5r/eot1QrkrEWhBQs1wawWurlT/hKxmtjvkjuIcAxXz8vf6M6A3S9q2fX4EzjL6 kCcQ== X-Gm-Message-State: AJIora/pffmiQX3nX0UWpKmh3T9a6AW7svltzY448+hpKHsFFVd6tVVU zxMIEdQnTCCzMVAdGtnOfqpu86Kn0qzKihJhpPqr0w== X-Google-Smtp-Source: AGRyM1sp8r4DKDqp+3bXLyIEl1rWuq4duyZZsvEEp5+awBcKu+U0NNFWJYr396qMNpgLQ2YVHwSleitEY6cw3zveH98= X-Received: by 2002:a81:a1ca:0:b0:31e:58d4:e724 with SMTP id y193-20020a81a1ca000000b0031e58d4e724mr5943209ywg.486.1658255383950; Tue, 19 Jul 2022 11:29:43 -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: From: Dionna Amalie Glaze Date: Tue, 19 Jul 2022 11:29:32 -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-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rlMp77yo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=dionnaglaze@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658255385; a=rsa-sha256; cv=none; b=PSKMNoAvmzmtp8bNYgV2lKAEnyeJSvfQW4SJIwf4+MG8bweLR1dMGpoP9JowuK8tre2UQO SmXpxP+Y7VKTTLp9fcm7Q7GUo85EQA2WxoahbFAEyfviwWpN9UaaFcL49lkyV6Lzq8nb7D y1UfmXhVygpQPyw+sxwke6C/mM8j/lA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658255385; 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=unVD5D8mS78cV9OKwyoa/aVTA3h/WCQeocLsIDcTU88=; b=d23Asy51Lrz7Xxzap9cbzS1dAxF358eu5qkmQSnS1nCXd3I8ZJCyEwR4ux8b1/mDUblyt1 wDbCusdwrxdrIiw5KEyVb0fKmaKv9zphJX8lsnlDa08NmkXOMi2tAw++06Lq3a92YaodVb w6atKMYy4Sk9Ek6NEgYVUN3vQW4fyek= X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B3B6018005C Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rlMp77yo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=dionnaglaze@google.com X-Stat-Signature: 6unbfzfnqhswuu9t4qh46gn3hr7w8o9y X-HE-Tag: 1658255384-148526 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 think we should make it obvious from a kernel image if it supports > > > unaccepted memory (with UTS_VERSION or other way). > > > > > Something I didn't address in my previous email: how would the UEFI > know where the kernel is to parse this UTS_VERSION out when it's > booting a bootloader before Linux gets booted? > How about instead of the limited resource of UTS_VERSION, we add a SETUP_BOOT_FEATURES enum for setup_data in the boot header? That would be easier to parse out and more extensible in the future. https://www.kernel.org/doc/html/latest/x86/boot.html?highlight=boot This can contain a bitmap of a number of features that we currently need manual tagging for, such as SEV guest support, SEV-SNP guest support, TDX guest support, and (CONFIG_UNACCEPTED_MEMORY, TDX) or (CONFIG_UNACCEPTED_MEMORY, SEV-SNP). The VMM, UEFI, or boot loader can read these from the images/kernels and have the appropriate behavior. -- -Dionna Glaze, PhD (she/her)