From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by mx.groups.io with SMTP id smtpd.web10.21955.1676048770395973186 for ; Fri, 10 Feb 2023 09:06:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=ZnnOhWbA; spf=pass (domain: google.com, ip: 209.85.210.175, mailfrom: dionnaglaze@google.com) Received: by mail-pf1-f175.google.com with SMTP id d4so626947pfo.4 for ; Fri, 10 Feb 2023 09:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/my3KJWYdsaTcvqos5HwRcA412d1VQVMABA/jDUczBc=; b=ZnnOhWbAFTiTIb6DW/nQy6TYLkSlIVcvKhLIKZCAEL/G6HwZMcQUkzyQkGJ+BOXlGD +mv2UB8G8CSlaEWezInrT+4rQrvJrld4SSpEAF3jR0MQXHC0l8VZJDHkrLjLa2nhpVEa Q2IwlA0JqQYUSvM0+bDTPJVEBB1vLsEy98ISJZyPmKCIr6Nn2X5OANv1a8UiWPOmIhl1 aw+DbJS10jmkD29d4uQIgDCWfkdjSo/u9KychK7Ao7QU+rFevNljXVHHov4/ILmCpPoL j4/IaWG65ejevJrs/Nxk+Gx+zcSxgpX/BCDeRgXOjaXJVZUicr/vHjTbL+yHSDIKdJFY asaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=/my3KJWYdsaTcvqos5HwRcA412d1VQVMABA/jDUczBc=; b=niBlfCcsYq1DtQlRZ/bPiiVMJQlHqrpybHGXngddYYR37dUZF7DyxrCsfTT93FsNGO GQTRM6Xm1te0VDhVQ01HOm5F1xbzJMNLCi8eRM2FQG8amFvplqmBzDn5uNfF8n8lZ4Ji 2k+CjPJM5LXk43v5fC3Hs27ovYkfaILyVnTwCdp++iA5vli2/aMQ71fb1cPcU+8O//un FZr0P2r86ssKSlYr5vDaMggFIx6qnUxNIxhW4phLTgJ19+Y+fIpTTlupya5M3pbU23d5 /nrn2rmEgogBM3AD7WUw6UaDDNzr5rkmoR+CO7kHm1/LR9onDXaWy7kNENv2pB8DiowB EOyg== X-Gm-Message-State: AO0yUKXSqUeQdaJuJofJvRIXRaC57aAa1TZBPhkT7U+U2Uh4VHmmuefg yj0BzUjCAUFkCJtg42ryqXhXG3ZT/VNELhD3DKjH1Q== X-Google-Smtp-Source: AK7set95NbcriZ6UrFjcuFmIN0/SbB+DJruT/gvyBTdBXPYjUohxZrOonbReYhcBMkewA6NK9dxC2KEn9Z+cbYcOJag= X-Received: by 2002:a62:1c54:0:b0:5a8:5fa4:8c68 with SMTP id c81-20020a621c54000000b005a85fa48c68mr1056204pfc.23.1676048769537; Fri, 10 Feb 2023 09:06:09 -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> In-Reply-To: From: "Dionna Glaze" Date: Fri, 10 Feb 2023 09:05:58 -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" On Fri, Feb 10, 2023 at 5:56 AM Gupta, Pankaj wrote: > > On 2/9/2023 10:27 PM, Dionna Amalie Glaze wrote: > > On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze > > 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)