Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e1986845-9eb9-2147-5073-5d7a45633aba@intel.com>
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 <ardb@kernel.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Borislav Petkov <bp@alien8.de>
Cc:     Gerd Hoffmann <kraxel@redhat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Dionna Glaze <dionnaglaze@google.com>,
        linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
        x86@kernel.org, jiewen.yao@intel.com, devel@edk2.groups.io,
        "Min M. Xu" <min.m.xu@intel.org>,
        James Bottomley <jejb@linux.ibm.com>,
        Erdem Aktas <erdemaktas@google.com>,
        Dave Hansen <dave.hansen@linux.intel.com>
References: <20230113212926.2904735-1-dionnaglaze@google.com>
 <20230113222024.rp2erl54vx3grdbd@box.shutemov.name>
 <20230116105648.63hsxnmj2juwudmu@sirius.home.kraxel.org>
 <def9b0b5-b880-be99-fa95-b05d76a91824@intel.com>
 <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com>
 <CAMj1kXG7s_B1nyEgsxFRRvUzsWNXcFfTszRA2hKY=_a-L24PZg@mail.gmail.com>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <CAMj1kXG7s_B1nyEgsxFRRvUzsWNXcFfTszRA2hKY=_a-L24PZg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.