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. > So a world switch is likely unavoidable. :( Maybe not, but maybe simpler in the end. >> 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. Okay, let's cross fingers. :) >> 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. > > (I wonder if there's an inherent need for populating these pointed-to > areas in the CpuMpDxe driver.) Right, these are the questions. > 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. > ... 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. Paolo ------------------------------------------------------------------------------ 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
