On 05/04/15 17:55, Paolo Bonzini wrote: > 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.
(2) looked like a great idea to me, but after all I doubt it would work. Massaging the DSC files would maybe possible (similarly to the Ia32X64 build, as you say -- just build the SMM core and the SMM drivers in the Components.IA32 part, and add one such part to the X64 DSC file). And then maybe the SMM IPL (which is a runtime DXE driver) could load and launch the 32-bit SMM core, even. (Not sure this is supported by design.) At least the SMRAM that the SMM core would live in is certainly under 4GB. However, the point where it ultimately breaks, I think, is the individual runtime drivers that communicate with their privileged SMM counterparts. The communication happens via serializing a binary message, and then raising an SMI. Minimally in the case of the authenticated variable driver (the unprivileged half), SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableSmmRuntimeDxe.c said serialization occurs to a buffer that is pre-allocated (with the maximum possible message size, which is known in advance) during boot time (ie. before we enter the runtime phase). This buffer is allocated in SmmVariableReady(), with AllocateRuntimePool(), and the original (physical) address is passed to EFI_SMM_COMMUNICATION_PROTOCOL in SendCommunicateBuffer() later on, for the actual operations. AllocateRuntimePool() will happily allocate the buffer as high as possible, which then requires the SMM half to have the same bitness. (The buffer is of course untrusted and the SMM half will carefully validate the message first, but nonetheless it must be able to access it.) So a world switch is likely unavoidable. :( > 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? I'm not sure, but I think I see why you're asking this. (I can't provide test results because (a) the GetFirstGuidHob(&gEfiAcpiVariableGuid) never succeeds with our current S3 implementation, and (b) in the early S3 versions that faked SMRAM, *neither* of the signature checks (SMM_S3_RESUME_SMM_32 / SMM_S3_RESUME_SMM_64) matched, hence the code fell back to the direct S3ResumeExecuteBootScript() call at the end of the function.) > If it is, I wonder which parts of the existing SMM support assume the > OVMFIA32.dsc or OVMFIA32X64.dsc configurations. Good question. As stated above, this code has never been exercised in OVMF (any configuration), as far as I recall. > > Does OVMFIA32X64 work at all, or has it bitrotted? I think it should work fine. We don't test it regularly, but we always keep the different bitness DSC and FDF files in sync (I tend to diff them between each other), and we're careful about integer-to-pointer (and inverse) conversions, and about passing pointers between PEI and DXE. I expect the "32-bit PEI with 64-bit DXE" build to work. ... Yes, I tested it (incl. S3) with a 64-bit, 5GB RAM Fedora 20 guest. Seems to work fine. >> * 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? I hope Jiewen can help us with this -- can we perhaps talk to the authors of these drivers? (The Quark_EDKII_v1.1.0 project doesn't seem to name natural persons, and it is not available as a source code repo, just in tarball form, so no commit info either.) ... Honestly I don't understand why a side channel must exist between those two drivers. > More important: who produces *the data pointed by* the PCDs? Is it the > SMM driver or is it the CpuDxe driver? Right. Unfortunately, both PCDs are pointed at static variables that live inside, and are populated by, the CpuMpDxe driver referenced above: - PrepareMemoryForConfiguration() in Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ProcessorConfig.c sets PcdCpuConfigContextBuffer to the address of "mCpuConfigConextBuffer". - SaveCpuS3Data() in the same file sets PcdCpuS3DataAddress to the address of mAcpiCpuData. (I wonder if there's an inherent need for populating these pointed-to areas in the CpuMpDxe 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. In this case I'm not worried about the runtime guest OS; the SMBASE relocation should happen only once, during DXE (the SMM world starts to live then, and continues into runtime). The OS should be allowed to reuse 0x30000 (and therefore I'm thinking "boot services data"); but I think DXE drivers should certainly be kept out of there. ... I hope we'll get help from the original authors of this code. If not, I can embark on reading & analyzing these two drivers in depth (keeping the Intel SDM open too), but given their sizes (each one is larger than 300 KB as I said), it will take forever. :( Thanks Laszlo ------------------------------------------------------------------------------ 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
