From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C09D53A7 for ; Tue, 19 Jul 2022 22:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658268092; x=1689804092; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=7YsCljn9/plJ4mNS6po3lPvMpYECRfazDmQwYeZV0aM=; b=CFJiTC4bYN3Y1c/c7WpO5uBd/jwt8Y5+Lj+wVYZU0pf5+DdsI02uAa1o pon6cxHsHYDLMyA6HH/L348qM8Q0r1+zc2bMheHb/dAoYd8TtYwjZVAze GfVVSpZSoXThtIAwKrdV8qMQvsIp6Q+nnTyb9CSliFni8ZvES7NcTV14p rgf57foi1mZeNzXpP1yMzL965/+GWzlvkXleerDWrmQmH2Cs/TQd7muXo saNB/MQ6KDDD/6OQBUOoDyLI60mDmUTT8n67iRvdlNJ5gmbUqc6TA6plD 3tiLP5eRje9BeRP4OD+Qhm5ohMs+I0ryFvIBs8VZL7YLQsJppqrE9vuAD g==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="273454336" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="273454336" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 15:01:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="924964668" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga005.fm.intel.com with ESMTP; 19 Jul 2022 15:01:20 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id E322510E; Wed, 20 Jul 2022 01:01:28 +0300 (EEST) Date: Wed, 20 Jul 2022 01:01:28 +0300 From: "Kirill A. Shutemov" To: Borislav Petkov , Peter Gonda Cc: Dave Hansen , Ard Biesheuvel , Dionna Amalie Glaze , 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 , 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: <20220719220128.xl7yo4lk6uxwxilf@black.fi.intel.com> References: <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jul 19, 2022 at 11:50:57PM +0200, Borislav Petkov wrote: > On Tue, Jul 19, 2022 at 02:35:45PM -0700, Dave Hansen wrote: > > They're trying to design something that can (forever) handle guests that > > might not be able to accept memory. > > Wait, what? > > If you can't modify those guests to teach them to accept memory, how do > you add TDX or SNP guest support to them? > > I.e., you need to modify the guests and then you can add memory > acceptance. Basically, your point below... > > > It's based on the idea that *something* needs to assume control and > > EFI doesn't have enough information to assume control. > > > > I wish we didn't need all this complexity, though. > > > > There are three entities that can influence how much memory is accepted: > > > > 1. The host > > 2. The guest firmware > > 3. The guest kernel (or bootloader or something after the firmware) > > > > This whole thread is about how #2 and #3 talk to each other and make > > sure *someone* does it. > > > > I kinda think we should just take the guest firmware out of the picture. > > There are only going to be a few versions of the kernel that can boot > > under TDX (or SEV-SNP) and *can't* handle unaccepted memory. It seems a > > bit silly to design this whole interface for a few versions of the OS > > that TDX folks tell me can't be used anyway. > > > > I think we should just say if you want to run an OS that doesn't have > > unaccepted memory support, you can either: > > > > 1. Deal with that at the host level configuration > > 2. Boot some intermediate thing like a bootloader that does acceptance > > before running the stupid^Wunenlightended OS > > 3. Live with the 4GB of pre-accepted memory you get with no OS work. > > > > Yeah, this isn't convenient for some hosts. But, really, this is > > preferable to doing an EFI/OS dance until the end of time. > > Ack. Definitely. I like it too as it is no-code solution :P Peter, I'm pretty sure unaccepted memory support hits upstream well before TDX get adopted widely in production. I think it is pretty reasonable to deal with it on host side in meanwhile. Any objections? -- Kirill A. Shutemov