From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EAC6D2112E02B for ; Fri, 21 Sep 2018 12:05:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CE96D307D981; Fri, 21 Sep 2018 19:05:40 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-124-218.rdu2.redhat.com [10.10.124.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2B1560F87; Fri, 21 Sep 2018 19:05:39 +0000 (UTC) To: poxyran , Andrew Fish Cc: edk2-devel@lists.01.org References: <69e85ce8-a6bd-1400-5e16-aadd1551b877@gmail.com> From: Laszlo Ersek Message-ID: Date: Fri, 21 Sep 2018 21:05:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Fri, 21 Sep 2018 19:05:40 +0000 (UTC) Subject: Re: [Question] Testing environment regarding SMM driver X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 19:05:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/21/18 20:15, poxyran wrote: > Hello again, > > my question is: is it possible to create a SMM driver that > installs/register a SMI handler (in order to call it from a usermode app > in the OS) and test it in the UEFI Shell or do I need to setup up a > dedicated machine with the SMM stack as described in official EDK II > documentation [1]? > > [1] > > https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt These questions are not "either/or", they are orthogonal. Normally, any pre-existent platform firmware will keep you, as a 3rd party UEFI developer, *out* of SMM. Doing otherwise would be a huge security hole. However, if you own the platform in question (meaning you can build and install the firmware to the platform), then you should be able to use whatever the SMM infrastructure has to offer. It does not matter whether you do this on a physical UEFI development platform, or in OVMF + QEMU/KVM. As long as you get sufficient access to the platform itself. I hope this answers Q1. Regarding the wiki article. I wrote that article mainly for developers with a Windows desktop background. That's why I recommend to set up a separate, headless Linux server. Because, running Linux as the host OS, you get to run OVMF on QEMU not just with software emulation (TCG) but with hardware virtualization (KVM). And the latter makes for a world of difference. If you work at a Windows shop, you can run virtualization clients (management tools) on your Windows desktop, and with them, connect to the Linux server for managing / running your firmware. If you already work on a Linux laptop, you should be able to run OVMF on QEMU/KVM using nothing but your laptop. In such cases, the libvirt client and server components, and QEMU, and the host kernel (KVM), and OVMF, build up the "virt stack" on a single machine. Whether you can do the *exact* things you want to do, within OVMF, I can't tell. I don't know what you mean to do. A good part of the edk2 SMM stack is built into OVMF with SMM_REQUIRE, but (due to QEMU/KVM being a virtual platform), at least *some* artifacts of physical hardware will be necessarily missing. (Such as SMRR, movable LAPIC base, etc.) OVMF also does not include/provide a number of standardized SMM abstractions, such as EFI_PEI_SMM_COMMUNICATION_PPI. (That's by choice, BTW.) I vaguely recall that Ray used OVMF as a testbed for some SMM driver he was developing at some point. I think Ray was using Q35 because of that (i.e. SMM), and his use case also included CSM, and that's why he wrote commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35", 2016-03-15). But I could be totally imagining things. If you run git log --reverse --grep=SMM -- OvmfPkg you'll get a good amount of documentation about OVMF's SMM support. The first large series was 8786ba4fe722..5e04f4b7e1a4, but things didn't stop with that, of course. The OvmfPkg/README file has some notes on SMM too. I think you should be able to imitate the variable driver split, for your use case. You can write a runtime DXE driver that exposes a custom protocol. You can write a UEFI app (to be started from the UEFI shell) that locates and calls this protocol. In the implementation of the new runtime protocol, you can use EFI_SMM_COMMUNICATION_PROTOCOL to send message buffers into SMM. (Actually you could do this directly in your UEFI app too.) I expect you should be able to write a DXE_SMM_DRIVER driver too that registered a hook for the message sent. I don't recall all the details off-hand, but it's very well specified in the Platform Init spec. I hope this helps with Q2. Thanks Laszlo