public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Dionna Glaze" <dionnaglaze@google.com>
To: "Gupta, Pankaj" <pankaj.gupta@amd.com>
Cc: devel@edk2.groups.io, Gerd Hoffmann <kraxel@redhat.com>,
	 James Bottomley <jejb@linux.ibm.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	 "Min M. Xu" <min.m.xu@intel.com>, Andrew Fish <afish@apple.com>,
	 "Michael D. Kinney" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe
Date: Fri, 10 Feb 2023 09:05:58 -0800	[thread overview]
Message-ID: <CAAH4kHa8B+zFSRTDt=-r2i3GgHms7fAOgehEb0KAevHFPos4sw@mail.gmail.com> (raw)
In-Reply-To: <a301b0ec-5d6b-afe3-c082-0e53d0059f8c@amd.com>

On Fri, Feb 10, 2023 at 5:56 AM Gupta, Pankaj <pankaj.gupta@amd.com> wrote:
>
> On 2/9/2023 10:27 PM, Dionna Amalie Glaze wrote:
> > On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze
> > <dionnaglaze@google.com> wrote:
> >>
> >>> With this patch I observe an issue where my Linux (6.2.0-rc7) guest
> >>> recur to Bootloader menu again. I am testing this with SEV SNP (w/o
> >>> UPM). Also, guest don't have lazy memory acceptance support.
> >>>
> >>
> >> Thanks for the report. I'll try to reproduce it on our UEFI and if I'm
> >> unable, then we'll discuss next steps.
> >>
> >
> > I don't see this in our test Ubuntu 22.04 image from Canonical. Do you
>
> Ubuntu 22.04 guest by default run 5.15 kernel? But SEV SNP got
> merged in 5.19. I don't know currently how we are handling accepting
> the memory on "ExitBootServices" with or w/o guest supporting SNP.
>

It does, but I used the Qemu kernel injection pathway in Ovmf to run a
build of 6.2.0-rc7. Our testing setup doesn't give the user a boot
menu to select a kernel, so I wasn't aware that this return to
bootmenu could happen.


>This looks to me like it is entering the 'accept' path twice, and so
> ExitBootServices() is failing twice, resulting in a failed boot.

The double log is expected behavior because I didn't add a check for
whether accepting all memory would be a no-op.

The "Accepting all memory" message occurs twice if the guest does not
have support for unaccepted memory following this control flow:

1. EBS
2. [...] Log "Accepting all memory"
3. Loop through all memory spaces
3a. If the memory space is unaccepted, accept it.
3b. Remove the unaccepted memory space.
3c. Add a conventional memory space back with the same range and capabilities.
4. EBS returns an error since the map key is different.
5. OS calls GetMemoryMap to get the updated key.
6. OS calls EBS with the updated key.
7. [...] Log "Accepting all memory"
8. Loop through all memory spaces
8a. There are no unaccepted memory spaces left, so nothing happens.
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)

  reply	other threads:[~2023-02-10 17:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26  0:56 [PATCH v10 0/4] Add safe unaccepted memory behavior Dionna Glaze
2023-01-26  0:56 ` [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe Dionna Glaze
2023-01-26 10:30   ` Ard Biesheuvel
2023-01-26 16:04     ` Dionna Glaze
2023-02-09 13:35   ` [edk2-devel] " Gupta, Pankaj
2023-02-09 16:52     ` Dionna Glaze
2023-02-09 21:27       ` Dionna Glaze
2023-02-10  8:00         ` Gupta, Pankaj
2023-02-10 11:12           ` Ard Biesheuvel
2023-02-10 11:34             ` Gupta, Pankaj
2023-02-10 13:56         ` Gupta, Pankaj
2023-02-10 17:05           ` Dionna Glaze [this message]
2023-02-13 14:38             ` Gupta, Pankaj
2023-02-13 16:53               ` Dionna Glaze
2023-02-13 17:56                 ` Gupta, Pankaj
2023-02-13 18:31                   ` Dionna Glaze
2023-02-13 19:33                     ` Lendacky, Thomas
2023-02-13 19:33                     ` Gupta, Pankaj
2023-02-13 21:44                       ` Dionna Glaze
2023-02-14 12:51                         ` Gupta, Pankaj
2023-02-14 12:55                           ` Gupta, Pankaj
2023-02-14 20:44                             ` Dionna Glaze
2023-02-14 20:46                               ` Gupta, Pankaj
     [not found]                           ` <1743B21FF9509E5F.2641@groups.io>
2023-02-14 14:00                             ` Gupta, Pankaj
2023-02-14  9:12                 ` Gerd Hoffmann
2023-02-14 17:28                   ` Dionna Glaze
2023-02-14 22:44                     ` Lendacky, Thomas
2023-02-15  9:38                     ` Gerd Hoffmann
2023-01-26  0:56 ` [PATCH v10 2/4] MdePkg: Introduce the SevMemoryAcceptance protocol Dionna Glaze
2023-01-26  1:24   ` Yao, Jiewen
2023-01-26 17:04     ` Dionna Glaze
2023-01-26 17:19       ` Ard Biesheuvel
2023-01-26  0:56 ` [PATCH v10 3/4] OvmfPkg: Implement AcceptAllUnacceptedMemory in AmdSevDxe Dionna Glaze
2023-01-26  0:56 ` [PATCH v10 4/4] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAH4kHa8B+zFSRTDt=-r2i3GgHms7fAOgehEb0KAevHFPos4sw@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox