Boot Services là gì?

Boot Services là tập hợp các API của UEFI chỉ hợp lệ trong boot time - trước khi OS loader gọi ExitBootServices(). Toàn bộ Boot Services được truy cập qua con trỏ toàn cục gBS (EFI_BOOT_SERVICES *).

DXE driver, UEFI application, và BDS đều dùng Boot Services để làm mọi việc: allocate memory, install/locate protocol, tạo event, load image và connect controller.

Boot Services rất tiện, nhưng có hạn sử dụng. Sau ExitBootServices(), gBS không còn hợp lệ - mọi code dùng Boot Services sau điểm này là undefined behavior.

Các nhóm API chính

Memory type và lifetime

Khi allocate memory bằng Boot Services, memory type quyết định lifetime của vùng đó:

VOID *Buffer;

// EfiBootServicesData - chỉ tồn tại đến ExitBootServices()
gBS->AllocatePool(EfiBootServicesData, Size, &Buffer);

// EfiRuntimeServicesData - cần tồn tại sau ExitBootServices()
// Runtime driver dùng type này để OS không reclaim
gBS->AllocatePool(EfiRuntimeServicesData, Size, &Buffer);

Lỗi phổ biến nhất là allocate với EfiBootServicesData rồi lưu pointer vào structure dùng ở runtime path. Sau ExitBootServices(), vùng memory boot services có thể bị OS reclaim.

EfiRuntimeServicesData chỉ nên dùng cho dữ liệu thật sự thuộc runtime service hoặc runtime driver. Không nên dùng runtime memory type chỉ vì muốn “giữ pointer lâu hơn” - vùng này sẽ xuất hiện trong memory map và ảnh hưởng đến OS. Memory này cũng có thể liên quan đến SetVirtualAddressMap() nếu runtime code giữ pointer sau khi OS chuyển sang virtual address mode.

Event và TPL

Boot Services có cơ chế Event để xử lý callback và async notification. Mọi event chạy ở một TPL (Task Priority Level) nhất định:

EFI_EVENT Event;

// Tạo event sẽ signal khi protocol mới xuất hiện
gBS->CreateEvent(
       EVT_NOTIFY_SIGNAL,
       TPL_CALLBACK,          // TPL của callback
       MyNotifyFunction,
       NULL,
       &Event
     );

// Đăng ký với một protocol GUID
VOID *Registration;
gBS->RegisterProtocolNotify(&gEfiBlockIoProtocolGuid, Event, &Registration);

// Cleanup khi không cần
gBS->CloseEvent(Event);

TPL quan trọng để hiểu thứ tự xử lý và reentrancy:

Khi code đang chạy ở TPL cao hơn, event ở TPL thấp hơn sẽ bị defer đến khi TPL giảm xuống.

Ở TPL cao, callback nên chạy ngắn và tránh làm việc nặng. Không nên wait lâu, polling phức tạp, hoặc gọi các Boot Services không phù hợp với TPL hiện tại. Nếu cần xử lý nhiều, nên defer sang ngữ cảnh TPL thấp hơn.

Boot Services và các bài đã học

Boot Services là nền tảng kết nối tất cả những gì đã học:

Protocol Services  → gBS->InstallProtocolInterface / LocateProtocol / OpenProtocol
Handle Database    → gBS->LocateHandleBuffer / ProtocolsPerHandle / OpenProtocolInformation
Driver Binding     → gBS->ConnectController / DisconnectController
DXE Dispatcher     → load/dispatch driver trong môi trường DXE nơi Boot Services đã sẵn sàng

Mọi thao tác với handle database, protocol install/locate, driver binding đều đi qua gBS. Đây là lý do tại sao hiểu Boot Services là hiểu DXE.

Phân biệt Boot Services và Runtime Services

	Boot Services (gBS)	Runtime Services (gRT)
Hợp lệ khi	Trước ExitBootServices()	Trước và sau ExitBootServices()
Dùng cho	Driver, BDS, OS loader	Variable, time, reset, runtime firmware services
Memory type	EfiBootServicesData/Code	EfiRuntimeServicesData/Code
Ví dụ	AllocatePool, LocateProtocol	GetVariable, ResetSystem

Khi nào cần quan tâm đến Boot Services?

Hầu như mọi DXE driver đều dùng Boot Services - không thể tránh. Nhưng có một số tình huống cụ thể cần chú ý đặc biệt:

• Runtime driver phải tránh gBS sau ExitBootServices()
• OS loader phải lấy memory map rồi gọi ExitBootServices() đúng cách
• Driver leak event hay memory nếu không CloseEvent và FreePool khi cleanup
• Code dùng EfiBootServicesData nhưng pointer được giữ lâu hơn boot time

Checklist Boot Services

• Code có chạy trước ExitBootServices() không - nếu sau thì không được dùng gBS.
• Memory allocate với EfiBootServicesData có bị dùng sau ExitBootServices() không?
• Event đã tạo có được CloseEvent() khi không còn cần không?
• Protocol đã OpenProtocol có được CloseProtocol() trong Stop() không?
• Runtime driver có path nào vô tình gọi gBS không?
• Memory type có phù hợp với lifetime mong đợi của buffer không?

Câu hỏi tự kiểm tra

1. Boot Services được truy cập qua pointer nào?
2. Điểm nào đánh dấu kết thúc validity của Boot Services?
3. EfiBootServicesData và EfiRuntimeServicesData khác nhau ở lifetime thế nào?
4. TPL dùng để làm gì trong Event model?
5. Tại sao runtime driver không được gọi gBS->LocateProtocol()?
6. Driver có thể dùng Boot Services trong Stop() không?
7. Nếu event notify bị leak, debug như thế nào?

Bài liên quan

• Runtime Services là gì?
• ExitBootServices là gì?
• Protocol là gì?
• Handle Database là gì?
• DXE là gì?

Nguồn tham khảo public

• UEFI Specification 2.11 - Boot Services
• EDK II MdePkg - UefiBootServicesTableLib.h
• EDK II MdePkg - UefiSpec.h

Thấy nội dung này hữu ích?

Lưu lại hoặc chia sẻ cho người cũng đang học firmware, BIOS/UEFI và embedded systems.

Chia sẻ Copy link

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Ghi chú/BIOS Terms

DXE là gì trong UEFI?

DXE là phase firmware sau PEI, nơi driver được dispatch, protocol được install và Boot Services trở nên đầy đủ. DXE xây dựng môi trường để BDS có thể chọn và khởi động OS.

4 tháng 1, 2025Đọc tiếp →

Ghi chú/BIOS Terms

TPL và Event trong UEFI là gì?

TPL kiểm soát mức ưu tiên callback trong UEFI. Event là cơ chế notify/signal/wait. Hiểu TPL giúp debug deadlock, callback sai thời điểm và timer không fire.

14 tháng 5, 2024Đọc tiếp →

Ghi chú/BIOS Terms

Protocol trong UEFI là gì?

Protocol là interface install lên handle trong DXE, cho phép driver giao tiếp không phụ thuộc implementation. Hiểu Protocol giúp debug driver binding và locate fail.

15 tháng 7, 2024Đọc tiếp →

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác