BIOS Terms Stable

SMI là gì?

SMI là interrupt đưa CPU vào SMM để chạy handler. Có nhiều nguồn SMI: SW, GPIO, timer, chipset. Hiểu SMI giúp debug latency spike và SMM communication.

Cập nhật 5 phút đọc
BIOS Terms cover

SMI (System Management Interrupt) là interrupt đặc biệt đưa CPU vào SMM để chạy SMM handler. Có nhiều nguồn có thể trigger SMI: software, chipset event, GPIO, timer hoặc power event.

Nếu SMM là “chế độ”, thì SMI là “cửa vào”.

Các nguồn SMI phổ biến

Mục Giá trị Ghi chú
SW SMI Kích hoạt bằng software Thường dùng cho SMM communication. Trên nhiều Intel x86 platform, software có thể ghi value vào port 0xB2 để trigger SW SMI nếu nguồn này được enable.
GPIO SMI Kích hoạt từ pin/event GPIO Liên quan đến platform event, ví dụ button press, lid open/close.
Timer/Periodic SMI Trigger theo chu kỳ Firmware set timer để SMI fire định kỳ. Cần cẩn thận vì ảnh hưởng latency toàn hệ thống.
Power/Thermal SMI Kích hoạt từ power/thermal event Chipset báo firmware qua SMI khi có power state change hoặc temperature alert.
Chipset/PCH SMI Kích hoạt từ chipset source khác I/O trap, PCI event, EC event, hoặc các source platform-specific.

Software SMI - cách thường gặp để software trigger SMI trên x86

Trên x86, một cách thường gặp để DXE driver giao tiếp với SMM handler là Software SMI qua port 0xB2:

// DXE side: trigger SW SMI với value 0x42
// Nếu SW SMI source được enable, CPU sẽ enter SMM
// và SMM dispatcher gọi handler match với value này
IoWrite8(0xB2, 0x42);

// Hoặc dùng EFI_SMM_COMMUNICATION_PROTOCOL thay vì trigger trực tiếp
// (cách EDK II khuyến nghị - firmware handle SMI bên dưới)
SmmCommunication->Communicate(SmmCommunication, Buffer, &Size);

Trên nhiều Intel x86 platform, port 0xB2 thường được dùng như APM Control Port / SW SMI trigger. Ghi một byte vào port này có thể sinh SW SMI nếu chipset/firmware đã enable nguồn đó. Giá trị ghi vào port thường được dùng để match SW SMI handler tương ứng, ví dụ qua SwSmiInputValue.

Trong EDK II, driver thường nên dùng EFI_SMM_COMMUNICATION_PROTOCOL thay vì tự ghi port 0xB2, trừ khi đang viết code platform-specific hoặc debug thấp tầng.

SMI source và clear sequence

Sau khi SMM handler xử lý xong, phải clear SMI source trước khi RSM - nếu không, một số source sẽ trigger SMI lại ngay lập tức:

// Pseudo-code: register/offset phụ thuộc PCH/platform
// Đọc và clear ICH/PCH SMI status register (write-1-to-clear pattern)
UINT32 SmiSts = IoRead32(ACPI_BASE + SMI_STS_OFFSET);
IoWrite32(ACPI_BASE + SMI_STS_OFFSET, SmiSts);

// Cách clear phụ thuộc chipset/source.
// Với timer/GPIO/PCH source, handler thường phải clear status bit tương ứng.
// Một số source được framework/platform xử lý; handler cần biết rõ source của mình.

Write-1-to-clear là pattern phổ biến với SMI status register - ghi 1 vào bit tương ứng để xóa, không phải ghi 0.

EDK II: đăng ký SW SMI handler

Trong EDK II, SMM driver dùng EFI_SMM_SW_DISPATCH2_PROTOCOL để đăng ký handler cho một SW SMI value cụ thể:

EFI_SMM_SW_DISPATCH2_PROTOCOL  *SwDispatch;
EFI_SMM_SW_REGISTER_CONTEXT    SwContext;
EFI_HANDLE                      DispatchHandle;

// Locate protocol qua gSmst
gSmst->SmmLocateProtocol(
         &gEfiSmmSwDispatch2ProtocolGuid,
         NULL,
         (VOID **)&SwDispatch
         );

// Đăng ký handler cho SW SMI value 0x42
SwContext.SwSmiInputValue = 0x42;
SwDispatch->Register(
              SwDispatch,
              MySwSmiHandler,
              &SwContext,
              &DispatchHandle
              );

Khi DXE driver ghi 0x42 vào port 0xB2, handler MySwSmiHandler sẽ được gọi trong SMRAM.

Multi-core và SMI

Trên nhiều hệ thống multi-core, SMM infrastructure có cơ chế rendezvous:

  • Một hoặc nhiều CPU có thể nhận SMI tùy thiết kế CPU/chipset
  • Các AP có thể được đưa vào SMI rendezvous
  • BSP hoặc CPU được chọn chạy handler chính
  • Sau khi handler xong, các CPU resume bằng RSM

Điều này có nghĩa là nhiều core có thể bị giữ trong SMM/rendezvous cho đến khi handler xong - đây là lý do SMI có thể gây latency lớn trên hệ thống multi-core.

Debug liên quan SMI

Latency spike không rõ nguyên nhân → periodic SMI handler có thể đang chạy quá lâu. Đo bằng platform trace, performance counter, logic analyzer, hoặc công cụ profiling/hardware debug tùy môi trường. Trên OS, SMI thường chỉ thấy như latency gap khó giải thích.

SmmCommunication->Communicate() không return → SW SMI handler có thể đang block, deadlock, hoặc handler chưa được đăng ký đúng value.

SMI storm → một source SMI bị trigger liên tục vì handler không clear source/status bit đúng cách, gây CPU liên tục vào/ra SMM.

Checklist SMI

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

  1. SW SMI khác hardware SMI (GPIO, timer) ở điểm nào?
  2. Trên nhiều Intel x86 platform, port 0xB2 thường dùng để làm gì?
  3. Tại sao handler phải clear SMI source trước RSM?
  4. SMI storm xảy ra khi nào?
  5. Trên nhiều hệ thống multi-core, SMI rendezvous giữa BSP/AP thường hoạt động như thế nào?
  6. EFI_SMM_SW_DISPATCH2_PROTOCOL dùng để làm gì?

Bài liên quan

Nguồn tham khảo public

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.

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

SMM là gì?

SMM là chế độ CPU đặc biệt để firmware xử lý tác vụ nhạy cảm ngoài tầm kiểm soát OS. Hiểu SMM giúp debug variable write treo, flash fail và security issue.

Ghi chúSecurity / SMM / Firmware

SW SMI là gì?

Giải thích SW SMI: OUT 0xB2, command ID, SMM dispatch, handler registration, failure pattern và checklist debug bảo mật.

BlogBIOS / UEFI

SMM trong UEFI: System Management Mode từ góc debug

SMM không phải phase tuyến tính mà là isolated execution mode. Hiểu SMI trigger, SMRAM, handler timing, SmmReadyToLock và debug SetVariable không lưu được.

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