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 1FA64C77B7C for ; Tue, 9 May 2023 06:47:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B68128000C; Tue, 9 May 2023 02:47:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16644280001; Tue, 9 May 2023 02:47:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02D7928000C; Tue, 9 May 2023 02:47:55 -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 E5254280001 for ; Tue, 9 May 2023 02:47:55 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BAA7A1C7405 for ; Tue, 9 May 2023 06:47:55 +0000 (UTC) X-FDA: 80769786510.15.924507E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id CFC80C0003 for ; Tue, 9 May 2023 06:47:53 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=G93vkezy; spf=pass (imf22.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683614873; a=rsa-sha256; cv=none; b=VVanbxn9AMI2XYadGfvjt61adlaLPdBQBjT2erQMo5S1mNP525e2drVl6AZ7UQGPjmTuVW lU57NPGGbt++dPGgaHtD0AD+SEsLHt5D2f2Kcg1KvRA+XXyMzcTDcdRz6t7dNZ7t57+dJ3 8M7QwW+cCxlP3t6sWXmrooTgJ2tNfcI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=G93vkezy; spf=pass (imf22.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683614873; 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=K1T36XvaCtEXp82q8lwJnnpjNC8NjGyuuillRFjdZJs=; b=UO1s0uPJJFvme5H+e3WfPG0be6aO9yZPs0Y5tgqqSF8diuE1Le9QYhNaDCArujQVr4Cw39 zF9S73v7NlgI5MzFWaLJx2tM8MaQndCAMF4hbvLVx1mTmmDK0Th9GtusiQxKqHnW3iUdm1 gupSPrC7zTd/TGV39UZgXSP3MhvwvG8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DD1F062DD2 for ; Tue, 9 May 2023 06:47:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25E0CC4339B for ; Tue, 9 May 2023 06:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683614872; bh=/g0g3mKPSGSxoNisFazeQZrBZpWi+qa0Btk+6LTTmIg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=G93vkezyJ5JYgaRb8raNPkm0MUmUm0RExDdW2RI2ClwGyyHzr7qZEqTACUPj4teNl J6d114DtyMKruzr4eXREji5JoWOz+0XOt69OWB0uDiSvPAzbSAkUv4tQXZG7F6ZmK0 0zFJpdTtBjzRoxRkqnBhmq+bQLDcoUwE3W/Fa4qYq88bucE8MBUY7Ci6URQtVOmJM4 ly8OEiapUmwHijFr3G16XY/uE15vZGS9Ek8wNkviYv3hPKHLIuMzCa7AbO/srsG2h5 vUgF2RUIteZg3V6uK8fnlY24uxBWvQiYWzWYFI6bN6FIHAiMC6SNjLILpCn+d2XsZ5 Onjq69jx6yuBQ== Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-4efe9a98736so6223757e87.1 for ; Mon, 08 May 2023 23:47:52 -0700 (PDT) X-Gm-Message-State: AC+VfDzJsbRLIoJyixJTDX8jC53WHnjmtvFseb66opHJ9gjKKNqRkqTu WQFnoQ0hqV7PXTjY7OEoGbjkeiT9Ysvwt0FYJis= X-Google-Smtp-Source: ACHHUZ7eXCf2DhFoZbXsOooRbR89zqpckWA8L0hnCqv54zhuVpCXL2As1V2WvFbe4mhg1Z0pcGUw+ObvpEBuJ+DjYiI= X-Received: by 2002:ac2:5638:0:b0:4f1:26f5:7814 with SMTP id b24-20020ac25638000000b004f126f57814mr427935lff.20.1683614870122; Mon, 08 May 2023 23:47:50 -0700 (PDT) MIME-Version: 1.0 References: <20230507234618.18067-1-kirill.shutemov@linux.intel.com> <20230507234618.18067-5-kirill.shutemov@linux.intel.com> <20230508190043.ouauzbghn27khdy4@box.shutemov.name> <20230509005634.qtuiodpirexbxu2k@box.shutemov.name> In-Reply-To: <20230509005634.qtuiodpirexbxu2k@box.shutemov.name> From: Ard Biesheuvel Date: Tue, 9 May 2023 08:47:38 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, 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" X-Rspam-User: X-Stat-Signature: 8f6mcwh9afaicptk7aexd1ru3jmpmx1h X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CFC80C0003 X-HE-Tag: 1683614873-12189 X-HE-Meta: U2FsdGVkX18GzHsigRC4aUfPtRpzmV/5q9P8Pqkq+K2+2H/MFILhbtmdJdbs6a7xL4js12/5IVUXurhkX3AedDXKG75EpBbUyh3Z/oZHmdXMEkLgIX+vgNNMpRhp81ZN9SIcMKvp3npgUbOuuEXgu1HZg24JbDbaXNpMxnncUnOXMaj9XgA9Bn72iBJ6oGVXNjYmEKbOJ1/C1wwVLWaegyGBfeF1wOd9ZBC0OGOfLAGwwc2Y8ZDFHD47eZjCvgfJhKo1pdbCfYZXcpbLJpCL5X/WaH8qkLaU//sZO1x6tQzKehx5978d6QBZ8sej4WeH5UBAvFDH0GvIUPNp9IJzkeoDKk5zE34PVXPmOrJL1pRtElgiHT7ayfD1zfLfn9gA1IckTqhka0IrF8CRf8W1kP/jbqSUZmW4L8ScSiesdvCTSnS5uA5C5nRoLkRjf4eUIf2cNTLc9THORGs8t2AZCAlLpxaPpCF9xGKA8j04XObBHbT4z/4nlbl41YxixZgPeFqCBDyw2Qdo+7GXatIBRarFs/wRF4mME797tNwRIlNvU/02lzkFTMnC3HR8qgrnIEcQZ0h3Qtp4IxnPMsrXr1usALVL2HbcQ3KDtWxbMuQELRFvEo4QPuNd9B64Ez7EzHBE3WK/Ur1u35L5IocFejBODSwAsZZ0QPI1HSCPXX0V11KUiIPbeBMnC/mD5m5Y7UdC3Y7xYZdmEh3Tk9juQ3QabpRKhBm/shxrG8WCyCqz8L7AMydmbEmHc10uLtJL8dZohgtLVKvmgKJKtwzbjwYa3gGZb19fbiOIGMUY8XvLdqj8T6aSXIwOPe2zWAxcwgpJzYaC39sl6LlfMK23Ej17QtyXnmxoY9F6ccMMb6H9y0FcL7GzFQ5GgC7e6JyD6nddNaYUdpKk+mvN8B31J9KHeR/KD4euKPxFuBYDIIiafuZkyjvXxOYt/7yzvShbfpx4eyIqjwJ5/0ItE2g hhAMy489 x8x/HFXVHqESUyARjoRV63mRYqoqjO7aKIsnB/C9YraTA8lyafcolJJPTP0balFcn41EgIggU97XV8nFVdprO9YQPpA+KbhEZyeS6HREfUNMujn9maEdz0edBKtNwxU26lQ7N1Bm0AVDA1I7CJ4y+oE7oxN2b/NZu3ys47rPhsbhatVyWY9xXkyM3hPHntciJRztQhvRIoMRvnBP+0+nCeU45alcl9q6LZ7wu2gTyb4Xt+agCRq8e2A2p5pv7YZDqj3iFUks/U1rk9fApbCnLhqo67zF51dNKuikDlmpmu5DvQg4mDg8MO20xh/gXe01cRp2n 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: On Tue, 9 May 2023 at 02:56, Kirill A. Shutemov wrote: > > On Tue, May 09, 2023 at 12:11:41AM +0200, Ard Biesheuvel wrote: > > > @@ -1324,13 +1325,15 @@ void __init e820__memblock_setup(void) > > > * e820_table is not finalized and e820__end_of_ram_pfn() cannot be > > > * used to get correct RAM size. > > > */ > > > - if (boot_params.unaccepted_memory) { > > > + if (efi.unaccepted != EFI_INVALID_TABLE_ADDR) { > > > + struct efi_unaccepted_memory *unaccepted; > > > unsigned long size; > > > > > > - /* One bit per 2MB */ > > > - size = DIV_ROUND_UP(e820__end_of_ram_pfn() * PAGE_SIZE, > > > - PMD_SIZE * BITS_PER_BYTE); > > > - memblock_reserve(boot_params.unaccepted_memory, size); > > > + unaccepted = __va(efi.unaccepted); > > > + > > > + size = sizeof(struct efi_unaccepted_memory); > > > + size += unaccepted->size; > > > + memblock_reserve(efi.unaccepted, size); > > > } > > > > > > > This could be moved to generic code (but we'll need to use early_memremap()) > > I don't understand why early_memremap() is needed. EFI_LOADER_DATA already > mapped into direct mapping. We only need to reserve the memory so it > could not be reallocated for other things. Hm? > *If* we move this to generic code, we have to ensure that we don't rely on x86 specific semantics. When parsing the EFI configuration tables, other architectures don't have a complete direct map yet, as they receive the memory description from EFI not from a translated E820 map. Note that this is only for getting the size of the reservation. Later on, when we actually consume the contents of the bitmap, generic or non-x86 code will need to use the ordinary memremap() API to map this memory, and this amounts to a __va() call when the memory is already mapped. But I am not suggesting changing that part for this series. And even the hunk above can remain as you suggest - we can revisit it once other architectures gain support for this. The main thing I would like to avoid at this point in time is to add new fields to struct bootparams that loaders such as GRUB may start to populate as well - I don't think there is a very strong case for pseudo-EFI boot [where GRUB calls ExitBootServices()] on confidential VMs (as it prevents the EFI stub and the kernel from accessing the measurement and attestation APIs), but let's not create more struct bootparams based API if we can avoid it.