On Wed, Aug 14, 2019 at 09:26:47AM -0700, Andrew Fish via Groups.Io wrote: > Every runtime driver I've every seen usually works like this: > 1) Loads as an EFI driver and uses EFI Boot Services in its constructor (gBS, > gDS, AllocatePool(), etc.) > 2) You use the EFI Boot Service to register the ExitBootServices Event. > 3) SetVirtualAddressMap event fires and converts all the pointers > 4) After all the ExitBootServices events have been processed the DXE Runtime > driver re-relocates the Runtime Driver > 5) The next code that runs is a call from the kernel virtual mapping, and the > system is at runtime > > It is important to remember that when gRT->SetVirtualAddressMap() is > called by the OS Loader (or early kernel) that gBS->ExitBootServices() > has already been called. So by the time you get 3) almost all of EFI > is gone. The only services that remain are gRT. Note you find the > location of gRT by using the gST passed into the entry point of the > driver. So here is lies the problem the entry point is passed a Handle > (EFI Boot Services concept) and a pointer to gST (another boot > services table). So you can't really reload a module and expect it to > work.
Indeed. My hope was that the particular VariableRuntimeDxe module was just a bunch of self-contained code that accesses all the data it needs through the arguments it's passed. Having now looked at the code, this assumption is certainly wrong: the module depends on a lot of private data that is initialized at boot services time. Thanks and sorry for the noise, Roman. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45831): https://edk2.groups.io/g/devel/message/45831 Mute This Topic: https://groups.io/mt/32686575/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
