On Thu, Mar 19, 2015 at 01:03:58PM +0100, Laszlo Ersek wrote: > 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.
It's a UEFI configuration table - ECR 1090 ( https://mantis.uefi.org/mantis/view.php?id=1090 ) or the UEFI 2.5 drafts have it. I can get you access internally if you don't have it already. > > 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"? Those are the /results/ and it does do those; the actual control variables are any variables under the guid you reference below, and they just hold an ESRT entry - i.e. not the table header but the individual entry describing one flashable part. > > 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. Yeah, that's true - it's just an example. > 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? That's a necessity, in that the variables' contents are going to be determined by the test scenarios you determine are worthwhile, and that's going to depend largely on the code being used apply capsule updates from EFI and your OS. > 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. Well, when I write a test harness with it, my plan is to make several scenarios on different pflash images, and merely iterate starting guests with different images. It doesn't really matter - you can structure that workflow however is most convenient for you if you're deploying something. Personally, I'm going to make images for each of several scenarios - more than one capsule at once that are all valid, more than one capsule at once where some are valid and some aren't, single capsules, only invalid capsules, capsules with version numbers of 0xffffffff, etc., and then rig jenkins up to run a series of tests against each using the userland linux code Richard Hughes and I have written and the efi application I've written as part of that to apply the updates. So jenkins will start a QEMU instance with a particular pflash > 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? It doesn't really matter, so long as it stays in a persistent data store across reboots, we can write to it from within UEFI, and it happens before the ReadyToBoot event. > Because, for the latter, one option would be the > existent -acpitable switch. Well, there's no ACPI table here, and the data needs to be writeable from within the firmware. I /could/ workaround the requirement that it be writeable by propagating status back from Capsule#### variables during boot, but that's quite a bit more complexity, and ideally ESRT entries' status flags wouldn't depend on variables defined by UEFI that are necessarily mutable. > 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). That could potentially work as well - the only requirement is that they exist as variables before the ReadyToBoot event, because that's when we're generating ESRT. So setting them from inside the running firmware or a guest OS and then rebooting will work, as will any method of populating the data store from outside of the guest environment before starting it. (I suspect you create such a variable after that, UpdateCapsule() on it will work, it just won't be in the ESRT until an intervening reboot.) Honestly if you had a driver that created variables from the host, that would work, so long as it was before the ReadyToBoot event or there was an intervening reset. It's also worth noting that I implemented all of ESRT_OPERATION_PROTOCOL because it already exists in Tiano, and I'm assuming somebody has some plans about using it some day, but there's no code in this patch (or the branch it's against) that actually uses that protocol. So all but EsrtPopulateTable() there are untested at this time. The other stuff is there to support FMP (i.e. option ROMs), I think, and I may add some code to make test harnesses that look applicable to that as a separate patch later, but it's not necessary for a first pass at a working driver to test against. > 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. Fair question - it's just UpdateCapsule() . The results are a) updated status in ESRT, b) Capsule#### and whatnot result variables being modified, and c) UpdateCapsule()'s return value. I'll add some text in my commit message on the next revision of the patch. > > 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 Thanks! > > 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? I'd certainly like to aim at pushing it upstream, yes - though obviously the bits about including it on OVMF/AAVMF builds should be conditionalized; I can see why you wouldn't want it in builds deploying on customer guests. That'll be done in the next revision of the patch as well. -- Peter ------------------------------------------------------------------------------ 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
