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 4F0E0C433EF for ; Tue, 19 Jul 2022 21:23:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CADC56B0074; Tue, 19 Jul 2022 17:23:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C36AA6B0075; Tue, 19 Jul 2022 17:23:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAE936B0078; Tue, 19 Jul 2022 17:23:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9B0FA6B0074 for ; Tue, 19 Jul 2022 17:23:48 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6CF5A14027A for ; Tue, 19 Jul 2022 21:23:48 +0000 (UTC) X-FDA: 79705126536.24.A9F956F Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf07.hostedemail.com (Postfix) with ESMTP id 17D6D40059 for ; Tue, 19 Jul 2022 21:23:39 +0000 (UTC) Received: from zn.tnic (p200300ea97297609329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9729:7609:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E629F1EC0644; Tue, 19 Jul 2022 23:23:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1658265808; h=from:from: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; bh=9enq0fgxD5G4aG3v4Ve8uLcTEh3C8HVLu42xXwSENQs=; b=Nepl+HfvfnIeaiJV3nAMnxEVX+rd09745zFNBMV7IvHW/EAVv0blS62razb3b9KTO9qOoA S28eL2neJFYrwuoZl4vDQ+2PrCE5Ie0OcYUc+Ru6rBXZFKh1iPj+qp5/MuPLDQJf/1U2Me Lr2aHQ7qIx0xQpAbilMYQxlmcvQYAPk= Date: Tue, 19 Jul 2022 23:23:19 +0200 From: Borislav Petkov To: Ard Biesheuvel Cc: Dionna Amalie Glaze , "Kirill A. Shutemov" , Peter Gonda , 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" Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Message-ID: References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=Nepl+Hfv; spf=temperror (imf07.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658265825; 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=9enq0fgxD5G4aG3v4Ve8uLcTEh3C8HVLu42xXwSENQs=; b=zruA7HACK0I2ApbJQmpDZUPfUGlGrKF3Cw0//x1otxRqyliiNR7yETa8e9gtCDTD4txQBW WEbM8dB4xFgewpQ0f3X2/c/FCbzZxLrFHCx0s4fiL4pbqCcOKir3xtfBofXbhtfizcnG7l xAOaiou8S2NI8dU7/eevLEngukWzLX8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658265825; a=rsa-sha256; cv=none; b=Kz3REtwglcKFvVirEb1zB2euee/KD6Ye7j/CP87odNWX8yF9z0kXiT8R+ajoevZPCNI8oa mK8aITcq23g60rV5l4r/pTMrOkYQwh4GfJuWvGyhNQkrnvlL3VyXukjBSUL5wKvb3s/1R6 pw9R7riTr9en5i8H22cYQ0mKUyR0Jr4= X-Rspam-User: X-Rspamd-Queue-Id: 17D6D40059 Authentication-Results: imf07.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=Nepl+Hfv; spf=temperror (imf07.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) X-Stat-Signature: o34zrrxk3uajn7oaqkjytw3mfgcy8jxs X-Rspamd-Server: rspam07 X-HE-Tag: 1658265819-853491 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, Jul 19, 2022 at 10:45:06PM +0200, Ard Biesheuvel wrote: > So let's define a way for the EFI stub to signal to the firmware > (before EBS()) that it will take control of accepting memory. The > 'bootloader that calls EBS()' case can invent something along the > lines of what has been proposed in this thread to infer the > capabilities of the kernel (and decide what to signal to the > firmware). But we have no need for this additional complexity on > Linux. To tell you the truth, I've been perusing this thread from the sidelines and am wondering why does this need this special dance at all? If EFI takes control of accepting memory, then when the guest kernel boots, it'll find all memory accepted and not do anything. If EFI doesn't accept memory, then the guest kernel will boot and do the accepting itself. So either I'm missing something or we're overengineering this for no good reason... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette