On 04/05/2015 15:58, Laszlo Ersek wrote: > So here's the *specific* issues I'm facing (and need help with): > > * Problem #1 for task (4): > > Because Quark is 32-bit only, the (mostly assembly) code under > "OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32" that (partly) constitutes the > SMM entry vector does not *build* for X64 guests. > > I don't know what it would take to make that code build & work for X64 > guests: > - just replace some registers and instructions, and maybe recalculate > some offsets? > - or else, is X64 architecturally different in this regard, and a > rewrite from scratch is needed? > > (But, again, this code should have always lived in edk2, under > UefiCpuPkg...)
The SMM entry vector will start in a 16-bit real mode code segment, albeit with 4GB segment limits. So there must be yet another 32-bit protected mode switching sequence somewhere. So my guess is: 1) you can add a 32->64-bit mode world switch there. I know your love for this kind of code, I guess you can bribe someone to take care of this part. :) 2) build the SMM code in 32-bit mode, similar to OVMFIA32X64. My gut feeling is that (2) is simpler if one knows the edk2 build tools, which I don't so I may be saying nonsense. Regarding this, I'm going to ask a question though... The way I read the S3RestoreConfig2 function of UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c, is that the function assumes it runs in 32-bit mode when SMM is available. Is this correct? If it is, I wonder which parts of the existing SMM support assume the OVMFIA32.dsc or OVMFIA32X64.dsc configurations. Does OVMFIA32X64 work at all, or has it bitrotted? > * Problem #2 (terrible) for task (4): > > I audited all PCDs used by PiSmmCpuDxeSmm carefully. Most of them are > fixed or feature PCDs, fine. However, there are two dynamic PCDs that > carry important information (and we can't just go with a default): > - PcdCpuConfigContextBuffer > - PcdCpuS3DataAddress > > PiSmmCpuDxeSmm *consumes* these PCDs, and the driver that produces them > -- brace for impact -- is > > Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ > > This means that PiSmmCpuDxeSmm will never work unless we throw out our > current MpService implementation, located in edk2's > > UefiCpuPkg/CpuDxe/ > > (contributed by Chen Fan of Fujitsu), and replace it with the one from > the Quark distribution. > > Which means that I'd have to import *another* 300+ KB driver from the > Quark package, get it to build, and pray that it doesn't have even > *further* dependencies. What do these PCDs do? Can we backport them to the edk2 CpuDxe? More important: who produces *the data pointed by* the PCDs? Is it the SMM driver or is it the CpuDxe driver? Especially if the data is produced by the SMM driver, problem #1 seems worse. > * Problem #3 (smaller, in comparison) for task (4): > > The default SMBASE area, starting at guest-phys address 0x30000, and > continuing for 0x10000 bytes, doesn't seem to be protected with any kind > of memory allocation HOB or similar in Quark_EDKII_v1.1.0. (Grep for > SMM_DEFAULT_SMBASE). > > Why is this okay? As far as I understand, when a CPU enters SMM for the > very first time, it will happily scribble over this area (saving state > etc). We should make sure in advance (starting from PEI) that no later > memory allocation (in PEI or in DXE) will accidentally overlap with that > memory range, because when the SMBASE relocation is performed, that > allocation will be corrupted. This seems right. It should be an EfiACPIMemoryNVS HOB, I think. I think you do not need actual SMM stuff in order to check whether this upsets OSes. Paolo > Can someone please advise wrt. to problems #1 to #3? ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel