On 03/18/15 20:29, Peter Jones wrote:
> Hi,
> I've written a driver for edk2 in QEMU to provide very basic support for
> ESRT
Where can I read about ESRT? ACPI 5.1 does not mention it.
> and (fake) firmware updates via UpdateCapsule(). The purpose of
> this is to allow us to write a test harness for our OS and pre-boot firmware
> update code without the worry of burning through piles of hardware (or
> spending days on end with a dediprog) every time something goes wrong.
>
> As such it never actually updates any real firmware - all it actually
> does is SetVariable() to store the API state.
Are the variables set in this way the standardized CapsuleNNNN
variables, from
7.5.6 UEFI variable reporting on the Success or any Errors
encountered in processing of capsules after restart
or something "ad-hoc"?
> This allows us to start a
> VM with a custom ESRT by providing an NvVars file on the boot drive
> image,
"an NvVars file on the boot drive" is strongly deprecated; it predates
our pflash support. Normally ACPI tables are generated by QEMU, or
(custom tables are) passed with the -acpitable QEMU switch. OVMF then
installs those tables.
Anyway, looking at the commit message in the patch, apparently variables
in a new GUID ("namespace") are used to compose an ESRT dynamically.
... The rest of that commit message I don't understand. (I need more
education; I don't have any of the context.)
In any case, the variables discussed here seem to qualify as "input". Is
that a necessity, or just a way that works?
Like, you create some UEFI variables while running guest Linux in this
GUID ("namespace"), reboot the guest (keeping the same qemu process
alive), and this driver in the firmware picks up your variables,
composes an ESRT, and... well I don't know.
So please enlighten us wrt. the intended workflow.
Anyway, does this input for the ESRT *have* to come from inside the
guest (ie. guest Linux, in the form of UEFI variables), or can it come
from the host side too? Because, for the latter, one option would be the
existent -acpitable switch. Another option would be something that
Gabriel is working on right now for QEMU -- passing in named fw_cfg
blobs from the host side, for purposes that are not specified on the
qemu level (ie. they would be specified by the firmware or other guest
code).
I'm just asking because if we can unify some info channels here, maybe
we should. Both OVMF and AAVMF have client libraries for fw_cfg.
> provides a mechanism to deterministically exercise the APIs, and
> allows us to examine the results independent of the normal APIs.
A bit more specification would be appreciated before looking at the code
-- what APIs are exercised (The UpdateCapsule() runtime service? Or
"Delivery of Capsules via file on Mass Storage device"?), what are the
results etc.
> I've checked that it builds and runs using OvmfPkg on x86_64, and that
> it builds on ia32, arm, and aarch64.
>
> So - if anybody would be so kind, review and feedback would be good :) I
> *think* I'm mostly following the coding conventions for edk2, but TBH
> I'm not sure where they're written down,
http://sourceforge.net/projects/edk2/files/Specifications/EDK2_C_Coding_Standards_2_0.pdf/download
> so I've just been ballparking
> it based on code in the repo - which varies significantly from module to
> module.
Another question: would you like to have this module added to edk2, or
are you "just" looking for feedback?
Thanks
Laszlo
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
