public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gupta, Pankaj" <pankaj.gupta@amd.com>
To: Dionna Amalie Glaze <dionnaglaze@google.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: Mon, 13 Feb 2023 15:38:40 +0100	[thread overview]
Message-ID: <9ea61013-e2c1-30a4-3be7-feed537c035a@amd.com> (raw)
In-Reply-To: <CAAH4kHa8B+zFSRTDt=-r2i3GgHms7fAOgehEb0KAevHFPos4sw@mail.gmail.com>


>>>>> 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.

Seems like hitting this all the time. Can't see
EFI_GCD_MEMORY_TYPE_UNACCEPTED memory at all in the memory map.

And always hitting:
if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {

So, no memory is getting accepted. Questions below:

- If no memory is getting accepted at all, should guest boot fail with
   below errors?
- Why unaccepted memory not being set in my setup but works fine for
   you? Does it require any other change?

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.
> 


  reply	other threads:[~2023-02-13 14:38 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
2023-02-13 14:38             ` Gupta, Pankaj [this message]
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=9ea61013-e2c1-30a4-3be7-feed537c035a@amd.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