Thanks Laszlo and Andrew for the answers, from what I can see, is not possible to do what I meant but your answers gave me some ideas. Thanks a lot.
BR, poxyran On 9/21/2018 4:05 PM, Laszlo Ersek wrote: > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
