From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlewS-0006qu-8o for qemu-devel@nongnu.org; Fri, 24 Apr 2015 10:51:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlewO-0002Tk-6k for qemu-devel@nongnu.org; Fri, 24 Apr 2015 10:50:56 -0400 Received: from mga09.intel.com ([134.134.136.24]:27120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlewN-0002TA-S5 for qemu-devel@nongnu.org; Fri, 24 Apr 2015 10:50:52 -0400 From: "Yao, Jiewen" Date: Fri, 24 Apr 2015 14:50:46 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C5001300E31@shsmsx102.ccr.corp.intel.com> References: <1429521560-2743-1-git-send-email-kraxel@redhat.com> <1429521560-2743-6-git-send-email-kraxel@redhat.com> <55365F05.1050402@redhat.com> <553660EC.4040902@redhat.com> <5536672A.6060809@redhat.com> <55366ADF.4000707@redhat.com> <5536B3A8.8040008@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C5001300CF4@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C5001300CF4@shsmsx102.ccr.corp.intel.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PATCH 6/6] [wip] tseg, part2, not (yet) tested) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "edk2-devel@lists.sourceforge.net" , Paolo Bonzini , Gerd Hoffmann Cc: "qemu-devel@nongnu.org" , "mst@redhat.com" Hi Laszlo I think there is good resource for your reference - Intel Quark. https://downloadcenter.intel.com/download/23197 You may download "Board_Support_Package_Sources_for_Intel_Quark_v1.1.0.7z",= and find "Quark_EDKII_v1.1.0" IA32FamilyCpuBasePkg\PiSmmCpuDxeSmm - it is CPUSMM driver. IA32FamilyCpuBasePkg\PiSmmCommunication - it is CommunicationPeim. PiSmmCpuDxeSmm works for Quark, but I think it should be easy to port to QE= MU platform. PiSmmCommunication should be generic, it might be able to put to UefiCpuPkg= later. Thank you Yao Jiewen -----Original Message----- From: Yao, Jiewen [mailto:jiewen.yao@intel.com]=20 Sent: Friday, April 24, 2015 7:56 PM To: edk2-devel@lists.sourceforge.net; Paolo Bonzini; Gerd Hoffmann Cc: qemu-devel@nongnu.org; mst@redhat.com Subject: Re: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: = [PATCH 6/6] [wip] tseg, part2, not (yet) tested) Hi Laszlo Below is my thought. 2) You are right. According to IA32 manual - "Maskable hardware interrupts,= exceptions, NMI interrupts, SMI interrupts, A20M interrupts, single-step t= raps, breakpoint traps, and INIT operations are inhibited when the processo= r enters SMM." You can also find more detail in "34.6 EXCEPTIONS AND INTERR= UPTS WITHIN SMM" In below doc, the "SMM Timer is initialized" means the timer used by BSP to= check if APs are all pulled into SMM for CPU Rendez-vous. A typical implem= entation is ACPI timer (PCH), or APIC timer (CPU). BSP just check timer cou= nt, but the timer does not generate any interrupt. 3) Yes. SmmCoreEntry is useful function as bridge between a real CPU_SMM dr= iver and SMM_CORE. In real world, when SMI happen, CPU will jump to SM_BASE in real mode. Then= it will jump to X64 mode immediately. The all CPUs will be in election phase. Only one will be elected as BSP. Just in case, some APIs are not in SMM yet, the BSP will send IPI to try pu= ll those APs into SMM mode. (SMM timer is used at this moment). Above process is called CPU rendez-vous. Then BSP will do enter SMM_CORE entry point (registered by SmmCoreEntry), w= hile APs are in loop state. After BSP returns from SMM_CORE, it will let APs leave loop state, and all = CPUs run RSM instruction to return back. Hope that helps. BTW: I am not sure how QEMU emulate SMI. Does SMI can be trigger by 0xB2 po= rt? And CPU will run to SMBASE in real mode? Thank you Yao Jiewen -----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com]=20 Sent: Wednesday, April 22, 2015 4:32 AM To: Paolo Bonzini; Gerd Hoffmann Cc: edk2-devel list; qemu-devel@nongnu.org; mst@redhat.com Subject: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger() (was: [PAT= CH 6/6] [wip] tseg, part2, not (yet) tested) (b) This is actually the opposite argument. Since SMM is security sensitiv= e, *and* UEFI is single-processor / single-threaded (well you can use multi= ple processors, you just can't run any UEFI code on anything but the BP), t= he timer interrupt should be blocked / masked *anyway* while in SMM, no? Otherwise edk2 could start running a plain timer= event callback in the middle of an SMM handler. Which makes me think that = this locking / interrupt masking must already be in place, and it's not the= responsibility of the individual EFI_SMM_CONTROL2_PROTOCOL.Trigger() implementation. (PI 1.3 vol4 doesn't me= ntion this responsibility in any case.) I've learned about the "EDK II SMM Call Topology" document from a piwg message: http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II= %20SMM%20call%20topology.pdf/download It doesn't speak about masking the timer. Does SMI mask other interrupts "architecturally" perhaps? ... (3) Oh, this is sad. Well, I am sad. Turns out there's a third UEFI protoco= l that OVMF needs to implement: EFI_SMM_CONFIGURATION_PROTOCOL. Its only interesting member is RegisterSmmEntry(), and that function is sup= posed to bind the central entry point (which is already available in the ed= k2 tree) to the processor-level SMI handler. (I'm kind of confused, because last time I experimented with faking SMRAM /= SMM in OVMF, my fake Trigger() function just returned success, and there w= as no EFI_SMM_CONFIGURATION_PROTOCOL at all, and things seemed to work. In = retrospect I can't imagine how control was transferred at all, without actu= al SMM / SMI support in both QEMU and OVMF. Hm... looking at occurrences of= "SmmEntryPointRegistered", this may have been intentional in edk2.) EFI_SMM_CONFIGURATION_PROTOCOL discussed in the "EDK II SMM Call Topology" = document, on the "SmmDriverDispatcher" and especially the "SMBASE Relocatio= n" pages. It takes a separate CPU driver, and (obviously) assembly code. The "SMBASE Relocation" page references "IA32FamilyCpuPkg", which is not op= en source. Nothing in edk2 produces gEfiSmmConfigurationProtocol, and no so= urce file contains the RSM instruction. The Vlv2TbltDevicePkg package (ValleyView2 Tablet?) makes several reference= s to IA32FamilyCpuPkg, but those are only references. I guess IA32FamilyCpuPkg is exactly the kind of chipset code that Intel has= not opened up. Our "SMM in OVMF" effort just got set back by months. :( Laszlo ---------------------------------------------------------------------------= --- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your o= wn process in accordance with the BPMN 2 standard Learn Process modeling be= st practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_= source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaign=3DVA_= SF _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ---------------------------------------------------------------------------= --- One dashboard for servers and applications across Physical-Virtual-Cloud=20 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