From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by mx.groups.io with SMTP id smtpd.web10.32553.1658176427911347973 for ; Mon, 18 Jul 2022 13:33:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=jOe7NYep; spf=pass (domain: gmail.com, ip: 209.85.208.174, mailfrom: benjamin.doron00@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id o12so15059189ljc.3 for ; Mon, 18 Jul 2022 13:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=u3GcEaMv0stJ7kZeQ2p78ruzDbJy2oyZkJ+/f0aAkCI=; b=jOe7NYepnd2LQ4kFCbWMBaBeirE58+94IxqYEktj46D7OhvC0lTvmpChnOmrFTURCv RSSyn/1AruEw4DjvoNjczK0Aq0soSrJB6qEYyAySJAjnvwT5TkNcmjO8/qL/Q3QkPr4X YOhYsT9yASKwuNhb4C0Kxfj6Kq1yytLTTQHmqDDBZp6HZ7NE3d4ziTVb1ELhYmEZ9FD6 48MzLLPzZJ59c1ooavHDgmlXMh59CGmAr7v0IUcCZaetXoXCPRiO9ajmO424Q2yLWlSy KHFIs3+XU6Nyawnc8JIdGcMzZ/z9y+3+GYhYxL14VEVJXDInQ7cum3KQ5uTlcN3QGxfC MxTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=u3GcEaMv0stJ7kZeQ2p78ruzDbJy2oyZkJ+/f0aAkCI=; b=RHI5pR2NUMkMYv8cBn5sTlTbJGXzr0pZeOQu+w49YLoFcaBqG1/+2v8PmAmxJnIwD/ npv9jyRx91eWjrNZ3rCPkhI917R2xgAcSVE6+BQA3Ayf3DEqhwtus94ggHuRwXuqZAOz 9TfKvbavzanr2nGPTavhpgrtq1l7jqQK8lk2z1CbFNKyCU/kcDukwM7YOHaT/7mwhfqY xka9ERlvm6G1LStADQAXwYqxmuJQ5JSvyhlfLe1NFl4aLwlhQlvF6km+dtLIJqTGVk07 sWfnDcCxcrZkj5E4LoBZwrbLco8FNMSVInYHqd9ucpCZy6XbIgo9Uj+Lc+oVOG7uWHC7 38Sg== X-Gm-Message-State: AJIora+OY7HBxDQyYZIb2xQurG7IdT1prGrx0u3yY1cF28ic0hiFPXiP YksuqLT6uSGCM9is5wxQZaEhCw5sbmLGa9KTdmRWO7+vILs= X-Google-Smtp-Source: AGRyM1tW/b7csVS6BRiQCNnJLZhZAv0K95itsw87GPWaQJmseYlLzVyDxfEfKMa3yJ31pcZO6j2YjJCISLW+FGlCq90= X-Received: by 2002:a2e:b70b:0:b0:25d:52f3:3043 with SMTP id j11-20020a2eb70b000000b0025d52f33043mr13106194ljo.380.1658176426035; Mon, 18 Jul 2022 13:33:46 -0700 (PDT) MIME-Version: 1.0 From: "Benjamin Doron" Date: Mon, 18 Jul 2022 16:33:35 -0400 Message-ID: Subject: [GSoC 2022] Implementing S3 resume for MinPlatform To: devel@edk2.groups.io Cc: "Desimone, Nathaniel L" , "Sinha, Ankit" Content-Type: multipart/alternative; boundary="000000000000d94c8805e41a4832" --000000000000d94c8805e41a4832 Content-Type: text/plain; charset="UTF-8" Hi all, I've been working on implementing S3 resume support for MinPlatform during the past few weeks. Presently, the last line of code that I know will execute on resume flows is https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c#L878 - right before transferring control to BootScriptExecutorDxe. I had added a debug print at https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c#L47 to ensure that control was successfully passed here, but it never executes and the platform doesn't resume. I've considered that it may be a debug library-specific issue, and I've been fixing some of those (but that certainly may still require debugging). However, after addressing that, the bug still too predictably occurs here. Therefore, what other assumptions are made for the jump here to succeed? So far, I've considered: - DxePcdLib could try calling the protocol after exit-BS, which is guaranteed to fail (then page fault). However, I've checked the disassembly and it's not used on resume flow. This is fine. - DebugLibSerialPort is used for this module, because RSC's serial port handler is unregistered at exit-BS. This should now be fine. Some (potentially) plausible architectural issues: - Page tables are used in long mode. Maybe I could verify these are sane by looking up the structure and printing each entry's fields, but they are probably fine. - Maybe BootScriptStackSize is too small? I sort of doubt it from looking at the disassembly. Also, even if the stack overflows, I'd expect the earlier debug prints to succeed. - Maybe my added debug print in S3BootScriptExecutorEntryFunction() is a problem? However, it's the IDTR that's written, not the GDTR. I'd expect that to only be an issue if an interrupt is fired. Also, SmmRestoreCpu() does the same. As I understand, normally there is an enormous difference between DXE and SMM, because SMM has some resume state in some CPU MSRs (etc), but I think here PiSmmCpuDxeSmm is being entered as if it were mere 64-bit code, like DXE. Best regards, Benjamin --000000000000d94c8805e41a4832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
I've been working on implementi= ng S3 resume support for MinPlatform during the past few weeks. Presently, = the last line of code that I know will execute on resume flows is https://github.com/tianocore/edk2/blob/maste= r/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c#L878 - right before= transferring control to BootScriptExecutorDxe.

I = had added a debug print at https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/A= cpi/BootScriptExecutorDxe/ScriptExecute.c#L47 to ensure that control wa= s successfully passed here, but it never executes and the platform doesn= 9;t resume. I've considered that it may be a debug library-specific iss= ue, and I've been fixing some of those (but that certainly may still re= quire debugging). However, after addressing that, the bug still too predict= ably occurs here. Therefore, what other assumptions are made for the jump h= ere to succeed?

So far, I've considered:
=
- DxePcdLib could try calling the protocol after exit-BS, which is gua= ranteed to fail (then page fault). However, I've checked the disassembl= y and it's not used on resume flow. This is fine.
- DebugLibS= erialPort is used for this module, because RSC's serial port handler is= unregistered at exit-BS. This should now be fine.

Some (potentially) plausible architectural issues:
- Page ta= bles are used in long mode. Maybe I could verify these are sane by looking = up the structure and printing each entry's fields, but they are probabl= y fine.
- Maybe BootScriptStackSize is too small? I sort of doubt= it from looking at the disassembly. Also, even if the stack overflows, I&#= 39;d expect the earlier debug prints to succeed.
- Maybe my added= debug print in S3BootScriptExecutorEntryFuncti= on() is a problem? However, it's the IDTR that's written, no= t the GDTR. I'd expect that to only be an issue if an interrupt is fire= d. Also, SmmRestoreCpu() does the same. As I understand, normally there is = an enormous difference between DXE and=20 SMM, because SMM has some resume state in some CPU MSRs (etc), but I think= =20 here PiSmmCpuDxeSmm is being entered as if it were mere 64-bit code,=20 like DXE.

Best regar= ds,
Benjamin
--000000000000d94c8805e41a4832--