[edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and ensure allocated memory <4GB

[Laszlo Ersek]

On 1/6/23 12:14, Gerd Hoffmann wrote:
>   Hi,
> 
>> Now, there *is* one benefit I can imagine. For Intel maintainers, it may
>> be difficult to maintain and to "route around" the SEV-related stuff in
>> "X64/MpFuncs.nasm", in the long term. I can wholly accept that. So
>> splitting and duplicating the assembly code for that purpose is
>> justified. But then the commit message should state this, and not
>> present "staying in 64-bit" as a benefit per se.
>>
>> Then the purpose is to ease the assembly code maintenance for Intel
>> developers. Entirely justified goal in my view; nobody likes to work
>> with complicated code they can't regression-test (and I presume Intel
>> developers can't easily test the various SEV enablement levels in-house,
>> on a range of AMD processors).
> 
> Which is exactly why I suggested to catch the SEV case by checking the
> PCD we have for that in C code.  That'll also remove the confusion we
> have right now wrt intel + amd processors.  The special case we have to
> worry about is SEV being active, not running on a AMD processor.  In
> case SEV is not active we'll just have the IA32 and X64 cases.

Thanks for repeating your suggestion. It seems very plausible, on second
reading. I guess I just couldn't grasp it enough the first time you
proposed it, sorry. I'd be very interested to see this in actual code!

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98123): https://edk2.groups.io/g/devel/message/98123
Mute This Topic: https://groups.io/mt/96067843/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-