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
