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. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98119): https://edk2.groups.io/g/devel/message/98119 Mute This Topic: https://groups.io/mt/96067843/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
