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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
