On 2015-05-04 11:03:08, Laszlo Ersek wrote: > 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).
OvmfPkgX64.dsc only supports X64 modules. It is a good example of how a platform can basically always run in X64 mode. (aside from quick/small mode transitions, of course.) I also feel strongly that the IA32, IA32+X64 and X64 versions of OVMF should attempt to be feature equivalent. As far as I know, SMM arch always matches the DXE arch. -Jordan > 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
