Linux kernel cân nhắc loại bỏ KGDB: QEMU có đủ thay thế?

Ngày 28/10/2026, Peter Zijlstra gửi lên kernel mailing list một patch loại bỏ hoàn toàn KGDB khỏi Linux kernel. Đối với phần lớn lập trình viên phần mềm máy chủ, đây có thể chỉ là việc dọn dẹp mã nguồn cũ. Đối với người phát triển firmware trên phần cứng thật, vấn đề đặt ra khác hơn: nếu KGDB không còn, những công cụ nào có thể thay thế?

Khái niệm KGDB

KGDB là debugger tích hợp trong kernel, được đưa vào Linux từ phiên bản 2.6.26 (2008) [1]. Công cụ này cho phép dùng GDB để gỡ lỗi kernel đang chạy theo cách tương tự gỡ lỗi chương trình user-space: đặt breakpoint, xem biến, thanh ghi và call stack.

Cách dùng điển hình cần hai máy: máy target chạy kernel cần gỡ lỗi và máy host chạy GDB, kết nối với nhau qua serial hoặc mạng. Mô hình này gần gũi với lập trình nhúng, nơi board thường có sẵn cổng serial. Chi tiết cấu hình nằm ở technote KGDB & kdb.

KDB (debugger dạng console) được xây dựng trên cùng debug core với KGDB, nên thay đổi lớn ở KGDB có thể ảnh hưởng đến KDB. Các bài báo chưa nêu rõ patch có loại bỏ cả KDB hay không.

Tác giả đề xuất

Peter Zijlstra là lập trình viên Linux lâu năm của Intel [2]. Theo tiểu sử tại RT Summit 2017 [4], ông là đồng maintainer của scheduler, perf events và hạ tầng locking, đồng thời làm việc với PREEMPT_RT; tên ông cũng có ở mục SCHEDULER trong MAINTAINERS (bản cập nhật 2019 [5]). Các mảng này đều nhạy với NMI và timing, nên nhận xét của ông về KGDB trong NMI context xuất phát từ kinh nghiệm trực tiếp. Tuy vậy, uy tín không thay cho dữ liệu sử dụng: chính ông cho biết lần cuối thử KGDB là khoảng 20 năm trước. Chức danh dựa trên nguồn từ 2016 đến 2019, chưa kiểm chứng với hiện trạng 2026.

Lập luận của Zijlstra

Lập luận chính của Zijlstra là KGDB ít được sử dụng, trong khi ảo hóa hiện đã phổ biến. Theo Phoronix [2], ông cho rằng gần như không còn lý do để dùng KGDB thay cho gdb-server của QEMU. Trong patch message, ông cũng mô tả KGDB là làm "some horrible things" [3].

Ngoài lý do ít người sử dụng, ba vấn đề kỹ thuật được nêu ra:

• NMI context: KGDB thường nằm lâu trong ngắt không che được (NMI), có thể làm sai lệch mã timekeeping và kích hoạt watchdog.
• Code patching và breakpoint: phần này liên tục phát sinh vấn đề. Theo ông, nỗ lực sửa mã breakpoint cho tương thích với KGDB là không xứng đáng, nên loại bỏ là lựa chọn hợp lý nhất.
• Kinh nghiệm cá nhân: ông cho biết lần cuối cùng dùng thử KGDB cách đây khoảng 20 năm và chưa dùng lại kể từ đó.

Đối với lỗi phụ thuộc phần cứng, ông đề xuất sử dụng device pass-through, giả lập thiết bị (emulation) hoặc gỡ lỗi bằng printk().

Phía muốn giữ lại

Một số nhà phát triển phản đối bằng các tình huống thực tế, theo tổng hợp của PBX Science [3]:

• Lỗi phụ thuộc phần cứng cụ thể mà máy ảo có thể không tái hiện được.
• Máy chủ vật lý lớn bị treo hoặc ngừng phản hồi, khó dựng lại trên máy ảo.
• Kỹ sư sử dụng KDB để kiểm tra trạng thái từng CPU tại hiện trường.

Các bài báo không nêu tên người phản đối nào, và PBX Science lưu ý rằng đây mới chỉ là các trường hợp riêng lẻ, chưa phản ánh mức độ sử dụng thực tế của KGDB hay KDB. Cuộc thảo luận vì vậy vẫn thiếu số liệu cụ thể, và các use case thực tế sẽ có giá trị đối với quyết định cuối cùng.

So sánh KGDB và QEMU gdb-server

Hình 1. Hai mô hình debug: KGDB trên board thật và QEMU gdb-server trên máy ảo.

KGDB yêu cầu hai máy kết nối qua serial hoặc mạng, và mã debugger chạy ngay trong kernel đang được gỡ lỗi. Ngược lại, gdb-server của QEMU điều khiển CPU ảo từ bên ngoài guest. Để sử dụng, khởi động guest ở trạng thái tạm dừng bằng -S, kết nối GDB qua cổng TCP 1234 bằng -s, đồng thời chuẩn bị sẵn vmlinux khớp với kernel (cần lưu ý KASLR). Các script lx-symbols và lx-dmesg của kernel hỗ trợ thêm cho quy trình này [6][7]. Phương pháp này phù hợp với lỗi có thể tái hiện trong máy ảo, nhưng hạn chế hơn đối với ngắt thật, DMA, device reset hoặc hệ thống phần cứng rất lớn.

Góc nhìn trạm gốc 5G: chọn công cụ theo kịch bản lỗi

Với firmware của thiết bị trạm gốc 5G chạy trên phần cứng nhúng chuyên dụng, nhiều lỗi khó nằm ở những phần máy ảo không mô phỏng được: ngắt thật, DMA, giao tiếp với các khối phần cứng chuyên dụng và jitter của datapath thời gian thực. Bảng dưới đây trình bày cách lựa chọn công cụ theo kịch bản lỗi khi không còn KGDB.

Kịch bản lỗi	Công cụ phù hợp	Điểm mạnh	Hạn chế
Logic kernel/driver thuần phần mềm, tái hiện được trong VM	QEMU gdb-server	Debugger nằm ngoài guest, không cần board	Không có phần cứng thật
Kernel panic/oops đã xảy ra trên board	kdump + crash	Phân tích post-mortem trên vmcore	Không dừng được hệ thống đang chạy
Race, latency, jitter trong datapath	ftrace, trace-cmd, perf	Theo dõi mà ít can thiệp thời gian chạy hơn breakpoint	Phải bật trước khi lỗi xảy ra
Treo cứng, cần dừng CPU và xem trạng thái	JTAG + OpenOCD	Không phụ thuộc kernel còn sống	Cần cổng JTAG và probe, không luôn có trên thiết bị đã triển khai
Lỗi liên quan ngắt thật, DMA, device reset	Log phần cứng + printk, JTAG khi cần	Gần với hiện tượng thật	Phải tự dựng môi trường, khó lặp lại
Debug tương tác trên board qua serial/mạng	KGDB/KDB	Chỉ cần serial hoặc mạng, không cần phần cứng debug riêng	Các hạn chế như Zijlstra nêu; đang bị đề xuất gỡ

Theo đánh giá của tác giả, điểm khác biệt đáng chú ý nằm ở dòng cuối: trong số các công cụ ở bảng, KGDB là công cụ duy nhất cho phép dừng và kiểm tra kernel đang chạy trên board mà không đòi hỏi phần cứng debug riêng. Nếu thiết bị triển khai không để lộ cổng JTAG, khoảng trống này sẽ xuất hiện khi KGDB bị loại bỏ. Bảng là tổng hợp của tác giả, chưa được kiểm chứng trên một nền tảng cụ thể.

Lộ trình có thể xảy ra

Hiện tại, đây mới là một đề xuất đang được thảo luận, chưa được merge và chưa có lịch trình cụ thể. Trong thread có ý kiến nên thực hiện theo hai bước: tắt KGDB qua các tùy chọn Kconfig trước, sau vài phiên bản kernel mới xóa mã nguồn, để những người còn sử dụng có thời gian phản hồi.

Nếu lộ trình này được chọn, khoảng thời gian đệm sẽ hữu ích cho các nhóm đang dùng KGDB trên thiết bị thật: rà soát quy trình debug hiện tại, đánh giá khả năng thay thế bằng JTAG, kdump hoặc tracing, và ghi nhận những trường hợp chưa thể thay thế.

Kết luận

Theo đánh giá của tác giả, nhận định của Zijlstra về chi phí bảo trì KGDB có cơ sở, và với phần lớn nhà phát triển, QEMU đã đáp ứng đủ nhu cầu. Tuy nhiên, đề xuất này cần được cân nhắc cùng với nhu cầu của những người gỡ lỗi trên phần cứng mà máy ảo không mô phỏng được. Giai đoạn thảo luận hiện nay là thời điểm các maintainer cần được cung cấp bằng chứng thực tế.

Những ai đang dùng KGDB hoặc KDB trên thiết bị thật nên nêu use case trên thread LKML, gồm loại board, loại lỗi và lý do các công cụ thay thế chưa đáp ứng được. Câu hỏi còn lại là nếu KGDB biến mất, quy trình gỡ lỗi kernel trên board thật sẽ dựa vào công cụ nào.

Tài liệu tham khảo

Phần diễn biến của đề xuất dựa trên hai bài báo và chưa được đối chiếu với thread LKML gốc. Phần giới thiệu tác giả đề xuất dựa trên các nguồn công khai của Linux Foundation và kernel mailing list. Các tài liệu kernel và QEMU dùng cho phần khái niệm và cách dùng chưa được đối chiếu lại tại thời điểm viết.

1. Kernel docs, Using kgdb, kdb and the kernel debugger internals
2. Phoronix, Linux Kernel Developers Considering Removal Of KGDB Debugging Functionality, 28/10/2026
3. PBX Science, Linux Kernel Developers Weigh Removing KGDB, the Kernel's Source-Level Debugger, cập nhật 31/10/2026
4. Linux Foundation, tiểu sử Peter Zijlstra tại RT Summit 2017
5. LKML, cập nhật MAINTAINERS cho sched và perf (2019)
6. Kernel docs, Debugging kernel and modules via gdb
7. QEMU docs, GDB usage