From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by mx.groups.io with SMTP id smtpd.web10.19974.1676307243849625435 for ; Mon, 13 Feb 2023 08:54:03 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=q2QVcdEK; spf=pass (domain: google.com, ip: 209.85.216.53, mailfrom: dionnaglaze@google.com) Received: by mail-pj1-f53.google.com with SMTP id v6-20020a17090ad58600b00229eec90a7fso14259433pju.0 for ; Mon, 13 Feb 2023 08:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1676307243; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ha1jqhdjLKQ6e7Yn3uQnxyJmwkQGsjEsJGGpG3LU28Y=; b=q2QVcdEKSEnVeUuBVrBsWxhsJJOjVcw0Ton++/E7DPsbRKlo8hIZdte+bJyqR4i0X3 PeGgwJuatdmfN0GJM2NL1ub+t3RXf5+K3uMlI8UAUQ4Ag0bEk5epVlL1lc4ey0YzEt4e +1hv9jpc05r5SItdskvOAl8kZhZPuGt+NSgwVKU1VVBt+PtaRsbK7CsALvUUDkTnGqO6 SyI2/E9bjqYQwV+58TJ9foAO9yi49/V3VFFk8FnYP2LMurbBPAJwhtBfrmsqk/5HFnR3 t8031x63mveKw4RHrAaVq+CqhidQSjbN3l/qua+1Un7fg7uRU+x+jgTWYOOztG3P/AaT azHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676307243; 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=ha1jqhdjLKQ6e7Yn3uQnxyJmwkQGsjEsJGGpG3LU28Y=; b=SyAHe1mxywzjBTjdm/OEXmpllCjJaakrOuB3monJqGdehmVvWmT7hwyDH7+cmnetGI Lpl06LmwQ+h4XUQIstXBYjgyZtkZcMF5L+FzlWqhznABU3ZqFtnVEpnoGKC7RQSkdta3 nxUbzoFGlY3iiAYUkqbpXGNChLm/kmHfObWxp0c83JPpzuDQbr5Rdp6nzgGxce1+baNx yS5bz6RIWOppvcyrVg8sua0QZ4dBkN3uwimRir1b/i5NT8ijb9GY0Iycd6sV91nLYMUi TpC27f699ie5BMxnuk6MCURQqE2zPJGnN9eAT9chs34MB0ICZqYckxAJwswsegyU5jxb vuqw== X-Gm-Message-State: AO0yUKXvbERHEyL9al11gS6Ug8bCey6ySRWUGNZfny6k2ysRPjZy/vkz hPUTrjuTCQZPPB3oRpImL0GorYGLvhv6K8M6T3B8gQ== X-Google-Smtp-Source: AK7set+X7k3w95j53QIF3R9IFbg7UuantnWNzQx3z/W8uGyYoNGV7lNs+rmr26gSbp7kuQ+LfJC9CJ5OI0p4rrfa8/8= X-Received: by 2002:a17:902:70c3:b0:196:1951:3fb7 with SMTP id l3-20020a17090270c300b0019619513fb7mr6211079plt.1.1676307242952; Mon, 13 Feb 2023 08:54:02 -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> In-Reply-To: <9ea61013-e2c1-30a4-3be7-feed537c035a@amd.com> From: "Dionna Glaze" Date: Mon, 13 Feb 2023 08:53:51 -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" > > So, no memory is getting accepted. Questions below: > > - 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... > Thanks, > Pankaj > > > 9. Return successfully (one would hope) > > > >> Accepting all memory^M > >> Accepting all memory^M > >> EFI stub: ERROR: exit_boot() failed!^M > >> EFI stub: ERROR: efi_main() failed!^M > > > > This now does suggest that EBS is failing twice, since after the > > supposed no-op of the second log, the EFI stub's exit_boot claims > > failure. I can't reproduce this part. Would you try adding a log > > within the acceptance loop inside the if that checks for unaccepted > > memory? I'd be curious if the loop is indeed changing the map again, > > despite my claims at idempotency. > > > -- -Dionna Glaze, PhD (she/her)