8.8 DXE Runtime Driver

Search…
A DXE runtime driver executes in both boot services and runtime services environments. This means the services that these modules produce are available before and after ExitBootServices() is called, including the time that an operating system is running. If SetVirtualAddressMap() is called, then modules of this type are relocated according to virtual address map provided by the operating system.
The DXE Foundation is considered a boot service component, so the DXE Foundation is also released when ExitBootServices() is called. As a result, runtime drivers may not use any of the UEFI Boot Services, DXE Services, or services produced by boot service drivers after ExitBootServices() is called.
A DXE runtime driver defines MODULE_TYPE as DXE_RUNTIME_DRIVER in the INF file. In addition, because the DXE runtime driver encounters SetVirtualAddressMap() during its life cycle, it may need to register an event handler for the event EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE.
8.8.1 INF File
Following is the example of [Defines] section for a driver named
SampleDriverRuntimeDxe. For DXE runtime driver, the MODULE_TYPE entry should be DXE_RUNTIME_DRIVER
1
[Defines]
2
  INF_VERSION = 0x00010005
3
  BASE_NAME   = SampleDriverRuntimeDxe
4
  FILE_GUID   = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
5
  MODULE_TYPE = DXE_RUNTIME_DRIVER
6
  ENTRY_POINT = SampleRuntimeDriverEntryPoint
7
​
8
[Depex] gSampleProtocolGuid
Copied!
Note: If module dependent on the new definitions and features in
EFI_BOOT_SERVICES/UEFI_RUNTIME_SERVICES-defined in UEFI specifications from version 2.1 forward-the hex version need to be given in INF file [Defines] section's UEFI_SPECFIICATION_VERSION field.
8.8.2 Handler for EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
DXE runtime drivers may need to be notified when the operating system calls SetVirtualAddressMap(). In this case, the DXE runtime driver must create a signal type event that is notified when SetVirtualAddressMap() is called by the operating system. This call allows the DXE runtime driver to convert pointers from physical addresses to virtual addresses.
The notification function for this type of event is not allowed to use any of the UEFI Boot Services, UEFI Console Services, or UEFI Protocol Services either directly or indirectly because those services are no longer available when SetVirtualAddressMap() is called.
Instead, this type of notification function typically uses ConvertPointer() to convert pointers within data structures that are managed by the DXE runtime driver from physical addresses to virtual addresses.
Template code for notification function and event registration is as follows:
1
//
2
// This is the global pointer which needs converting
3
//
4
VOID *gGlobalPointer;
5
VOID
6
EFIAPI
7
NotifySetVirtualAddressMap (
8
  IN EFI_EVENT Event,
9
  IN VOID *Context
10
)
11
{
12
  gRT->ConvertPointer (
13
         EFI_OPTIONAL_POINTER,
14
         (VOID **)&gGlobalPointer
15
         );
16
}
17
EFI_STATUS
18
EFIAPI
19
SampleRuntimeDriverInitialize (
20
  IN EFI_HANDLE ImageHandle,
21
  IN EFI_SYSTEM_TABLE *SystemTable
22
)
23
{
24
  EFI_STATUS Status;
25
  EFI_EVENT SetVirtualAddressMapEvent;
26
  //
27
  // TODO: Other initialization of entry point can be added here.
28
  //
29
  //
30
  // Here is just the sample of registration of
31
  // EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
32
  //
33
  Status = gBS->CreateEventEx (
34
                  EVT_NOTIFY_SIGNAL,
35
                  TPL_CALLBACK,
36
                  NotifySetVirtualAddressMap,
37
                  NULL, // Parameter Context can be passed here
38
                  &gEfiEventVirtualAddressChangeGuid,
39
                  &SetVirtualAddressMapEvent
40
                  );
41
  ASSERT_EFI_STATUS (Status);
42
}
Copied!
8.7 Handler for EVT_SIGNAL_EXIT_BOOT_SERVICES
8.9 DXE SAL Driver
Last modified 2yr ago
Copy link
Contents
8.8.1 INF File
8.8.2 Handler for EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE