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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 339BBC32793 for ; Wed, 18 Jan 2023 15:41:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230513AbjARPl5 (ORCPT ); Wed, 18 Jan 2023 10:41:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbjARPlx (ORCPT ); Wed, 18 Jan 2023 10:41:53 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F67112596; Wed, 18 Jan 2023 07:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674056512; x=1705592512; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oDbeD+94j2sqIaSf3nZfHg8M7FyaDfrDoJHJdLgJFy8=; b=nhdHuPRMsyZFez6Qtnuu1/LECYRTnsXzmyol10rcP7DGqgZolaHt2Iqu 5H8ZX9Voyxkaeb6hAF/icLkQag1xXt1n/BGpiDNt2pcW18oOg4vhpi76Y TPFsOcz8ssKJpxtKf6//uoE6fpxouNJWgQo3HKDL9f8/mnSxm1Mt4+gdL UK61phUk/qGF3r+KKq/CC4wLZPL99rgsqUjiv99SzNe0aRZwx1MtC2tMV rVlnRar4O6E7f1mVZypfBQ9S5b7tP5UpqeTPiKaSOQizoQkkB8Y3euuVq hFbJk5EhXUrfT0ZeYdZ1eOevYipU392pzDnPlHaqQiYEvEMoiJuUvJPLS g==; X-IronPort-AV: E=McAfee;i="6500,9779,10594"; a="304692977" X-IronPort-AV: E=Sophos;i="5.97,226,1669104000"; d="scan'208";a="304692977" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2023 07:39:52 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10594"; a="723128703" X-IronPort-AV: E=Sophos;i="5.97,226,1669104000"; d="scan'208";a="723128703" Received: from megreen-mobl.amr.corp.intel.com (HELO [10.209.72.115]) ([10.209.72.115]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2023 07:39:50 -0800 Message-ID: Date: Wed, 18 Jan 2023 07:40:05 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI Content-Language: en-US To: Ard Biesheuvel , Tom Lendacky , Matthew Garrett , Mark Rutland , Borislav Petkov Cc: Gerd Hoffmann , "Kirill A. Shutemov" , Dionna Glaze , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, x86@kernel.org, jiewen.yao@intel.com, devel@edk2.groups.io, "Min M. Xu" , James Bottomley , Erdem Aktas , Dave Hansen References: <20230113212926.2904735-1-dionnaglaze@google.com> <20230113222024.rp2erl54vx3grdbd@box.shutemov.name> <20230116105648.63hsxnmj2juwudmu@sirius.home.kraxel.org> <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/23 07:09, Ard Biesheuvel wrote: > However, I guess we're at a point where SEV and TDX really want > different solutions, so I think divergence might be the way to > proceed. I don't think they want different things really. TDX doesn't need this protocol. It sounds like SEV does need it, though. That doesn't mean they really diverge. They're *both* going to have to poke at this protocol knob to get the firmware to not accept the memory. This does slightly change the motivation for doing explicit unaccepted memory support in the kernel. I also don't know _quite_ how this will look to a guest. For instance, will they see different memory maps based on which protocol they are using? I assume so, but didn't see any of that explicitly mentioned in this patch.