From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mx.groups.io with SMTP id smtpd.web10.22985.1676313103409470736 for ; Mon, 13 Feb 2023 10:31:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=UAv7CJCX; spf=pass (domain: google.com, ip: 209.85.215.175, mailfrom: dionnaglaze@google.com) Received: by mail-pg1-f175.google.com with SMTP id z6so4750909pgk.0 for ; Mon, 13 Feb 2023 10:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1676313103; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4FFJQFGr0HI6bnVR62sTm6p1PcOD8YpFtyra6ErxiVE=; b=UAv7CJCXBfF+A3knRiSs+ORGJsEkrDYYos/O3LeqEeC1KXMWzS5CNHrsD/hYfFL1tZ oNxtnaXiYO3j7RqPs+LdBmdl2D8K7gGT69+X75UitRt+fhjGFCxiZE9m4Rn2UsckHiPq bQzHlbNrW9FJrnF+dwU09m2nTY1mhwyEEY7dVgWby+uGUzkXV/sw0PQQhgu3zV7BX/tK 6ULIm79i0TOk3srtOZy+qB44dgsq+dg78MyAunlVShLOkXddLEuN4g1RXWrlP0tvvQff WCBYLFBhHyoZ8QT2ldd5Nn0BEASvNip7jHIsI9PypEx22w7gMWRep/FJZiDwGU1I2Ydy 8JMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676313103; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4FFJQFGr0HI6bnVR62sTm6p1PcOD8YpFtyra6ErxiVE=; b=eulNnfYu98XeXXDADaBJZReEOFVKtCiHcpB9ZW/MS6S+nS02wAy1jayZm/7BidOdla slZREWQry/8o7el+SfkCNe4g4q6PWZOBZvHT/bltPhKSNie0wsN00jbK50NOw06Rh8uI eDoDq4Ov9H+3RSA9bnddz1oQalILmvL1ml1aLApd3fIkpy5ClZYsD4zo5hK9WFwyo4BP +El4wpmR9WF1EoH/8Yb22bZBa6EL1VzSVw+WsSySNLSKa3s3TAs3jI4lRy4jkE/ZR7q7 6kLEktpdeYYQgvEs/AAwyPTi/dFimp47VTO8XrDkOw9WkuOo2Sv8piw1MmEXg4KIxZpL FUGQ== X-Gm-Message-State: AO0yUKVe5eG2/7+rSuZ6ncWt8u6KvlLWIFXNF4Fmzadc5IbNHQn0v1pT fsZyHPgFdzu5bkReYgDIpOpq+fCWB6571EhrgZGa9A== X-Google-Smtp-Source: AK7set/KMxI3yR63f9Pvy1PD5nNnjXjgcyGk92zaKiZ5OIxDKDMbEUOUqB71PQURDtmSJUsXI2S+bY5mNtI+4a2J38g= X-Received: by 2002:a05:6a00:27aa:b0:5a8:be0a:5293 with SMTP id bd42-20020a056a0027aa00b005a8be0a5293mr751964pfb.56.1676313102646; Mon, 13 Feb 2023 10:31:42 -0800 (PST) MIME-Version: 1.0 References: <20230126005647.3019225-1-dionnaglaze@google.com> <20230126005647.3019225-2-dionnaglaze@google.com> <0d8f2b0b-1d62-3db6-34c9-e9ce39838bce@amd.com> <9ea61013-e2c1-30a4-3be7-feed537c035a@amd.com> <52c7d139-3763-b4f2-ab5c-a0a925a1a3ff@amd.com> In-Reply-To: <52c7d139-3763-b4f2-ab5c-a0a925a1a3ff@amd.com> From: "Dionna Glaze" Date: Mon, 13 Feb 2023 10:31:31 -0800 Message-ID: Subject: Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe To: "Gupta, Pankaj" Cc: devel@edk2.groups.io, Gerd Hoffmann , James Bottomley , Jiewen Yao , Tom Lendacky , Ard Biesheuvel , "Min M. Xu" , Andrew Fish , "Michael D. Kinney" Content-Type: text/plain; charset="UTF-8" I'm rather confused at the moment how our internal testing succeeds given the premise of the protocol is to use the specified behavior that the OS must call get_memory_map again if ebs fails with efi_invalid_parameter, but upstream does not appear to do this. If you're able to make progress by applying this patch to your linux build, then we might be back at square one, since the protocol's whole purpose is to work with older SEV-SNP kernels. diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index a0bfd31358ba..795db2315f35 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -747,6 +747,18 @@ static efi_status_t exit_boot(struct boot_params *boot_params, void *handle) /* Might as well exit boot services now */ status = efi_exit_boot_services(handle, &priv, exit_boot_func); + /* + * EBS may fail once with INVALID_PARAMETER, which means the OS must call + * get_memory_map again and try EBS one more time. + */ + if (status == EFI_INVALID_PARAMETER) { + status = allocate_e820(boot_params, &e820ext, &e820ext_size); + if (status != EFI_SUCCESS) + return status; + + status = efi_exit_boot_services(handle, &priv, exit_boot_func); + } + if (status != EFI_SUCCESS) return status; On Mon, Feb 13, 2023 at 9:56 AM Gupta, Pankaj wrote: > > > >> - If no memory is getting accepted at all, should guest boot fail with > >> below errors? > > > > No, the guest should not error. EBS should return success on the > > second call and permit progress. > > > >> - Why unaccepted memory not being set in my setup but works fine for > >> you? Does it require any other change? > >> > > > > We have an internal fork of EDK2 that we regularly rebase on top of > > upstream, and we have our own hypervisor called Vanadium. So there's a > > lot different. We don't have an easy way to test with upstream EDK2 > > and Qemu. > > A recent import found incompatibilities with measured boot only in > > SEV-SNP that we have disabled, but that's related to NVdata, which we > > deal with differently in GCE due to the cloud IVARS service and our > > allergy to SMM emulation. Should be unrelated. > > > > I've looked over our OvmfPkg.patch that we maintain after every rebase > > and most everything is related to our paravirtualized UEFI package > > that eschews SMM to talk to Vanadium directly through either shared > > memory or port I/O depending on whether the guest OS owns cr3 or not. > > > > You've added a log for the if != unaccepted memory, but will you log > > what status the function ultimately returns? And both the MapKey what > > status CoreTerminateMemoryMap returns in DxeMain.c's > > CoreExitBootServices? I'm wondering if maybe the EFI stub calling EBS > > isn't calling GetMemoryMap to update the MapKey after the > > invalid_param result that this semantics depends on. If the stub is > > the Linux kernel's own stub, then it should be doing the right > > thing... > > CoreTerminateMemoryMap::MapKey::18033 ^M > CoreTerminateMemoryMap::Status::2 > .... > CoreTerminateMemoryMap::MapKey::18035 ^M > CoreTerminateMemoryMap::Status::2 ^M > > Thanks, > Pankaj > > > -- -Dionna Glaze, PhD (she/her)