On 05/04/15 21:21, Paolo Bonzini wrote: > > > On 04/05/2015 20:03, Laszlo Ersek wrote: >> 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. > > Is there no <4G pool? Perhaps we can add a PCD, or just do it > unconditionally because 32-bit SMM seems like a better match for > OVMFIA32X64.dsc.
Memory allocations can be limited to a maximum address (well, page allocations, not pool allocations), but the point is that the "abstract" SMM drivers should remain abstract. The more I go outside of OvmfPkg (and not with fixes for genuine bugs) and outside of those designated protocols / PPIs, the harder the review process becomes. >> So a world switch is likely unavoidable. :( > > Maybe not, but maybe simpler in the end. Right, I just need to find that person to bribe. :) >> 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. > > Oh, it's not in the PEIM? I would have thought that SMBASE relocation > is not preserved by S3: > http://comments.gmane.org/gmane.comp.emulators.bochs.devel/7935 suggests > the same. Huh. You are right of course. During S3 resume, the SMBASE relocation must be redone minimally so that the resumed OS can again use the (SMM-based) variable services. None of the PEIMs do that explicitly. So, I think this SMBASE reprogramming on S3 resume should then happen via the SMM_S3_RESUME_STATE object that I mentioned earlier. Hm, indeed. Jiewen wrote in an earlier private thread (see Message-Id <74d8a39837df1e4da445a8c0b3885c5001300...@shsmsx102.ccr.corp.intel.com>) that the SMM_S3_RESUME_STATE.SmmS3ResumeEntryPoint entry point had to "restore CPU MSR data, do SM_REBASE for BSP and APs". ... It is called by the S3 resume PEIM, and it is then supposed to return control to SmmS3ResumeState->ReturnEntryPoint (which is S3ResumeExecuteBootScript()). ... The SmmS3ResumeEntryPoint field is set to SmmRestoreCpu(), inside PiSmmCpuDxeSmm. And that function further calls SmmRelocateBases(). So, basically, the S3 resume PEIM transfers control directly into the CPU SMM driver for a while (which it can do because the SMRAM is open at that stage). So I think you are right; since the relocation will overwrite 0x30000 on each S3 resume, we need to advise the runtime OS too to stay away. I don't know where / if this is happening in the Quark source code. Could be a genuine bug or just me missing the place. >> ... 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. :( > > Hmm, I think we need to understand the requirements before reading the > code. You need to try and read sections of the code in isolation. Indeed the first thing I'd like to understand about individual functions is "what is this good for, and do I need it at all". I guess I'll start on that tomorrow. 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
