Oni Ranger

Virtual Machine Monitor Kvm

2026-01-31T00:00:00+08:00

Virtual Machine Monitor với KVM và Rust (update: 2026-09-26)

Thử viết một VMM dựa trên KVM API bằng Rust trong đôi ngày cuối tuần.

I. Vài khái niệm cơ bản

Virtualization - ảo hóa

Về cơ bản thì ảo hóa là kỹ thuật mô phỏng lại môi trường phần cứng của hệ thống (trong các máy ảo - virtual machine). Kỹ thuật này tạo ra một lớp trừu tượng tương tự nhưng không đồng nhất với môi trường phần cứng đang host nó. Mỗi virtual machine (VM) có một môi trường tách biệt và có các “phần cứng” mong muốn của nó, mặc dù thực tế thì tất các các VM trên cùng một máy vật lý sẽ chia sẻ cùng một tài nguyên, và tài nguyên này được kiểm soát chặt chẽ bởi một phần mềm đặc biệt của hệ thống gọi là hypervisor. Ảo hóa giải quyết được nhiều vấn đề của hệ thống tính toán:

Sử dụng tài nguyên hiệu quả: Thay vì mỗi server chỉ chạy 1 OS và sử dụng 1 phần nhỏ của CPU, chúng ta có thể chạy hàng chục VM trên đó và sử dụng phần lớn tài nguyên của hệ thống.
Tạo tra một môi trường cô lập với phần còn lại của hệ thống. Mỗi máy ảo là một bản giả lập bằng phần mêm của hệ thống máy tính, nếu OS của một VM bị crash thì nó chỉ ảnh hưởng đến chính VM đó.
Linh hoạt: Việc khởi tạo một máy ảo mới diễn ra nhanh chóng và các VMM hiện nay đều cho phép migrate máy ảo giữa các host mà không có downtime.
Có khả năng chạy các phần mềm/hệ điều hành cũ.

Virtual machine monitor (VMM) và hypervisor

VMM là một phần mềm tạo và quản lý máy ảo, chằng hạn như Virtual Box, Qemu, HyperV (desktop app) Thông thường VMM và hypervisor thường được dùng lẫn lộn, mặc dù vậy, theo định nghĩa nguyên thủy thì:

VMM tập trung vào khía cạnh quản lý và giám sát.

Hypervisor nhấn mạnh rằng “thứ này” có phân quyền cao hơn so với Kernel: Hypervisor vs supervisor. Còn theo như cái sự hiểu biết của bản thân tui, thì hypervisor là component thực hiện việc ảo hóa VCPU.

Hypervisor Type 1 và Type 2

Các hypervisor được chia làm hai loại

Type 1: Bare-metal Hypervisor

Chạy trực tiếp trên phần cứng, không thông qua việc sử dụng bất kỳ hệ điều hành nào, nó thực hiện đầy đủ các chức năng của hệ điều hành.

┌─────────┐ ┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │ │  VM 3   │
│ (Guest) │ │ (Guest) │ │ (Guest) │
└────┬────┘ └────┬────┘ └────┬────┘
   │           │           │
   └───────────┴───────────┘
               │
   ┌───────────▼───────────┐
   │   Type 1 Hypervisor   │
   │ (runs on bare metal)  │
   └───────────┬───────────┘
               │
   ┌───────────▼───────────┐
   │       Hardware        │
   └───────────────────────┘

Ví dụ: VMware ESXi, Microsoft Hyper-V, Xen, KVM (with Linux as the host) Do hypervisor loại 1 chạy trực tiếp trên phần cứng nên nó mang lại hiệu năng cao hơn và an toàn hơn (do nó không chứa các component thừa thãi của một OS thông thường)

Type 2:

Là một phần mềm sử dụng lại sức mạnh của một OS thông thường

┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │
│ (Guest) │ │ (Guest) │
└────┬────┘ └────┬────┘
   │           │
   └─────┬─────┘
         │
┌──────────▼──────────┐
│  Type 2 Hypervisor  │  ◄── Runs as an application
│  (VirtualBox, etc.) │
└──────────┬──────────┘
         │
┌──────────▼──────────┐
│   Host OS (Windows, │  ◄── Regular operating system
│   macOS, Linux)     │
└──────────┬──────────┘
         │
┌──────────▼──────────┐
│      Hardware       │
└─────────────────────┘

Ví dụ: VirtualBox (TCG), VMware Workstation, Parallels Desktop, QEMU (TCG no KVM) Mặc dù dễ dàng cài đặt và có khả năng tận dụng các phần mềm khác chạy trên cùng hệ điều hành tuy nhiên hypervisor loại này mang lại overhead và ít an toàn hơn.

KVM

KVM hoạt động như một kernel module của Linux kernel, được merge vào kernel từ năm 2007. Nó tận dụng khả năng ảo hóa hệ thống của intel CPU - Vtx (sau này nó có support thêm AMD-V, S390, ARM nữa) để tạo ra các VCPU với overhead gần như bằng 0.

Intel Vtx

là một extension của intel cpu:

CPU có một privilege level mới gọi là “Guest mode”
Guest mode chạy trực tiếp trên CPU ở tốc độ gần như native.
Đối với một số priviledge instruction mà Guest mode không được phép thực hiện thì CPU sẽ tự động chuyển về host mode và tạo ra exception để hypervisor xử lý.
KVM API

KVM sử dụng ioctl thông qua /dev/kvm để cho phép VMM tạo và quản lý máy ảo. KVM chỉ emulate một vài peripheral quan trọng, còn lại các thiết bị ngoại vi khác phải được emulate bởi VMM, ví dụ như block, network, etc…

Theo như định nghĩa ở trên thì KVM là một đứa nhập nhằng không biết xếp vô loại 1 hay 2, nhưng quan trọng là nó chạy được :v

┌─────────┐ ┌─────────┐   ┌────────────────┐
│  VM 1   │ │  VM 2   │   │ Regular Apps   │
│ (Guest) │ │ (Guest) │   │ (Firefox, etc) │
└────┬────┘ └────┬────┘   └───────┬────────┘
     │           │                │
     └─────┬─────┘                │
           │                      │
┌──────────▼──────────────────────▼────────┐
│                Linux Kernel              │
│  ┌─────────────┐                         │
│  │ KVM Module  │  ◄── Turns Linux into   │
│  │             │      a hypervisor       │
│  └─────────────┘                         │
└──────────────────────┬───────────────────┘
                       │
┌──────────────────────▼───────────────────┐
│   Hardware (Intel VT-x / AMD-V)          │
└──────────────────────────────────────────┘

II. Tự viết VMM bằng Rust.

GITHUB

Thực tế thì việc viết một VMM sử dụng Rust khá là đơn giản bằng cách sử dụng các crate có sẵn của rust-vmm, tuy nhiên do mục tiêu học tập và tìm hiểu, mình sẽ không sử dụng các wrapper/helper của rust-vmm, thay vào đó sẽ sử dụng raw libc function để tương tác với kvm. Tuy vậy, việc viết/gen lại các hằng số cơ bản khác mất thời gian, nên đối với các hằng số, mình sẽ sử dụng lại định nghĩa sẵn của rust-vmm. Về cách sử dụng của KVM API, trên LWN đã có một bài hướng dẫn khá đầy đủ Using KVM API . Cơ bản thì nó có mấy bước sau:

S1: Mở KVM handle (/dev/kvm) để lấy descriptor, thông qua fd này, vmm có thể tương tác với KVM.
S2: Tạo VM bằng cách sử dụng KVM_CREATE_VM ioctl trên kvm fd vừa mở.
S3: Cung cấp memory region cho VM để sử dụng.
S4: Khởi tạo và config các VCPU. (mình chỉ có 1 thôi)
S5: Load guest code vào memory (vùng memory đã cấp phát ở S3).
S6: Handle các VM exit event. Bây giờ sẽ đi vào các bước cụ thể
Bước 1: Lấy file descriptor của KVM handle và khởi tạo VM

Việc lấy File descriptor có thể được thực hiện thông qua hàm open() của libc crate:

 
     let kvm_path = CString::new("/dev/kvm")?;
     let kvm_fd = unsafe { libc::open(kvm_path.as_ptr(), O_RDWR) };

Mình cũng tạo ra một struct mới để giữ file descriptor này nhằm tiện lợi hơn trong việc sử dụng:

 
struct Kvm {
    fd: c_int,
}

impl Kvm {
    fn new() -> Result<Self> {
        let kvm_path = CString::new("/dev/kvm")?;
        let kvm_fd = unsafe { libc::open(kvm_path.as_ptr(), O_RDWR) };

        if kvm_fd >= 0 {
            Ok(Self { fd: kvm_fd })
        } else {
            Err(io::Error::last_os_error()).context("failed to open /dev/kvm")
        }
    }
}

Ở đây, mình đã lưu fd vào một trường fd của struct Kvm, tuy nhiên, do đây là raw libc code nên nó không tận dụng được các tính năng safety của Rust để tự động gọi close() khi object đi hết vòng đời. Một cách để khắc phục điều này là implement Drop cho struct KVM

 
impl Drop for Kvm {
    fn drop(&mut self) {
        unsafe {
            libc::close(self.fd);
        }
    }
}

Dù vậy, cách này trông không ngầu, không thông dụng cho lắm, thay vào đó, thường ta sẽ sử dụng OwnedFd để wrap raw file descriptor, OwnedFd đảm bảo rằng file sẽ được close() bởi nó ở cuối vòng đời và không một thực thể nào khác có thể close() file descritor nó đang sở hữu ngoài nó. Cấu trúc Kvm được update thành:

 
struct Kvm {
    fd: OwnedFd,
}

impl Kvm {
    fn new() -> Result<Self> {
        let kvm_path = CString::new("/dev/kvm")?;
        let kvm_fd = unsafe { libc::open(kvm_path.as_ptr(), O_RDWR) };

        if kvm_fd >= 0 {
            Ok(Self {
                fd: unsafe { OwnedFd::from_raw_fd(kvm_fd) },
            })
        } else {
            Err(io::Error::last_os_error()).context("failed to open /dev/kvm")
        }
    }
}

Ngoài ra struct Kvm còn một hàm setup() dùng để kiểm tra và xác thực KVM API version thông qua KVM_GET_API_VERSION (xem trên github) Sau khi đã có được KVM fd, chúng ta có thể khởi tạo một VM thông qua ioctl KVM_CREATE_VM:

 
let fd = unsafe { ioctl(kvm.fd.as_raw_fd(), KVM_CREATE_VM, 0) };

Để thuận tiện cho việc sử dụng, một struct cũng được định nghĩa để giữ các biến liên quan đến một VM:

 
pub struct VM {
    kvm: Kvm,
    pub fd: OwnedFd,
}
impl VM {
     pub fn new() -> Result<Self> {
          let kvm = Kvm::new()?;
          kvm.setup()?;
          let fd = unsafe { ioctl(kvm.fd.as_raw_fd(), KVM_CREATE_VM, 0) };
          // ... create VM instance
     }
}

tương tự như đối với KVM handle, nếu KVM_CREATE_VM thành công, file descriptor trả về sẽ được lưu vào trường fd của struct VM

Bước 2: Memory cho VM

Một máy ảo cần RAM. Nhưng khác với máy vật lý, nơi RAM là phần cứng, “RAM” của máy ảo thực chất chỉ là một vùng bộ nhớ của máy host mà chúng ta dành riêng cho máy guest sử dụng.

Điểm mấu chốt là: địa chỉ vật lý của guest không phải là địa chỉ vật lý của host. Khi guest truy cập địa chỉ 0x1000, nó không được phép truy cập trực tiếp vào bộ nhớ của host tại địa chỉ đó. Thay vào đó, KVM sẽ dịch các địa chỉ vật lý của guest sang các địa chỉ ảo của host thông qua một cơ chế ánh xạ (mapping) do chúng ta cung cấp.

Guest Virtual Address (GVA)
        ↓  (guest page table)
Guest Physical Address (GPA)
        ↓  (EPT / NPT)
Host Physical Address (HPA)

Chúng ta cần cung cấp địa chỉ vùng nhớ dự định sử dụng cho VM với KVM handle, thông qua ioctl, nhưng trước hết mình sẽ define một struct để việc quản lý và giải phóng vùng nhớ này được dễ dàng hơn memory.rs

 
pub(crate) struct MemoryWrapper {
    // NonNull verifies the pointer isn't null and is useful for optimization
    ptr: NonNull<c_void>,
    size: usize,
}

Mình viết ra vài method cho cấu trúc này, tuy nhiên có 2 method quan trọng nhất là new() dùng để tạo ra một vùng nhớ với kích thước yêu cầu thông qua hàm mmap của libc, và hàm drop() có tác dụng unmap vùng nhớ này ở cuối vòng đời mmap() với MAP_ANON|MAP_SHARED sẽ tạo ra vùng nhớ anonymous và cho phép share với thread khác.

 
 pub fn new(mem_size: u64) -> Result<Self> {
        let addr = unsafe {
            mmap(
                core::ptr::null_mut(),
                mem_size as usize,
                PROT_READ | PROT_WRITE,
                MAP_ANON | MAP_SHARED,
                -1,
                0,
            )
        };
    /*...*/
 }

// Release the memory automatically 
 impl Drop for MemoryWrapper {
    fn drop(&mut self) {
        unsafe {
            if munmap(self.ptr.as_ptr(), self.size) != 0 {
                eprintln!(
                    "Warning: munmap failed: {}",
                    std::io::Error::last_os_error()
                );
            } else {
                println!("Guest memory unmapped successfully.");
            }
        }
    }
}

Như đã đề cập ở trên, vmm cần thông báo cho kvm về vùng nhớ này thông qua một ioctl: KVM_SET_USER_MEMORY_REGION

 
impl VM {
// ....
    pub fn insert_memory_region(&mut self, slot: u32, flags: u32, 
                                mem_size: u64, guest_pa: u64) -> Result<()> {
        let host_memory = MemoryWrapper::new(mem_size)?;
        let mem_region = kvm_userspace_memory_region {
            slot,                           // Memory slot index
            flags,                          // KVM_MEM_LOG_DIRTY_PAGES, etc.
            userspace_addr: host_memory,    // Host virtual address
            memory_size: mem_size,          // Size of the region
            guest_phys_addr: guest_pa,      // Where guest sees this memory
        };

        let ret = unsafe {
            ioctl(self.fd.as_raw_fd(), KVM_SET_USER_MEMORY_REGION, &mem_region, 0)
        };
        // ...
    }
//....
}

kvm_userspace_memory_region là một struct được định nghĩa tuân theo quy định của KVM API:

 
#[repr(C)]
#[derive(Default)]
struct kvm_userspace_memory_region {
    pub slot: u32,                     // An index for this memory slot
    pub flags: u32,                    // Flags
    pub guest_phys_addr: u64,          // Where the guest thinks its RAM starts
    pub memory_size: u64,              // How many bytes of RAM
    pub userspace_addr: MemoryWrapper, // userspace_addr
}

Ở đây repr(C) có tác dụng yêu cầu rustc biểu diễn layout của struct này theo tiêu chuẩn của ngôn ngữ C, MemoryWrapper là struct ta đã định nghĩa ở trên.

Bước 3: VCPU cho VM

CPU là bộ phận tối quan trọng đối với một máy tính, và máy ảo cũng không phải ngoại lệ. Một trong những function quan trọng nhất trong quá trình khởi tạo VM là create_vcpu. Đây không chỉ đơn thuần là tạo ra một File Descriptor (FD), mà là thiết lập một vùng nhớ chia sẻ (shared memory) để chương trình Rust của chúng ta (ở userspace) và KVM (ở kernelspace) có thể “nói chuyện” với nhau mà không tốn quá nhiều chi phí copy dữ liệu. VCPU sẽ được định nghĩa như sau

 
pub struct VCpu {
    pub fd: OwnedFd,
    pub run_ptr: NonNull<kvm_run>,
    pub mmap_size: usize,
}

Khai báo cấu trúc kvm_run - đây là cấu tạo của message sẽ được trao đổi giữa kvm và vmm khi có exit event. Về cơ bản thì cấu trúc này được gen lại từ linux-header, thông tin cụ thể về các field và type của các field có thể xem ở kvm_run

 
#[repr(C)]
#[derive(Debug)]
struct kvm_run {
    pub request_interrupt_window: u8,
    pub immediate_exit: u8,
    pub padding1: [u8; 6],
    pub exit_reason: u32,
    pub ready_for_interrupt_injection: u8,
    pub if_flag: u8,
    pub flags: u16,
    pub cr8: u64,
    pub apic_base: u64,
    pub __bindgen_anon_1: kvm_run__bindgen_ty_1,
    pub kvm_valid_regs: __u64,
    pub kvm_dirty_regs: __u64,
    pub s: kvm_run__bindgen_ty_2,
}

Trước khi tạo VCPU, chúng ta cần biết cấu trúc giao tiếp kvm_run sẽ chiếm bao nhiêu bộ nhớ. Kích thước này không cố định mà phụ thuộc vào kiến trúc CPU.

 
let map_size = unsafe { ioctl(self.kvm.fd.as_raw_fd(), KVM_GET_VCPU_MMAP_SIZE, 0) };

Nếu bước này thất bại (map_size < 0), chúng ta không thể tiếp tục vì không biết phải cấp phát bao nhiêu RAM để giao tiếp với kernel. Tiếp theo, tạo VCPU bằng KVM_CREATE_VCPU ioctl, tương tự như với VM và KVM handle, kết quả trả về là một fd

 
let vcpu_fd = unsafe { ioctl(self.fd.as_raw_fd(), KVM_CREATE_VCPU, 0) };

Đây là đoạn code quan trọng nhất. Chúng ta sử dụng mmap để ánh xạ vùng nhớ của kernel (nơi chứa trạng thái VCPU) vào không gian địa chỉ của tiến trình Rust hiện tại. Tại sao phải làm vậy? Cấu trúc kvm_run chứa thông tin cực kỳ quan trọng như: Tại sao VM dừng lại? (Exit Reason), dữ liệu I/O, trạng thái thanh ghi,… Thay vì dùng syscall để copy dữ liệu này ra vào liên tục (rất chậm), mmap cho phép cả User và Kernel cùng đọc/ghi trực tiếp vào một vùng RAM.

 
let addr = unsafe {
    mmap(
        core::ptr::null_mut(),
        map_size as usize,
        PROT_READ | PROT_WRITE, // Cho phép đọc và ghi
        MAP_SHARED,             // Quan trọng: Thay đổi sẽ được thấy bởi cả 2 phía
        vcpu_fd,
        0,
    )
};

Cuối cùng, vẫn như cũ, ta đóng gói kết quả vào VCpu struct và lưu và VM để tận dụng Drop của rust cho RAII

 
self.vcpus_fd.push(VCpu {
    fd: unsafe { OwnedFd::from_raw_fd(vcpu_fd) }, // Quản lý vòng đời FD tự động
    run_ptr: kvm_run_mmap,                        // Con trỏ tới vùng nhớ chia sẻ
    mmap_size: map_size as usize,
});

Đến lúc này, nếu bạn load code vào vùng nhớ đã cấp phát (guest memory) và gọi KVM_RUN ioctl trên VCPU vừa tạo, thì VMM đã có thể thực thi code, tuy vậy, chỉ có thể là code 16bit. Cơ bản thì mình không biết làm gì với code 16bit ngoài in hello world, nên nó không được Kun, do đó mục tiêu của cái VMM này là load code 64bit. Nên ta cần chuyển đổi mode của VCPU từ 16 bit thành 64bit trước.

Bước 4: Bước vào thế giới 64bit.

Khi một CPU thuộc kiến trúc x86 được bật lên, nó luôn bắt đầu ở real mode. Đây là chế độ 16‑bit rất cũ, được giữ lại để tương thích với bộ vi xử lý Intel 8086. Tuy nhiên, các hệ điều hành hiện đại — như Linux 64‑bit — cần chạy trong long mode, tức chế độ 64‑bit. Vì vậy, trong quá trình khởi động, hệ thống phải thực hiện một loạt bước cấu hình để chuyển CPU từ real mode → protected mode → long mode. Chỉ khi vào long mode, CPU mới có thể chạy mã 64‑bit, truy cập không gian địa chỉ lớn, và sử dụng các tính năng hiện đại của kiến trúc x86‑64. Việc này yêu cầu:

Setup Page tables: 64bit mode yêu cầu page table phải được setup từ trước.
Cung cấp Segment descriptors.
4.1 Thiết lập Page Table (Identity Mapping)

Tại sao sử dụng Identity mapping? Trên x86, tất cả các OS (bao gồm cả Linux, mac, windows) đều phải sử dụng identity mapping ở early boot, bởi vì code ở early boot của OS được hardcode bằng địa chỉ vật lý. Tuy nhiên khi paging được enabled địa chỉ CPU nhìn thấy là địa chỉ ảo, do đó nếu ánh xạ này không phải là đồng nhất thì CPU sẽ không thể tìm được địa chỉ của câu lệnh tiếp theo trong code => Tripple fault -> Crash. Sau khi khởi động thành công, OS (có thể) sẽ thay thế page table ban đầu bằng page table của chính nó.

 
fn enter_long_mode(&self, mem: &mut [u8]) -> Result<()> {
    // Page table locations in guest physical memory
    let pml4_addr: u64 = 0x2000;  // Page Map Level 4
    let pdpt_addr: u64 = 0x3000;  // Page Directory Pointer Table
    let pd_addr: u64 = 0x4000;    // Page Directory

    // Page table entry flags
    let flags: u64 = (1 << 0)     // Present - page is valid
                   | (1 << 1);    // Read/Write - page is writable

    // PML4[0] points to PDPT
    // This single entry covers the first 512GB of address space
    let entry = pdpt_addr | flags;
    mem[0x2000..0x2008].copy_from_slice(&entry.to_le_bytes());
    
    // PDPT[0] points to PD
    // This single entry covers the first 1GB of address space
    let entry = pd_addr | flags;
    mem[0x3000..0x3008].copy_from_slice(&entry.to_le_bytes());
    
    // PD entries: each covers 2MB (using huge pages)
    // 512 entries × 2MB = 1GB of identity-mapped memory
    let huge_page_flags = flags | 0x80;  // PS bit = Page Size (2MB pages)
    for i in 0..512 {
        let phys_addr = i * 0x200000;    // 2MB aligned physical address
        let entry = phys_addr | huge_page_flags;
        let offset = 0x4000 + (i as usize * 8);
        mem[offset..offset + 8].copy_from_slice(&entry.to_le_bytes());
    }
    // ...
}

Chức năng của từng Bit CR0 (Control Register 0): PE (bit 0): Chuyển từ chế độ thực (real mode) sang chế độ bảo vệ (protected mode). PG (bit 31): Enable paging. Sau khi bật, VA sẽ được thông dịch thông qua page tables.

CR3 (Control Register 3): Chứa địa chỉ vật lý của PML4 Khi CPU cần dịch một địa chỉ, nó sẽ bắt đầu từ vị trí được chỉ định ở đây.

CR4 (Control Register 4): PAE (bit 5): Kích hoạt mở rộng địa chỉ vật lý (Physical Address Extension). Đây là điều kiện bắt buộc cho Long Mode vì phân trang 64-bit sử dụng định dạng PAE. PSE (bit 4): Cho phép sử dụng các trang lớn (huge pages) kích thước 2MB và 4MB.

EFER (Extended Feature Enable Register - Thanh ghi kích hoạt tính năng mở rộng): LME (bit 8): Long Mode Enable – Thông báo cho CPU rằng chúng ta muốn sử dụng chế độ 64-bit. LMA (bit 10): Long Mode Active – Bit này được CPU tự động thiết lập khi chế độ 64-bit thực sự được kích hoạt thành công.

Đoạn code trên tạo ra một page table với 4 levels (CPU cùi bắp không cần suport L5) như sau:

Cấu trúc Page Table Entry - PTE

Mỗi địa chỉ ảo sẽ có kích thước 8 bytes Bit 0: Present - Nếu bằng 0, việc truy cập trang này sẽ gây ra lỗi (fault). Bit 1: Read/Write (Đọc/Ghi) - Nếu bằng 0, việc ghi dữ liệu sẽ gây ra lỗi. Bit 7 (PS): Page Size (Kích thước trang) - Do chúng ta sử dụng 2MB page size nên bit này bằng 1 ở PD (tui nhớ không nhầm thì linux kernel setup identity mapping đến page size 1G - nếu khả dĩ) Bits 12-51: Địa chỉ vật lý của cấp tiếp theo (hoặc của trang cuối cùng).

Kết quả

Sau khi thiết lập các bảng trang này: Địa chỉ ảo 0x0 ánh xạ tới địa chỉ vật lý 0x0. Địa chỉ ảo 0x1000 ánh xạ tới địa chỉ vật lý 0x1000. Điều này tiếp diễn cho đến 1GB (tương đương 512 trang × 2MB mỗi trang). Kernel (nhân hệ điều hành) có thể thực thi mà không cần lo lắng về việc chuyển đổi địa chỉ (do địa chỉ ảo và vật lý trùng khớp nhau).

Nếu setup của bạn là đúng thì PTE đầu tiên sẽ có giá trị là 0x0000000000000083 (0x->0x, PS, R/W, P)

4.2 Segment descriptor và GDT

Về Segment descritpr và GDT trên intel, có thể tìm hiểu trên wiki. Cơ bản thì đối với 64-bit mode, những descriptor này chỉ có tác dụng giúp CPU kiểm tra privilege:

CPU cần kiểm tra xem segment có hợp lệ và present không.
Kiểm tra CS register để xem nó đang chạy ở mode nào (64-bit hay 32-bit compatibilty mode) Để VMM có thể chuyển VCPU vào Guest mode, chúng ta cần cung cấp các segment hợp lệ. Helper để tạo segment:

 
#[repr(C)]
#[derive(Debug, Copy, Clone, Default)]
pub struct kvm_segment {
    pub base: u64,
    pub limit: u32,
    pub selector: u16,
    pub type_: u8,
    pub present: u8,
    pub dpl: u8,
    pub db: u8,
    pub s: u8,
    pub l: u8,
    pub g: u8,
    pub avl: u8,
    pub padding: u8,
}
/* Đoạn code này mình copy ở đâu về mà quên rồi */
const fn seg_with_st(selector_index: u16, type_: u8) -> kvm_segment {
    kvm_segment {
        base: 0,              // Base address (ignored in long mode for most segments)
        limit: 0xffffffff,    // Segment limit (ignored in long mode)
        selector: selector_index << 3,  // Selector = index × 8 (each GDT entry is 8 bytes)
        type_,                // Segment type (code/data, permissions)
        present: 1,           // Segment is valid
        dpl: 0,               // Privilege level 0 (kernel)
        db: if type_ == 0b1011 { 0 } else { 1 },  // D/B flag
        s: 1,                 // Not a system segment
        l: if type_ == 0b1011 { 1 } else { 0 },   // Long mode bit (code only)
        g: 1,                 // Granularity (limit × 4KB)
        avl: 0,               // Available for OS use
        padding: 0,
    }
}

// Code segment: selector index 1, type 0b1011 (Execute/Read, accessed)
const CODE_SEG: kvm_segment = seg_with_st(1, 0b1011);

// Data segment: selector index 2, type 0b0011 (Read/Write, accessed)  
const DATA_SEG: kvm_segment = seg_with_st(2, 0b0011);

Lưu ý rằng, đối với 64-bit code, thì D bắt buộc phải bằng 0 khi L=1 Sau khi đã có CODE và Data segment, ta cần ghi chúng vào memory của VM, mình sẽ chọn ghi vào ở 0x500

 
fn enter_long_mode(&self, mem: &mut [u8]) -> Result<()> {
// ...
    let gdt_table: [u64; 3] = [
        0,                       // Entry 0: NULL descriptor (required)
        to_gdt_entry(&CODE_SEG), // Entry 1: Code segment
        to_gdt_entry(&DATA_SEG), // Entry 2: Data segment
    ];

    // Copy GDT to guest memory at address 0x500
    mem[0x500..0x500 + gdt_bytes.len()].copy_from_slice(gdt_bytes);

    // Tell the CPU where the GDT is
    sregs.gdt.base = 0x500;
    sregs.gdt.limit = std::mem::size_of_val(&gdt_table) as u16 - 1;
//...
}

Cơ bản thì code trên sẽ copy toàn bộ slice gdt_table vào mem - đây chính là vùng memory chúng ta đã mmap (dành cho VM memory, không phải kvm_run). Ở đây, sregs là biến kiểu kvm_sregs lưu trữ các thông tin về các special register của kvm Lúc này memory sẽ trông như này:

Address 0x500:
┌────────────────────────┐
│ 0x0000000000000000     │ NULL descriptor (index 0)
├────────────────────────┤
│ 0x00AF9A000000FFFF     │ Code segment (index 1, selector 0x08)
├────────────────────────┤
│ 0x00CF92000000FFFF     │ Data segment (index 2, selector 0x10)
└────────────────────────┘

Tuy nhiên KVM vẫn chưa có ý thức gì về các register và GDT này, chúng ta cần phải nói cho nó biết thông qua ioctl KVM_SET_SREGS Đối với mỗi registers này, chúng ta đều cần lấy giá trị hiện tại của nó thông qua ioctl KVM_GET_SREGS để đảm bào không ghi đè giá trị không mong muốn lên các sreg mà chúng ta không muốn động tới.

 
// Get current special registers
let mut sregs = kvm_sregs::default();
unsafe { ioctl(self.fd.as_raw_fd(), KVM_GET_SREGS, &mut sregs, 0) };

// CR3: Page table base address
sregs.cr3 = pml4_addr;  // 0x2000 - tells CPU where page tables are

// CR0: System control flags
sregs.cr0 |= X86_CR0_PE;  // 0x1 - Protection Enable (enter protected mode)
sregs.cr0 |= X86_CR0_PG;  // 0x80000000 - Paging Enable

// CR4: Extended features
sregs.cr4 |= X86_CR4_PAE;  // 0x20 - Physical Address Extension (required for long mode)
sregs.cr4 |= X86_CR4_PSE;  // 0x10 - Page Size Extension (allow 2MB/4MB pages)

// EFER: Extended Feature Enable Register (MSR)
sregs.efer |= EFER_LME;   // 0x100 - Long Mode Enable
sregs.efer |= EFER_LMA;   // 0x400 - Long Mode Active

unsafe { ioctl(self.fd.as_raw_fd(), KVM_SET_SREGS, &sregs, 0) };

Bước 5: Runnnnn the Guest

VMM calls KVM_RUN
        │
        ▼
┌───────────────────┐
│ KVM prepares VMCS │ (Virtual Machine Control Structure)
│ loads guest state │
└─────────┬─────────┘
          │
          ▼
    ┌───────────┐
    │ VM Entry  │ ── CPU switches to guest mode
    └─────┬─────┘
          │
          ▼
   Guest code runs directly on CPU (near-native speed)
          │
          │ (I/O instruction, interrupt, etc.)
          ▼
    ┌───────────┐
    │ VM Exit   │ ── CPU switches back to host mode
    └─────┬─────┘
          │
          ▼
┌───────────────────┐
│ KVM saves guest   │
│ state, returns    │
│ to VMM            │
└─────────┬─────────┘
          │
          ▼
VMM examines exit_reason and handles it

Ở bước này mình sẽ load một đoạn code đơn giản vào bộ nhớ của máy ảo để kiểm thử :v, Guest code sẽ được load vào địa chỉ vật lý 0x100000 của máy ảo.

 
impl VM {
// ....
    pub fn load_code(&self, code: &Vec<u8>) -> Result<()> {
        unsafe {
            std::ptr::copy_nonoverlapping(
                code.as_ptr(),
                self.memory_regions.userspace_addr.as_mut_ptr().add(0x100000)
                code.len(),
            );
        };
        Ok(())
    }
// ....
}

// in main.rs
vm.load_code(&code)?;

Đoạn code 64bit sẽ sử dụng là : hello.S Lưu ý rằng chúng ta sẽ load compiled binary file vào bộ nhớ chứ không phải text file này. compile: nasm -f elf64 -o hello.o hello.asm Sau khi load code vào memory, KVM vẫn chưa biết rằng nó phải bắt đầu chạy code từ đâu vì chúng ta chưa setup RIP cho nó. Mình sẽ viết một function mới để phục vụ việc này

 
impl VCpu {
    //....
    fn init_registers(&self, rip: __u64, rsi: __u64) -> Result<()> {
        let mut regs = kvm_regs::default();
        unsafe { ioctl(self.fd.as_raw_fd(), KVM_GET_REGS, &mut regs, 0) };

        regs.rflags = 2;   // Bit 1 must always be set (reserved)
        regs.rip = rip;    // Instruction pointer = kernel entry point
        regs.rsi = rsi;    // RSI = pointer to boot_params (Linux boot protocol)

        unsafe { ioctl(self.fd.as_raw_fd(), KVM_SET_REGS, &mut regs, 0) };
        Ok(())
    }
//....
}

Cuối cùng, cần một hàm để yêu cầu VCPU bắt đầu thực thi Guest code

 
impl VCpu {
    //....
    fn run(&self) -> Result<()> {
        loop {
            let ret = unsafe { ioctl(self.fd, KVM_RUN, 0) };
            if ret < 0 {
                return Err(io::Error::last_os_error())
                    .context("failed to get start kvm run");
            }
            let kvm_run = unsafe { self.run_ptr.as_ref() };
            println!("KVM EXIT {:?}\n", kvm_run);
        }
    }
//....
}

Kết hợp các hàm lại với nhau để bắt đầu quá trình thực thi của máy ảo

 
impl VM{
    // ...
    pub fn run(&mut self) -> Result<()> {
        // actually we only have one cpu
        for vcpu in &self.vcpus_fd {
            vcpu.init_registers(0x100000, 0)?;
            vcpu.run()?;
        }
        Ok(())
    }
    // ...
}

// In main.rs
let mut vm = VM::new().expect("unable to open VM fd");
vm.insert_memory_region(0, 1u32, 250 * 1024 * 1024, 0)?;
vm.create_vcpu()?;
vm.enter_long_mode()?;
vm.load_code(&code)?;
vm.run()?;

Lúc này ta có thể build và chạy code với: cargo run -- 64bits-baremetal/guest.bin và hy vọng nó sẽ in ra hello world. Nhưng…, nó chỉ in ra một đống “KVM_EXIT” gì đó liên tục, lý do là KVM sẽ trả về output tại VM_EXIT bằng cách ghi dữ liệu vào vùng địa chỉ đã mapping của kvm_run instance, tuy nhiên chúng ta chưa hề handle nó, do đó chúng ta cần quay lại hàm VCpu.run() để xử lý việc này

 
impl VCpu {
    //....
    fn run(&self) -> Result<()> {
        // ..... Giữ lại đoạn code ở trên (có thể xóa phần println đi)
        match kvm_run.exit_reason {
            KVM_EXIT_IO => {
                    let io = unsafe { kvm_run.__bindgen_anon_1.io };
                    let port = io.port;
                    let dir = io.direction as u32;
                    if dir == KVM_EXIT_IO_OUT && port == 0x3f8u16 {
                    let offset = unsafe { kvm_run.__bindgen_anon_1.io.data_offset } as usize;
                    let character =
                        unsafe { *((self.run_ptr.as_ptr() as *mut u8).add(offset)) } as char;
                    print!("{}", character);
                    _ = std::io::stdout().flush();
                }
            }
            KVM_EXIT_HLT => {
                println!("Guest executed HLT. Stopping.");
                break Ok(());
            }
            _ => {}
        };
    }
    // .....
}

Để kiểm tra xem VM Exit có phải xảy ra do có dữ liệu I/O không, ta kiểm tra exit reason, nếu exit reason là KVM_EXIT_IO thì VCPU đã quay lại host mode do I/O. Lúc này nếu dữ liệu là OUT và port là 0x3f8u16 thì ta có thể đọc dữ liệu ra bằng cách copy data ở địa chi offset tính từ kvm_run pointer.

Thành quả là nó sẽ in ra: Hello, KVM!Guest executed HLT. Stopping.

Như vậy ta đã có một VMM cơ bản có thể thực thi được Guest code 64bit.

III. Boot vmlinux

Tuy nhiên nếu chỉ có in ra mỗi hello world thì nó cũng không có gì thú vị, và việc setup một đống code chỉ để in Hello world nó khá thừa thãi và cũng không có chỗ nào nhìn giống một cái VM. Dể demo rõ ràng hơn về VMM, chúng ta sẽ nâng cấp nó để nó có thể boot được một vmlinux cơ bản. Đầu tiên cần chuẩn bị một file vmlinux, có thể tự compile, hoặc download nó về từ

https://github.com/phi-nguyendp/rust-kvm-tool/blob/main/64bits-baremetal/vmlinux.bin

Đây là một file ELF

phinguyendp@phi:~/Rust/rust-kvm-tool$ file 64bits-baremetal/vmlinux.bin
64bits-baremetal/vmlinux.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=7c8bd33f36cb5eed93f1c724ab40b407198bbe6c, not stripped

Thử chạy luôn với cargo run -- vmlinux.bin xem nó hoạt động như thế nào

phinguyendp@phi:~/Rust/rust-kvm-tool$ cargo run -- ../mini-vmm/vmlinux.bin
warning: `rust-kvm-tool` (bin "rust-kvm-tool") generated 12 warnings (run `cargo fix --bin "rust-kvm-tool" -p rust-kvm-tool` to apply 3 suggestions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.68s
     Running `target/debug/rust-kvm-tool ../mini-vmm/vmlinux.bin`
Succeffully loading guest code to memory (size: 21441304)

Ok, nó chỉ in ra một dòng log về kích thước file đã load vào, và không còn gì khác cả, lý do là để boot được linux, ta cần tuân thủ bootprotocol của nó.

Linux boot protocol cho x86

Trước hết cần đọc một tý về boot protocol ở doc của linux https://www.kernel.org/doc/html/v6.1/x86/boot.html, hoặc hỏi thầy Gemini cho nhanh. Do đó trước khi cho VCPU thực thi code, ta cần phải cung cấp boot parameter hợp lệ và lưu nó vào địa chỉ nhớ yêu cầu. Để tiết kiệm thời gian cho việc code, thì mình đã copy file định nghĩa các cấu trúc và hằng số liên quan đến boot parameter của linux từ linux-loader repository (cơ bản thì file này được gen ra từ linux-header bằng cách sử dụng rust-bindgen) và lưu nội dung vào src/bootparams.rs . Trong đây có struct boot_params là đối tượng chính mà chúng ta cần quan tâm.

 
#[repr(C, packed)]
#[derive(Copy, Clone)]
pub struct boot_params {
    pub screen_info: screen_info,
    pub apm_bios_info: apm_bios_info,
    pub _pad2: [__u8; 4usize],
    pub tboot_addr: __u64,
    pub ist_info: ist_info,
    pub acpi_rsdp_addr: __u64,
    pub _pad3: [__u8; 8usize],
    pub hd0_info: [__u8; 16usize],
    pub hd1_info: [__u8; 16usize],
    pub sys_desc_table: sys_desc_table,
    pub olpc_ofw_header: olpc_ofw_header,
    pub ext_ramdisk_image: __u32,
    pub ext_ramdisk_size: __u32,
    pub ext_cmd_line_ptr: __u32,
    pub _pad4: [__u8; 112usize],
    pub cc_blob_address: __u32,
    pub edid_info: edid_info,
    pub efi_info: efi_info,
    pub alt_mem_k: __u32,
    pub scratch: __u32,
    pub e820_entries: __u8,
    pub eddbuf_entries: __u8,
    pub edd_mbr_sig_buf_entries: __u8,
    pub kbd_status: __u8,
    pub secure_boot: __u8,
    pub _pad5: [__u8; 2usize],
    pub sentinel: __u8,
    pub _pad6: [__u8; 1usize],
    pub hdr: setup_header,
    pub _pad7: [__u8; 36usize],
    pub edd_mbr_sig_buffer: [__u32; 16usize],
    pub e820_table: [boot_e820_entry; 128usize],
    pub _pad8: [__u8; 48usize],
    pub eddbuf: [edd_info; 6usize],
    pub _pad9: [__u8; 276usize],
}

Có hai việc cần làm đối với boot_params, một là thiết lập các trường của header, và 2 là cấu hình E820 memory map. Đầu tiên, đối với header, nó được lưu trữ ở boot_params.hdr của biến, chúng ta cần thiết lập một số thông số sau:

boot_params.hdr.type_of_loader: Loại boot loader chúng ta dùng để boot linux, do chúng ta không dùng boot loader nào trong danh sách được cung cấp bởi linux kernel nên ta set trường này thành 0xFF
boot_params.hdr.boot_flags: Bắt buộc phải là 0xAA55, đây là magic number quy định linux kernel.
boot_params.hdr.header: Đây cũng là một magic number, có giá trị là: “HdrS” (0x53726448)
boot_params.hdr.cmd_line_ptr: Địa chỉ của kernel command line. (lưu ý là buộc phải nằm trong vùng 32bit)
boot_params.hdr.cmdline_size: Kích thước của command line, tối đa là 255
boot_params.hdr.loadfags: bitmask về các option load kernel. Ở đây mình dùng: CAN_USE_HEAP | 0x01 | KEEP_SEGMENTS, nghĩa là: load protected-mode code ở 0x100000 (bit 0x1), heap_end_ptr là valid
boot_params.hdr.heap_end_ptr: The end of setup stack/heap tính từ real-mode code

 
fn setup_boot_params(boot_params: &mut boot_params, cmdline_addr: u32, total_mem: u64) {
    // 1. Bootloader identification
    // 0xFF = "Unregistered bootloader" - Linux accepts any value here
    boot_params.hdr.type_of_loader = 0xFF;
    
    // Magic numbers Linux checks to verify boot_params is valid
    boot_params.hdr.boot_flag = 0xAA55;        // Same as MBR signature
    boot_params.hdr.header = 0x53726448;       // "HdrS" in ASCII
    
    // 2. Command line setup
    // This is how we pass "console=ttyS0" to the kernel
    boot_params.hdr.cmd_line_ptr = cmdline_addr;  // 0x20000 in our case
    boot_params.hdr.cmdline_size = CMDLINE.len() as u32;
    
    // 3. Heap configuration
    // The kernel uses this for early allocations before proper memory management
    boot_params.hdr.loadflags = CAN_USE_HEAP | 0x01 | KEEP_SEGMENTS;
    boot_params.hdr.heap_end_ptr = 0xFE00;
// ...... bellow is e820 setup

CMDLINE được định nghĩa như sau:

 
const CMDLINE: &[u8] = b"console=ttyS0 earlyprintk=ttyS0";

Tiếp theo chúng ta cần setup E820 table. E820 là cấy chi? E820 memory map là một bảng mô tả layout bộ nhớ vật lý, được firmware (BIOS/UEFI) cung cấp cho hệ điều hành trong giai đoạn boot. Nó trả lời câu hỏi cốt lõi: “Vùng địa chỉ vật lý nào là RAM dùng được, vùng nào phải tránh?” Một entry E820 thường có dạng:

(start_address, size, type)

Trong đó type có thể là: E820_TYPE_RAM: RAM dùng được E820_TYPE_RESERVED: không được đụng tới E820_TYPE_ACPI, NVS: vùng ACPI, firmware

Ví dụ:

Ví dụ:
0x00000 ┌─────────────────┐
        │   Low Memory    │ ◄── Usable RAM (640KB)
        │   (E820_RAM)    │
0x9FC00 ├─────────────────┤
        │   Legacy Hole   │ ◄── Reserved for VGA, ROMs, etc.
        │   (not mapped)  │
0x100000├─────────────────┤
        │   High Memory   │ ◄── Usable RAM (rest of memory)
        │   (E820_RAM)    │
        │                 │
        └─────────────────┘

Trong môi trường ảo hóa, E820 trong VM không đến từ BIOS thật, mà do VMM / hypervisor tạo ra. Linux kernel trong guest không phân biệt được là đang chạy trên phần cứng vật lý thật hay máy ảo Nó chỉ biết tin vào E820 map mà nó nhận được lúc boot. Mình thiết lập e820 table trong boot_params như sau:

 
fn setup_boot_params(boot_params: &mut boot_params, cmdline_addr: u32, total_mem: u64) {
//......
    // 4. E820 Memory Map - THIS IS CRITICAL
    // Linux uses E820 to know what memory is available
    boot_params.e820_entries = 2;
    
    // Low memory: 0 to 640KB (conventional memory)
    // The "hole" from 640KB to 1MB is reserved for legacy hardware
    boot_params.e820_table[0].addr = 0x0;
    boot_params.e820_table[0].size = 0x9FC00;  // 639KB
    boot_params.e820_table[0].type_ = E820_RAM;
    
    // High memory: 1MB to end of RAM
    // This is where the kernel and most data lives
    boot_params.e820_table[1].addr = 0x100000;  // 1MB
    boot_params.e820_table[1].size = total_mem - 0x100000;
    boot_params.e820_table[1].type_ = E820_RAM;
}

Nếu bạn sử dụng dmesg trên máy linux của bạn thì bạn sẽ thấy có nhiều entry hơn nữa (tầm chục cái), tuy nhiên để tiết kiệm thời gian và vì lười nên mình chỉ tạo ra một table đơn giản đủ dùng. Sau khi đã thiết lập xong boot_params, chúng ta copy nó vào memory của VM ở địa chỉ 0x10000

 
pub fn load_code(&self, vmlinux: &Vec<u8>) -> Result<__u64> {
    //... declare variables ...
    Self::setup_boot_params(
        &mut boot_params,
        ADDR_CMDLINE as u32, // ADDR_CMDLINE is defined as and const (0x20000)
        self.memory_regions.memory_size,
    );
    // ... load kernel ...
    
    // Copy boot_params to 0x10000 (64KB)
    unsafe {
        std::ptr::copy_nonoverlapping(
            &boot_params as *const boot_params as *const u8,
            self.memory_regions.userspace_addr.as_mut_ptr().add(0x10000),
            size_of_val(&boot_params),
        );
        
        // Copy command line to 0x20000 (128KB)
        std::ptr::copy_nonoverlapping(
            CMDLINE.as_ptr(),  // "console=ttyS0 earlyprintk=ttyS0"
            self.memory_regions.userspace_addr.as_mut_ptr().add(0x20000),
            CMDLINE.len(),
        );
    }
}

Vậy là đã có một function đơn giản để thiết lập boot protocol, tiếp theo ta cần update hàm load_code() để có thể load được file vmlinux.bin vào bộ nhớ

Load vmlinux.bin

Trước hết cần hiểu rằng vmlinux.bin là một raw ELF không nén. ELF (Executable and Linkable Format) là một định dạng chuẩn, dùng để mô tả:

Mỗi section/segment phải được nạp vào vị trí nào trong bộ nhớ
Mỗi section cần quyền gì (đọc / ghi / thực thi)
Địa chỉ entry point (nơi CPU bắt đầu chạy)

Vì vậy, không thể chỉ copy nguyên file vào RAM – ta phải parse ELF và load từng segment vào đúng địa chỉ của nó. Đây là program headers của file vmlinux.bin này, thực tế chúng ta chỉ cần load các vùng nhớ được chỉ ra bởi header thuộc type LOAD (PT_LOAD) vào memory, theo đúng địa chỉ (Offset) được nêu ra trong các headers (lưu ý là chúng ta đã setup 1 vùng identity mapping từ trước)

phinguyendp@phi:~/Rust/rust-kvm-tool/64bits-baremetal$ readelf --program-headers vmlinux.bin
Elf file type is EXEC (Executable file)
Entry point 0x1000000
There are 5 program headers, starting at offset 64
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000200000 0xffffffff81000000 0x0000000001000000
                 0x0000000000b72000 0x0000000000b72000  R E    0x200000
  LOAD           0x0000000000e00000 0xffffffff81c00000 0x0000000001c00000
                 0x00000000000b0000 0x00000000000b0000  RW     0x200000
  LOAD           0x0000000001000000 0x0000000000000000 0x0000000001cb0000
                 0x000000000001f658 0x000000000001f658  RW     0x200000
  LOAD           0x00000000010d0000 0xffffffff81cd0000 0x0000000001cd0000
                 0x0000000000133000 0x0000000000413000  RWE    0x200000
  NOTE           0x0000000000a031d4 0xffffffff818031d4 0x00000000018031d4
                 0x0000000000000024 0x0000000000000024         0x4
                 ....

Việc copy dữ liệu từ vmlinux.bin vào guest memory được thực hiện trong load_code() như sau:

 
pub fn load_code(&self, vmlinux: &Vec<u8>) -> Result<__u64> {
    // Parse ELF headers
    let elf = ElfFile::new(vmlinux).map_err(|e| anyhow::anyhow!(e))?;
    
    // Iterate through program headers (segments)
    for ph in elf.program_iter() {
        // Only load PT_LOAD segments (actual code/data)
        if ph.get_type().unwrap_or(xmas_elf::program::Type::Null)
            == xmas_elf::program::Type::Load
        {
            let offset = ph.offset() as usize;      // Offset in ELF file
            let file_size = ph.file_size() as usize; // Bytes in file
            let mem_size = ph.mem_size() as usize;   // Bytes in memory
            let paddr = ph.physical_addr() as usize; // Guest physical address

            unsafe {
                let dest = self.memory_regions.userspace_addr.as_mut_ptr();
                let src = vmlinux[offset..(offset + file_size)].as_ptr();

                // Copy segment from ELF to guest memory
                std::ptr::copy_nonoverlapping(src, dest.add(paddr), file_size);

                // Zero BSS (mem_size > file_size means uninitialized data)
                if mem_size > file_size {
                    std::ptr::write_bytes(
                        dest.add(paddr + file_size), 
                        0, 
                        mem_size - file_size
                    );
                }
            };
        }
    }
    
    // Return the entry point - where execution starts
    Ok(elf.header.pt2.entry_point())
}

Ở đây elf.header.pt2.entry_point() chính là entry point của kernel, ta return nó như kết quả của load_code(), cho phép caller của function này sử dụng nó để thiết lập RIP Tại thời điểm này:

Kernel code được được đặt ở vị trí mong muốn trong memory.

Các biến toàn cục đã được khởi tạo (zeros for BSS) Tại thời điểm này, việc load dữ liệu vào memory coi như hoàn thành, Cở bản layout của Guest memory sẽ như sau (Cursor vẽ :v):

┌────────────────────────────────────────┐ 0x0
│       Interrupt Vector Table           │ (not used in our minimal setup)
├────────────────────────────────────────┤ 0x500
│       GDT (Global Descriptor Table)    │ 24 bytes (3 entries × 8 bytes)
├────────────────────────────────────────┤ 0x2000
│       PML4 (Page Map Level 4)          │ 4KB, 1 entry used
├────────────────────────────────────────┤ 0x3000
│       PDPT (Page Directory Ptr Table)  │ 4KB, 1 entry used
├────────────────────────────────────────┤ 0x4000
│       PD (Page Directory)              │ 4KB, 512 entries (1GB mapped)
├────────────────────────────────────────┤ 0x10000 (64KB)
│       boot_params structure            │ ~4KB
├────────────────────────────────────────┤ 0x20000 (128KB)
│       Kernel command line              │ "console=ttyS0..."
├────────────────────────────────────────┤ 0x100000 (1MB)
│                                        │
│       Linux Kernel Image               │
│       (loaded from ELF segments)       │
│       - .text (code)                   │
│       - .rodata (constants)            │
│       - .data (initialized globals)    │
│       - .bss (zeroed globals)          │
│                                        │
├────────────────────────────────────────┤
│                                        │
│       Free RAM                         │
│       (kernel allocates from here)     │
│                                        │
└────────────────────────────────────────┘ ?GB

Tiếp theo chúng ta cần cập nhật ví trị thực thi code cho KVM là có thể khởi động máy ảo được, tuy vậy còn một bước khác ta cần làm trước, đó là cập nhật IO handler, nếu không chúng ta không thể biết được code có chạy OK hay không

Xử lý Serial console I/O

Khi kernel khởi động, nó sẽ in ra các thông báo. Nếu không có cơ chế giả lập console, chúng ta sẽ không bao giờ thấy được các thông báo này — vì máy ảo (guest) sẽ ghi dữ liệu ra “phần cứng” vốn không hề tồn tại. Tham số dòng lệnh kernel console=ttyS0 yêu cầu Linux xuất log ra cổng serial đầu tiên (COM1). Cổng serial rất đơn giản: chỉ cần ghi một byte vào cổng I/O 0x3F8 là dữ liệu sẽ được gửi ra ngoài. Chúng ta chặn (intercept) các thao tác ghi này và in nội dung đó ra terminal của mình.

Cách KVM I/O hoạt động

Khi guest thực thi một lệnh out (ghi dữ liệu ra cổng I/O):
CPU trap (chuyển quyền điều khiển) sang KVM
KVM lưu thông tin về thao tác I/O vào cấu trúc kvm_run
KVM trả quyền điều khiển về cho VMM của chúng ta với exit_reason là KVM_EXIT_IO
VMM xử lý I/O này và gọi KVM_RUN lần nữa để tiếp tục chạy guest Ta tách phần xử lý KVM_EXIT_IO ra một hàm riêng để dễ quản lý:

 
fn handle_io(&self, kvm_run: &kvm_run) -> Result<()> {
    // Get I/O details from the kvm_run structure
    let io = unsafe { kvm_run.__bindgen_anon_1.io };
    let port = io.port;                                    // Which port?
    let is_out = io.direction as u32 == KVM_EXIT_IO_OUT;  // Read or write?
    
    // Data is at an offset within the kvm_run mmap'd region
    let data_ptr = unsafe { 
        (self.run_ptr.as_ptr() as *mut u8).add(io.data_offset as usize) 
    };

    match (port, is_out) {
        // Guest writing to COM1 data register - this is a character!
        (COM1_DATA, true) => {
            let ch = unsafe { *data_ptr } as char;
            print!("{}", ch);
            _ = std::io::stdout().flush();  // Show immediately
        }
        
        // Guest reading Line Status Register
        // Kernel checks "is the transmitter ready?" before sending
        (COM1_LSR, false) => {
            // Return: Transmitter empty (0x20) | Holding register empty (0x40)
            // This tells the kernel "yes, you can send"
            unsafe { *data_ptr = 0x60; }
        }
        
        // Other UART registers - ignore writes, return 0 for reads
        (COM1_IER..=COM1_MSR, _) => {
            if !is_out {
                unsafe { *data_ptr = 0; }
            }
        }
        _ => {}
    }
    Ok(())
}

Ở đây cần lưu ý rằng, do 8250/16550 serial driver sẽ đợi ở COM1_LSR cho đến khi có tín hiệu thông báo với nó là nó có thể truyền dữ liệu vào iout, ta cần thêm đoạn xử lý để ghí dữ liệu vào COM1_LSR.

Thiết lập các interrupt cần thiết

Trước khi cho CPU guest bắt đầu chạy (KVM_RUN), VMM bắt buộc phải thiết lập hệ thống ngắt (interrupt subsystem). Trên x86, Linux không thể boot đúng nếu thiếu các thành phần này, ngay cả khi chưa có interrupt thực sự được phát ra. Trước khi chạy guest, VMM phải thiết lập đầy đủ hạ tầng ngắt: TSS để xử lý ring transition, identity map để đảm bảo interrupt an toàn khi paging chưa ổn định, irqchip để cung cấp APIC, và PIT để hỗ trợ timing trong early boot. Thiếu bất kỳ thành phần nào cũng có thể khiến Linux treo ngay từ những dòng printk đầu tiên.

Đoạn code sau thực hiện toàn bộ phần thiết lập đó:

 
pub fn setup_irqchip(&self) -> Result<()> {
    // TSS ADDR
    let ret = unsafe { ioctl(self.fd.as_raw_fd(), KVM_SET_TSS_ADDR, ADDR_TSS, 0) };
    if ret < 0 {
        return Err(io::Error::last_os_error()).context("KVM_SET_TSS_ADDR failed");
    }

    // IDENTITY mapping
    let ret = unsafe {
        ioctl(
            self.fd.as_raw_fd(),
            KVM_SET_IDENTITY_MAP_ADDR,
            &ADDR_IDENTITY_MAP,
            0,
        )
    };
    if ret < 0 {
        return Err(io::Error::last_os_error()).context("KVM_SET_IDENTITY_MAP_ADDR failed");
    }

    // Create in-kernel APIC
    let ret = unsafe { ioctl(self.fd.as_raw_fd(), KVM_CREATE_IRQCHIP, 0) };
    if ret < 0 {
        return Err(io::Error::last_os_error()).context("KVM_CREATE_IRQCHIP failed");
    }

    // Create PIT (timer)
    let pit_config = kvm_pit_config::default();
    let ret = unsafe { ioctl(self.fd.as_raw_fd(), KVM_CREATE_PIT2, &pit_config) };
    if ret < 0 {
        return Err(io::Error::last_os_error()).context("KVM_CREATE_PIT2 failed");
    }
    Ok(())
}

KVM_SET_TSS_ADDR – Vì sao cần TSS dù đang ở long mode?

TSS là gì?

TSS (Task State Segment) là cấu trúc x86 dùng để:

Chuyển stack khi vào interrupt / exception
Lưu RSP0 (kernel stack) cho ring transition
Hỗ trợ cơ chế interrupt an toàn. CPU thật yêu cầu TSS hợp lệ khi: Có interrupt hoặc có exception, nếu TSS không tồn tại thì sẽ xảy ra triple fault. Dù Linux 64-bit không dùng task switching cổ điển, TSS vẫn bắt buộc tồn tại. KVM không tự tạo TSS cho bạn. VMM phải nói rõ: “TSS của guest nằm ở đâu trong guest physical memory.” Chúng ta cần đưa địa chỉ ADDR_TSS cho KVM, địa chỉ này là địa chỉ vật lý của VM, và bắt buộc phải là vùng ram trống, không overlap với kernel, thông thường sẽ đặt ở vị trí thấp (dưới 1 MB) hoặc 1 page riêng, ở đây ta chọn 0xffff_d000. Và dùng ioctl để thông báo cho KVM về sự lựa chọn này: ioctl(fd, KVM_SET_TSS_ADDR, ADDR_TSS)

KVM_SET_IDENTITY_MAP_ADDR – Cái này để làm gì?

Identity map là gì? Đây là một page table đặc biệt, dùng khi:

CPU vào interrupt
Nhưng paging / CR3 chưa hoàn chỉnh
Hoặc trong các trường hợp chuyển mode

KVM_CREATE_IRQCHIP – Tạo APIC trong kernel

Linux luôn giả định có APIC, ngay cả trong VM. Nếu không tạo IRQ chip thì sao?

Không có Local APIC
Không có timer interrupt
Không có IPI
SMP không hoạt động
Scheduler không chạy
Kernel có thể treo hoặc panic rất sớm Thật ra thì IRQCHIP có thể được emulate ở userspace, tuy nhiên nó chậm và quá phức tạp so với nội dung bài viết, nên ta dùng của kernel: ioctl(fd, KVM_CREATE_IRQCHIP)

KVM_CREATE_PIT2 –

Programmable Interval Timer (8254) – bộ đếm thời gian cổ điển, được linux dùng trong earlyboot. Linux dùng PIT để làm gì?

Delay calibration
Busy-wait loops
Đo tần số TSC Fallback timer trước khi APIC timer hoạt động. Lát nữa chúng ta sẽ thấy lỗi liên quan đến cái này.

Thiết lập registers và bắt đầu chạy máy ảo

Trước khi chuyển quyền điều khiển vào máy ảo (enter the VM), chúng ta cần thiết lập trạng thái ban đầu của CPU:

 
fn init_registers(&self, rip: __u64, rsi: __u64) -> Result<()> {
    let mut regs = kvm_regs::default();
    unsafe { ioctl(self.fd.as_raw_fd(), KVM_GET_REGS, &mut regs, 0) };

    regs.rflags = 2;   // Bit 1 luôn phải được set (bit dự trữ)
    regs.rip = rip;    // Instruction Pointer = điểm vào (entry point) của kernel
    regs.rsi = rsi;    // RSI = con trỏ tới cấu trúc boot_params (Linux boot protocol)

    unsafe { ioctl(self.fd.as_raw_fd(), KVM_SET_REGS, &mut regs, 0) };
    Ok(())
}

Theo Linux 64-bit boot protocol, các thanh ghi khi kernel bắt đầu thực thi được quy ước như sau:

RIP: địa chỉ entry point của kernel
RSI: con trỏ tới cấu trúc boot_params Các thanh ghi khác: không được định nghĩa (kernel không phụ thuộc vào giá trị của chúng)

Nói cách khác, khi kernel bắt đầu chạy, nó không tự dò tìm môi trường boot mà dựa trực tiếp vào con trỏ boot_params được truyền qua thanh ghi RSI. Cấu trúc này chứa toàn bộ thông tin quan trọng như:

E820 memory map
Tham số dòng lệnh kernel
Thông tin về initrd
Các feature mà bootloader / VMM hỗ trợ
Việc thiết lập đúng RIP và RSI là điều kiện bắt buộc để kernel Linux có thể khởi động thành công trong môi trường KVM.

Tiếp theo cập nhật đoạn code xử lý IO trong hàm run() của CPU thành:

 
fn run(&self) -> Result<()> {
    loop {
        // Enter guest mode - CPU executes guest code until something happens
        let ret = unsafe { ioctl(self.fd.as_raw_fd(), KVM_RUN, 0) };
        if ret < 0 {
            return Err(io::Error::last_os_error())
                .context("KVM_RUN failed");
        }
        
        // Examine why we exited
        let kvm_run = unsafe { self.run_ptr.as_ref() };

        match kvm_run.exit_reason {
            KVM_EXIT_IO => {
                // Guest did port I/O - handle it
                self.handle_io(kvm_run)?;
            }
            KVM_EXIT_HLT => {
                // Guest executed HLT instruction
                // This means the kernel is done (or idle)
                println!("Guest executed HLT. Stopping.");
                break Ok(());
            }
            other => {
                // Unknown exit - for debugging, we could dump state here
            }
        };
    }
}

Thiết lập lại hàm main() để input entry point đúng vào cho VM

 
fn main() -> Result<()> {
    //... Declarations 
    let mut vm = VM::new().expect("unable to open VM fd");
    // 2GB ram
    vm.insert_memory_region(0, 1u32, 2 * 1024 * 1024 * 1024, 0)?;
    vm.setup_irqchip()?;
    vm.create_vcpu()?;
    vm.enter_long_mode()?;
    let entry = vm.load_code(&code)?;
    println!("Code will start at {:#x}", entry);
    vm.run(entry)?;
}

Testtt

Thực hiện câu lệnh sau để bắt đầu chạy VM:

cargo run -- [path to vmlinux.bin]

Ngay khi thực hiện cargo run, linux sẽ được boot lên và in một số thông tin ra màn hình

warning: `rust-kvm-tool` (bin "rust-kvm-tool") generated 9 warnings (run `cargo fix --bin "rust-kvm-tool" -p rust-kvm-tool` to apply 2 suggestions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/rust-kvm-tool ../mini-vmm/vmlinux.bin`
Succeffully loading vmlinux to memory (size: 21441304)
Warning: munmap failed: Invalid argument (os error 22)
Code will start at 0x1000000

[    0.000000] Linux version 4.14.174 (@57edebb99db7) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #2 SMP Wed Jul 14 11:47:24 UTC 2021
[    0.000000] Command line: console=ttyS0 earlyprintk=ttyS0
[    0.000000] Disabled fast string operations
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] Hypervisor detected: KVM

Tuy nhiên, có điều gì đó không ổn, vì nó stuck luôn ở đây, trong khi mình expect rằng nó sẽ bị panic ở bược load rootfs (theo kinh nghiệm đọc khá nhiều bài về kvm toys)

Sau một lúc tìm hiểu, thì điều này là do kernel đang đợi dữ liệu ở port 0x61. Cổng 0x61 là cổng điều khiển bàn phím / PIT đời cũ. Linux poll cổng này từ rất sớm để hiệu chuẩn độ trễ và kiểm tra tính hợp lý của thời gian. Nếu VMM không trả về bits như mong đợi, kernel sẽ rơi vào một vòng lặp vô tận (spin forever).

Theo như đoạn code ở trong file arch/x86/kernel/tsc.c thì chúng ta cần trả về giá trị 0x20 nếu như có yêu cầu input từ port này:

 
    // linux kernel: arch/x86/kernel/tsc.c
	while ((inb(0x61) & 0x20) == 0) {
        //...
    }

Ta thêm 1 match arm vào handle_io để ghi 0x20 vào 0x61

 
        (0x61, false) => unsafe {
                *data_ptr = 0x20;
            },

Thử chạy lại VMM:

Ok, lần này đúng như mong đợi, nó đã panic ở bước load rootfs vì ta không cung cấp cho nó file rootfs nào cả.

Như vậy, ta đã có một VMM cơ bản có thể boot được linux kernel viết bằng Rust.

IV. Boot rootfs (busybox) (Đoạn này phần lớn được viết bởi thầy Claude code)

Mục tiêu lần này là load được một rootfs (busybox) để kernel không panic ngay ở bước tìm init nữa, mà thực sự chạy được một cái shell.

Chuẩn bị rootfs

Do VMM của mình chưa emulate bất kỳ block device nào (chưa có virtio-blk, chưa có AHCI/IDE gì cả), nên thay vì mount một rootfs thật từ disk, cách đơn giản nhất là dùng initramfs (cpio archive được giải nén thẳng vào RAM bởi kernel) - kernel có sẵn cơ chế: nếu tìm thấy file /init bên trong initramfs, nó sẽ exec file này làm PID 1 mà không cần root=/rdinit= gì thêm.

Mình có sẵn một bản busybox tự build từ trước, sau khi make CONFIG_PREFIX=_install install thì có một thư mục _install chứa toàn bộ symlink của các applet trỏ về bin/busybox. Việc còn lại là đóng gói thư mục này thành một cpio archive đúng chuẩn (format newc).

Mình đã nhờ thầy Claude code viết một script Python độc lập (tools/mkinitramfs.py) để làm việc này - lý do dùng Python thay vì gọi cpio/fakeroot có sẵn là vì mình cần thêm vài device node đặc biệt (/dev/console, /dev/null,…) mà không có quyền mknod thật trên máy host, nên phải tự encode header newc bằng tay:

def header(name: bytes, mode: int, filesize: int, ino: int, rdevmajor=0, rdevminor=0) -> bytes:
    namesize = len(name) + 1  # cpio filenames are NUL-terminated
    fields = [ino, mode, 0, 0, 1, int(time.time()), filesize,
              0, 0, rdevmajor, rdevminor, namesize, 0]
    return b"070701" + b"".join(b"%08X" % f for f in fields)

Script này sẽ tự thêm vào vài thư mục cần thiết (/proc, /sys, /dev,…), vài device node (/dev/console major 5 minor 1 là quan trọng nhất - kernel cần mở được file này để làm stdin/stdout/stderr cho PID 1), và một file /init tự sinh:

#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev 2>/dev/null

echo
echo "=== rust-kvm-tool: busybox initramfs loaded ==="
/bin/busybox uname -a
echo "Dropping to a busybox shell (exec /bin/sh)."
echo

exec /bin/sh

Load initrd vào memory

Để không đụng vào load_code() (hàm cũ, đã viết boot_params với ramdisk_image = 0), mình thêm một hàm hoàn toàn mới load_initrd(), chạy SAU load_code(): nó copy dữ liệu cpio vào guest memory rồi patch lại đúng 2 field ramdisk_image/ramdisk_size của struct boot_params đã được load_code() ghi vào memory trước đó.

pub fn load_initrd(&self, initrd: &[u8]) -> Result<__u64> {
    // enter_long_mode() chỉ identity-map 512 * 2MB = 1GB đầu của guest memory
    // (xem lại phần Page Directory ở trên), nên initrd phải nằm trong vùng này
    const IDENTITY_MAP_LIMIT: u64 = 512 * 0x200000;

    let addr = (IDENTITY_MAP_LIMIT - initrd.len() as u64) & !0xfff;

    unsafe {
        let dest = self.memory_regions.userspace_addr.as_mut_ptr();
        std::ptr::copy_nonoverlapping(initrd.as_ptr(), dest.add(addr as usize), initrd.len());

        let bp_ptr = dest.add(ADDR_BOOT_PARAMS as usize) as *mut boot_params;
        (*bp_ptr).hdr.ramdisk_image = addr as u32;
        (*bp_ptr).hdr.ramdisk_size = initrd.len() as u32;
    }

    Ok(addr)
}

main.rs chỉ cần thêm một khối if let Some(initrd_path) = ... để load file thứ 2 (optional) từ argv, gọi hàm này sau load_code() - không có dòng code cũ nào bị sửa cả.

Lần chạy đầu tiên: kernel unpack được initramfs, nhưng im lặng khó hiểu

[    0.000000] RAMDISK: [mem 0x3fd78000-0x3fffffff]
...
[    0.119960] Unpacking initramfs...
[    0.130565] Freeing initrd memory: 2592K
...
[    0.829519] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    0.831994] CPU: 0 PID: 1 Comm: sh Not tainted 4.14.174 #2

Initramfs được unpack thành công (Freeing initrd memory chứng tỏ cpio archive đúng format), và Comm: sh trong panic trace nghĩa là /init (shebang #!/bin/sh) đã thực sự được exec. Vấn đề là: không có một dòng echo nào trong script của mình xuất hiện trên console cả, dù nó chắc chắn đã chạy (rồi tới exec /bin/sh và panic vì PID 1 không được phép thoát).

Đi tìm lý do: printk hoạt động, nhưng userspace write() thì không

Để debug mà không phụ thuộc vào đường I/O đang nghi ngờ, mình cho /init ghi log qua /dev/kmsg (đường này đi thẳng vào printk, một đường ghi console hoàn toàn khác, đã biết chắc là hoạt động) thay vì echo thường. Kết quả: script chạy đúng như mong đợi, in ra đầy đủ. Vậy vấn đề nằm ở chính con đường ghi console “bình thường” (write() vào /dev/console).

Vấn đề là printk của kernel dùng một đường ghi console riêng, gọi trực tiếp outb và poll LSR (đúng như code handle_io cũ ở trên đã emulate) - không cần ngắt. Nhưng write() từ một process bình thường lại đi qua tty layer chuẩn của driver 8250, driver này chỉ ghi một đợt (burst) đầu tiên rồi chờ ngắt THRE (Transmitter Holding Register Empty) để biết là được ghi tiếp - và VMM của mình chưa bao giờ raise bất kỳ ngắt nào cho COM1 cả, nên nó treo ở đó vĩnh viễn.

Mình thêm ngắt bằng ioctl KVM_IRQ_LINE (raise rồi lower ngay, giả lập một edge - như thiết bị ISA thật), gọi ngay sau khi in ký tự ra ở COM1_DATA:

fn pulse_irq(vm_fd: BorrowedFd, irq: u32) -> Result<()> {
    let mut level = kvm_irq_level { irq, level: 1 };
    unsafe { ioctl(vm_fd.as_raw_fd(), KVM_IRQ_LINE, &level) };
    level.level = 0;
    unsafe { ioctl(vm_fd.as_raw_fd(), KVM_IRQ_LINE, &level) };
    Ok(())
}

Chạy lại… vẫn im lặng y hệt. Ngắt được raise (không lỗi), nhưng chẳng có gì thay đổi.

`uart:unknown` - driver còn chưa nhận ra có UART

Check tiếp bằng /proc/interrupts và /proc/tty/driver/serial (vẫn qua /dev/kmsg):

0: uart:unknown port:000003F8 irq:4
           4:          0    XT-PIC      (không có dòng này!)

uart:unknown nghĩa là hàm autoconfig() của driver 8250 không nhận diện được chip UART, nên driver không bao giờ thực sự “mở” port này (không request_irq, dù số irq:4 vẫn hiện ra từ static table). Việc ngắt mình vừa thêm vào chẳng có ai lắng nghe cả.

Lục lại source drivers/tty/serial/8250/8250_port.c (bản 4.14) thì autoconfig() có 2 test tồn tại trước khi đi vào việc nhận diện chip, fail 1 trong 2 là auto bị coi là PORT_UNKNOWN:

Ghi 0 rồi 0x0F vào IER, đọc lại phải đúng y hệt - do code cũ của mình return cứng 0 cho mọi lần đọc IER (không lưu trạng thái gì cả) nên test này luôn fail.
Bật loopback mode qua MCR (LOOP | 0x0A), đọc MSR phải ra đúng 0x90 (MCR’s RTS/DTR/OUT1/OUT2 phải “loop” ngược lại thành CTS/DSR/RI/DCD trên MSR) - code cũ cũng return cứng 0 cho MSR nên fail luôn.

Tức là 2 register IER và MCR cần phải là register “thật” (lưu và đọc lại đúng giá trị đã ghi), chứ không phải no-op như trước. Mình thêm 2 field Cell<u8> vào VCpu để lưu trạng thái này (chỉ có 2 lựa chọn: hoặc thêm field mới vào struct, hoặc track state ở đâu đó khác - thêm field coi như là “thêm mới”, không sửa logic cũ):

(COM1_IER, true) => { self.com1_ier.set(unsafe { *data_ptr }); }
(COM1_IER, false) => unsafe { *data_ptr = self.com1_ier.get(); },
(COM1_MCR, true) => { self.com1_mcr.set(unsafe { *data_ptr }); }
(COM1_MSR, false) => {
    let mcr = self.com1_mcr.get();
    let msr = if mcr & 0x10 != 0 {
        ((mcr & 0x01) << 5)  // DTR -> DSR
            | ((mcr & 0x02) << 3)  // RTS -> CTS
            | ((mcr & 0x04) << 4)  // OUT1 -> RI
            | ((mcr & 0x08) << 4)  // OUT2 -> DCD
    } else { 0 };
    unsafe { *data_ptr = msr; }
}

Lần chạy thứ hai: nhận đúng chip, nhưng driver lại kêu “too much work”

Sau khi thêm 2 register trên, /proc/tty/driver/serial báo uart:8250 irq:4, và /proc/interrupts đã có dòng 4: ... ttyS0 tăng dần - ngắt đã có người lắng nghe! Nhưng dmesg lại xuất hiện:

[    0.942144] serial8250: too much work for irq4

lặp lại liên tục. Lý do: ISR của driver đọc IIR trong một vòng lặp, cứ thấy “còn ngắt đang chờ” (bit 0 = 0) là nó lại xử lý tiếp, tới khi chạm giới hạn an toàn (256 lần) mới chịu dừng và log cảnh báo này. Code cũ (và cả bản mình mới thêm interrupt) đều return cứng 0x02 (nghĩa là “luôn luôn đang chờ xử lý”) cho mọi lần đọc IIR - nên vòng lặp không bao giờ tự thoát bằng cách tự nhiên.

Trên phần cứng thật, đọc IIR trong lúc nguyên nhân là THRE chính là hành động “acknowledge” - nó phải tự động chuyển state về “không còn gì để xử lý” (0x01). Mình thêm một cờ com1_thre_pending: Cell<bool> để mô phỏng đúng hành vi đó, và chỉ raise ngắt khi driver thực sự đã bật IER’s THRI bit (tránh việc spam ngắt từ sớm trước khi driver kịp enable nó):

(COM1_DATA, true) => {
    // ... in ký tự ra như cũ ...
    if self.com1_ier.get() & 0x02 != 0 {
        self.com1_thre_pending.set(true);
        Self::pulse_irq(vm_fd, COM1_IRQ)?;
    }
}
(COM1_IIR, false) => {
    let iir = if self.com1_thre_pending.take() { 0x02 } else { 0x01 };
    unsafe { *data_ptr = iir; }
}

Kết quả

=== rust-kvm-tool: busybox initramfs loaded ===
Linux (none) 4.14.174 #2 SMP Wed Jul 14 11:47:24 UTC 2021 x86_64 GNU/Linux
Dropping to a busybox shell (exec /bin/sh).

/bin/sh: can't access tty; job control turned off
~ #

Lần đầu tiên thấy một cái prompt shell thật sự (~ #) xuất hiện trên console, không còn panic nữa. Chưa gõ được gì vào đó (chưa emulate keyboard/RX cho serial - /bin/sh giờ chỉ block ở read() chờ input không bao giờ tới, thay vì bị kill PID 1 ngay lập tức như trước), nhưng đó là một câu chuyện khác cho lần sau.

Điều thú vị nhất rút ra được ở phần này: bug này không nằm ở chỗ thiếu tính năng (thiếu ngắt) mà mình tưởng ban đầu, mà là ở việc driver có hẳn một bước “kiểm tra tồn tại” trước khi tin rằng có phần cứng thật ở đó - một VMM tối giản như thế này rất dễ bỏ sót những bước “vô hình” kiểu vậy, vì mọi thứ vẫn trông như chạy được (kernel vẫn boot, vẫn in log bình thường) cho tới khi động vào đúng con đường phụ thuộc vào nó.

References

KVM API Documentation
Linux x86 Boot Protocol
Intel Software Developer’s Manual
OSDev Wiki - Setting Up Long Mode
rust-vmm Project - Production-quality Rust VMM components
yeet.cx are you bios now
KVM host in a few lines of code

Built with Rust, curiosity, and lots of debugging.

Virtual Machine Monitor Kvm was originally published by Nguyễn Đình Phi at Oni Ranger on January 31, 2026.

Sparse Memory Model

2024-12-24T00:00:00+08:00

Quản lý bộ nhớ vật lý trong Linux kernel (physical memory management)

Ai đã từng tìm hiểu về hệ điều hành đều biết rằng bộ nhớ vật lý được quản lý bằng cách chia nhỏ ra thành các vùng nhớ có kích thước bằng nhau, linux kernel gọi chúng là các pages, kích thước của page phụ thuộc vào kiến trúc của hệ thống, thông thường là 4KB, ví dụ ARM và X86. Thực tế thì tên gọi đúng của các vùng nhớ này là Physical frames, và mỗi frame được đại diện bởi một biến có kiểu struct page trong linux kernel. Có lẽ mọi người đều từng nghe tới cách kernel sử dụng buddy system để cấp phát các page khi chúng ta yêu cầu thông qua các api như alloc_pages(mask, order) hay __get_free_page*, tuy nhiên liệu bạn đã từng thắc mắc rằng liệu kernel theo dõi và lựa chọn page như thế nào để trả về thông qua các api này?

Sparse memory model - cách kernel lưu physical frame trong hệ thống.

Nói nôm na thì physical memory model là cách đánh địa chỉ bộ nhớ của hệ thống, trong trường hợp đơn giản nhất, bộ nhớ vật lý của hệ thống có thể được đánh địa chỉ liên tục từ 0 đến maximum address. Tuy nhiên trong thực tế, dãy địa chỉ của bộ nhớ vật lý của thể không phải là liên tục, chẳng hạn như trong các NUMA system. Đối với các hệ thống đơn giản, FLATMEM model có thể được sử dụng để quản lý không gian địa chỉ này. Trong FLATMEM model, một mảng global tên là mem_map sẽ được sử dụng để theo dõi toàn bộ không gian bộ nhớ vật lý, với mỗi phần tử của mảng là một struct page instance - mô tả thông tin của physical frame tương ứng. Trong model này, page tương ứng của mỗi PFN - physical frame number có thể dễ dàng được tìm ra vì chúng chỉ là linear mapping với phần tử đầu tiên của mảng mem_map sẽ có PFN là ARCH_PFN_OFFSET. pfn_to_page(u64 x) -> {return mem_map[x - ARCH_PFN_OFFSET]} Mặc dù vậy, model này lãng phí rất nhiều không gian bộ nhớ, vì nó tạo ra một struct page instance cho mỗi physical frame number có thể được có của Architecture, bất kể frame đó có thực sự tồn tại trong hệ thống đang chạy hay không.

Để giải quyết vấn đề này, SPARSEMEM model đã được ra: https://lwn.net/Articles/134804/ Trong model này, bộ nhớ vật lý của hệ thống được chia ra thành các phần nhỏ hơn gọi là memory section, có kích thước phụ thuộc vào architecture, và được đại diện bởi một biến kiểu struct mem_section, điều đặc biệt của model này là nó sẽ chỉ tạo ra page instance trong hệ thống nếu physical frame tương ứng thực sự tồn tại, ngoài ra đây cũng là model duy nhất trong linux cho phép memory hotplug. Model này có một sub setting là SPARSEMEM_VMEMMAP, tuy nhiên chúng ta sẽ tạm thời bỏ qua nó.

memory section

memory section là một đơn vị quản lý bộ nhớ vật lý được đưa vào linux kernel để phục vụ cho SPARSEMEM model, đây là một đơn vị đánh dấu vùng nhớ có kích thước lớn hơn page nhưng nhỏ hơn node, với x86-64, kích thước của nó là 128MB.

 
struct mem_section {
    unsigned long section_mem_map;
    struct mem_section_usage *usage;
};

Các mem_section của hệ thống được kernel lưu trữ trong một mảng hai chiều có tên là mem_section, mỗi element trong mảng này quản lý một vùng địa chỉ có kích thước 128MB (focus on x86_64),

struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
// put macros here for easier reference
#define SECTIONS_PER_ROOT   (PAGE_SIZE/sizeof(struct mem_section))
#define NR_SECTION_ROOTS DIV_ROUND(NR_MEM_SECTIONS, SECTION_PER_ROOT)

Có thể thấy rằng mỗi section root sẽ cần không gian nhớ 1 page để lưu trữ thông tin, tức là toàn bộ hệ thống của NR_SECTION_ROOTS để lưu trữ thông tin về bộ nhớ vật lý. Với hệ thống X86_64 sử dụng 5 level page table (52 bits physical memory) thì cần tất cả 2^19 (1 << (52 - 27))sections để theo dõi thông tin bộ nhớ vật lý, tương tự thì đối với hệ thống sử dụng 4 level page table sẽ là 2^11 sections.

Truy cập pages trong SPARSEMEMORY model

Trường section_mem_map(unsigned long, nhưng thưc tế nó là một con trỏ tới một mảng 1 chiều) của struct mem_section chính là một con trỏ tới phần tử đầu tiên của một mảng có chứa PAGES_PER_SECTION phần tử, mỗi phần tử là một instance của struct page - đây chính là nơi kernel lưu trữ các page trong hệ thống.

    mem_section
    +-----------------------------+
    |usage                        |
    |   (mem_section_usage *)     |
    |                             |
    |                             |
    +-----------------------------+         mem_map[PAGES_PER_SECTION]
    |section_mem_map              |  ---->  +------------------------+
    |   (unsigned long)           |    [0]  |struct page             |
    |                             |         |                        |
    |                             |         +------------------------+
    +-----------------------------+    [1]  |struct page             |
                                            |                        |
                                            +------------------------+
                                       [2]  |struct page             |
                                            |                        |
                                            +------------------------+
                                            |                        |
                                            .                        .
                                            .                        .
                                            .                        .
                                            |                        |
                                            +------------------------+
                                            |struct page             |
                                            |                        |
                                            +------------------------+
                   [PAGES_PER_SECTION - 1]  |struct page             |
                                            |                        |
                                            +------------------------+

Lưu ý rằng, mem_section ứng với mỗi section index sẽ luôn tồn tại trong hệ thống, tuy nhiên mảng section_mem_map chỉ được allocate nếu như section này là hợp lệ - tức là có physical frame number nằm trong section này, do đó nó tiết kiệm được rất nhiều không gian bộ nhớ trong các hệ thống mà địa chỉ vật lý là không liên tục. Điểm trừ của model này là các hàm như __page_to_pfn và __pfn_to_page có phần phức tạp hơn, do chúng phải tìm ra section trước khi có thể tìm ra page tương ứng.

Quá trình khởi tạo sparse model trên x86_64

Qúa trình này bắt đầu tại bằng hàm sparse_init(), hàm này thường được gọi đến thống qua các lời gọi hàm trong setup_arch()

setup_arch() -> x86_init.paging.pagetable_init() -> paging_init() -> sparse_init()

Hàm memblocks_present có nhiệm vụ đánh dấu các mem section tồn tại trong hệ thống bằng cách set bit SECTION_MARKED_PRESENT của ms->section_mem_map

Hàm sparse_init_nid(int nid, unsigned long pnum_begin, unsigned long pnum_end, unsigned long map_count) có nhiệm vụ khởi tạo sparse model cho node nid, node này chứa các mem section nằm trong khoảng từ pnum_begin đến trước pnum_end. sparse_init_nid sẽ sử dụng các alloc api của memblock để allocate một mảng kiểu page[] gồm PAGES_PER_SECTION phần tử và encode địa chỉ của mảng này vào ms->section_mem_map.

map = __populate_section_memmap(pfn, PAGES_PER_SECTION,
				nid, NULL, NULL); // allocate a page array
		....
		check_usemap_section_nr(nid, usage);
		sparse_init_one_section(__nr_to_section(pnum), pnum, map, usage,
				SECTION_IS_EARLY); // encode PFN to ms->section_mem_map

Lưu ý là ms->section_mem_map sẽ được encode như sau:

ms->section_mem_map = mem_map_addr - section_to_pfn(sec);

Trong đó mem_map_addr là địa chỉa của phần tử đầu tiên trong mảng []page, còn section_to_pfn(sec) sẽ trả về PFN của page đầu tiên trong section này.

Một số lower bit của ms->section_mem_map sẽ được sử dụng để lưu các flags

Truy cập thông tin từ Sparse model

#define __page_to_pfn(pg)					\
({	const struct page *__pg = (pg);				\
	int __sec = page_to_section(__pg);			\
	(unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec)));	\
})

#define __pfn_to_page(pfn)				\
({	unsigned long __pfn = (pfn);			\
	struct mem_section *__sec = __pfn_to_section(__pfn);	\
	__section_mem_map_addr(__sec) + __pfn;		\
})

Do ms->section_mem_map = start_page - start_pfn nên pg - ms->section_mem_map sẽ là pg - start_page + start_pfn = PFN của pg. section_mem_map đã chứa luôn start_pfn của section mà không cần phải tạo thêm một trường khác để lưu nó.

Node và zone

Trong các hệ thống hiện đại, các vùng nhớ khác nhau của bộ nhớ chính có thể mang đến tốc độ truy cập khác nhau đối với các Core khác nhau. Ví dụ như một hệ thống có nhiều CPU socket khác nhau với các memory bank được gắn trực tiếp vào các socket này, các CPU sẽ truy xuất đến các memory bank trên socket của nó nhanh hơn các memory bank được gắn vào socket của các CPU khác. Các hệ thống này được gọi là NUMA (Non-uniform memory access), thiết kế này cho phép OS có thể tăng performance của một process bằng cách schedule nó tới CPU gần với vùng nhớ chứa dữ liệu của process này (CPU-Pinning).

Trong linux kernel mỗi NUMA node được thể hiện bằng một object kiểu struct pglist_data alias pg_data_t. X86_64 định nghĩa một mảng tĩnh struct pglist_data *node_data[MAX_NUMNODES] __read_mostly; để lưu trữ các object này (MAX_NUMNODES tùy vào config, tối đa là 1«10 đối vỡi intel). Các NUMA node trong hệ thống sẽ được thiết lập meta data thông qua code path

start_kernel();
-->setup_arch();
    --> initmem_init();
        --> x86_numa_init();

Trong khi đó zone được dùng để phân chia bộ nhớ thành các khoảng địa chỉ vật lý liên tục mà các địa chỉ trong cùng một zone sẽ có cùng đặc tính riêng biệt:

ZONE_DMA: sử dụng cho direct memory access của các legacy device (thường chỉ truy cập được 16MB đầu tiên của bộ nhớ)
ZONE_DMA32: Tương tự zone DMA, nhưng có thể dùng cho các device có thể truy cập đến địa chỉ 4GB
ZONE_NORMAL: Vùng nhớ thông thường
ZONE_HIGHMEM: Cái này chỉ dùng cho các hệ 32bit cũ (intel)
ZONE_MOVABLE: Zone ảo, không phản ánh về đặc tính địa chỉ vật lý mà phản ánh khả năng di động của page

Mỗi node metadata object (pg_data_t) chứa thông tin các zone của mỗi node trong field pg_data_t->node_zones[MAX_NR_ZONES]. Mỗi struct zone chứa một mảng các free lists cho mỗi page order size (index << 2 of pages per pageblock) trong fieldzone->free_area[MAX_ORDER], field này được bảo vệ bới một spinlock. Mỗi free_area chứa một mảng các head pointer đến một linked list chứa các free page trong free_area có cùng Migrate_types : free_area->free_list[MIGRATE_TYPES].

Hiện tại, trong linux kernel có các migrate types sau:

MIGRATE_UNMOVABLE: Những page có migrate type này không thể được di cư. Thông thường đây là các page được allocate bởi kernel mà được truy cập trực tiếp bằng indexed tới địa chỉ vật lý mà không có abstraction nào nên không thể được di chuyển.
MIGRATE_MOVABLE: Các page này có thể được duy chuyển tùy ý, thông thường là các page thuộc về user land, được truy cập thông qua abstraction (virtual address) nên địa chỉ vật lý thực tế không quá quan trọng.
MIGRATE_RECLAIMABLE: Slab pages, không thể di chuyển, nhưng có thể được reclaimed thông qua shirnking.
MIGRATE_HIGHATOMIC: Một migrate type đặc biệt để reserve bộ nhớ cho atomic allocation
MIGRATE_CMA: Sử dụng cho Continous memory allocation (CMA), các page này cũng có thể dùng cho MOVEABLE allocations.
MIGRATE_ISOLATE: Không được động tới.

Tại sao chúng ta phải phân loại các pages vào các migrate type khác nhau? Một vấn đề nan giải của linux kernel cũng như các OS khác là memory fragmentation. Không giống như đối với disk fragmentation, chúng ta không thể dễ dàng sắp xếp lại các page để giải quyết vấn đề này được, linux kernel chọn cách phòng tránh memory fragmention là chủ yếu, việc di sửa đổi memory layout để giải quyết các phân mảnh đã xảy ra được xem như giải pháp cuối cùng

Migratype là một cố gắng nữa để giải quyết vấn đề nan giải này. Trong ngữ cảnh của buddy allocator, khi giải phóng bộ nhớ, allocator sẽ Gộp các page nhỏ hơn với buddy pages của nó để tạo thành page có order lớn hơn. Giả sử như chúng ta tìm được một vùng nhớ có dạng : [F] [A][F][F][F], thì nếu các page này là movable chúng ta có thể migrate page thứ 2([A]) để tạo thành 1 page order-2. Tuy nhiên nếu như các page MOVABLE và UNMOVABLE nằm cạnh nhau thì chúng ta không thể thực hiện được điều này. Kernel sử dụng các page blocks với kích thước là pageblock_order để gom các page có cùng MIGRATE lại với nhau. Các free_list của buddy allocator sẽ được chia nhỏ ra theo các MIGRATE_TYPE, các hàm allocations sẽ phải chỉ rõ MIGRATE mà nó muốn dùng để cấp phát bộ nhớ. MIGRATE_TYPE của 1 page có thể được lấy từ hàm get_pageblock_migratetype() Tại thời điểm khởi động, tất cả các pages đều là MIGRATE_MOVABLE, sau đó memmap_init_range() sẽ update migrate type của các page.

Các zone sẽ được thiết lập thông qua path

start_kernel();
--> mm_core_init();
    --> build_all_zonelists(NULL);
        --> build_all_zonelists_init(void);
            --> static void build_zonelists(pg_data_t *pgdat);
                --> build_zonelists_in_node_order();build_zonelists_in_node_order(pg_data_t *pgdat, int *node_order, unsigned nr_nodes);
                    -->  build_zonerefs_node()
                --> void build_thisnode_zonelists(pg_data_t *pgdat)

Mối liên hệ giữa các data struct sử dụng trong quản lý bộ nhớ vật lý.

Sparse Memory Model was originally published by Nguyễn Đình Phi at Oni Ranger on December 24, 2024.

Virtual File System

2022-01-26T00:00:00+08:00

Linux Virtual File System

Virtual file system(VFS) là cơ chế Linux sử dụng để cho phép các chương trình chạy ở userspace tương tác với hệ thống file của máy, cũng như cung cấp một giao diện đồng nhất cho phép các chương trình này có thể thực hiện các thao tác trên các loại File system khác nhau mà không cần phải thay đổi mã nguồn. Nhờ có VFS mà Linux có thể sử dụng được nhiều loại file system khác nhau trên cùng một hệ thống:

Disk-based file system : Lưu trữ dữ liệu trên các thiết bị lưu trữ vật lý (ssd, hdd), các file system type tiêu biểu của loại này bao gồm: ext3, ext4, NTFS, FAT32,…
Network filesystems: Truy cập dữ liệu từ xa qua mạng, chẳng hạn như NFS hay CIFS.
Special filesystems: chẳng hạn như procfs, debugfs, sysfs.

Mặc dù Linux kernel được việt bằng C, nhưng VFS được xây dựng dựa trên các lý thuyết hướng đối tượng. VFS bao gồm nhiều object khác nhau cấu tạo nên:

struct task_struct: Thông tin về một process.
struct file_struct: Lưu giữ thông tin về các opened file của một process.
struct file: Đây là đối tượng lưu giữ các thông tin về mối liên kết giữa một process và một open file. Đối tượng này được lưu trữ trong Main Memory.
struct dentry: Lưu giữ thông tin về mối liên hệ giữa directory entry và file. Các FS type khác nhau sẽ có cách lưu trữ thông tin này trong thiết bị lưu trữ vật lý theo cách riêng của nó.
Inode: Lưu giữ siêu dữ liệu (meta data) của file. Đối với các FS vật lý thông thường, những đối tượng này sẽ tương đương với các File Control block được lưu trữ trên đĩa. Mỗi inode sẽ có một inode number được sử dụng như định danh của file.
struct address_space: Sử dụng bởi page cache, dùng để map các page của một file (địa chỉ trong bộ nhớ chính) với các disk block (địa chỉ trên đĩa/thiết bị lưu trữ).
superblock: Lưu thông tin về mounted file system.

1. Các cấu trúc dữ liệu VFS liên kết với process.

Ai tìm hiểu về linux kernel đều biết rằng Linux kernel sử dụng struct task_struct để biểu diễn một process. Trong struct này có hai trường dùng để mô tả mối quan hệ giữa một process với các file:

1
2
3
4
5
6
struct task_struct {
  /* cut */
  struct fs_struct *fs;
  struct file_struct *files;
  /* cut */
};

File system objects và process

Trường fs là một đối tượng kiểu fs_struct chứa các filesystem information. Trong cấu trúc này thì, users là số lượng process đang sử dụng đối tượng fs_struct này, root và pwd là hai con trỏ thuộc kiểu struct path* lần lượt là đường dẫn tới thư mục root và thư mục hiện thời của process. Trường fs này được gán khi một process mới được tạo ra thông qua hàm copy_fs(). Trong trường hợp cờ CLONE_FS được set, copy_fs sẽ khởi tạo vùng nhớ mới, mà sẽ tăng giá trị của counter users thêm một đơn vị, process mới được tạo ra sẽ dùng chung fs của process cha. Trong trường hợp CLONE_FS không được set, thì một vùng nhớ mới sẽ được cấp phát để tạo ra một đối tượng struct fs_struct mới tách biệt với process cha. Do các process thông thường đều là con cháu của process init nên fs->root của các process này đều giống của process init. Trường hợp chúng ta sử dụng chroot thì fs->root sẽ mang một giá trị khác.

# Call stack tới copy_fs()
#0  copy_fs (tsk=<optimized out>, clone_flags=18874368) at kernel/fork.c:1515
#1  copy_process (pid=pid@entry=0x0 <fixed_percpu_data>, trace=trace@entry=0, node=node@entry=-1, args=args@entry=0xffffc900054e7e58) at kernel/fork.c:2155
#2  0xffffffff81454ca7 in kernel_clone (args=args@entry=0xffffc900054e7e58) at kernel/fork.c:2555
#3  0xffffffff81455ed8 in __do_sys_clone (clone_flags=18874385, newsp=0, parent_tidptr=0x0 <fixed_percpu_data>, child_tidptr=0x7fc7398aa8d0, tls=0) at kernel/fork.c:2672
#4  0xffffffff89616c75 in do_syscall_x64 (nr=<optimized out>, regs=0xffffc900054e7f58) at arch/x86/entry/common.c:50
#5  do_syscall_64 (regs=0xffffc900054e7f58, nr=<optimized out>) at arch/x86/entry/common.c:80
#6  0xffffffff89800068 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:113

Trường files là một đối tượng kiểu struct files_struct chứa thông tin về các opened files của process. struct files_struct chứa một mảng các opened file descriptor của process hiện tại, ngoài ra struct files_struct cũng có một trường count để đếm số process đang chia sẻ nó, counter này sẽ được tăng giá trị nếu như process cha set cờ CLONE_FILES khi nó tạo ra process con. struct files_struct cũng chứa một fdtable instance, và một con trỏ tới instance này, các trường trong struct fdtable về cơ bản là các pointer tới các trường của files_struct chứa nó, như trong hình sau

Files_struct và fdtable

fdtable->max_fds là số opened file descriptors tối đa của process.
fdtable->fd là một mảng các con trỏ tới các đối tượng struct file. Giá trị file descriptor trả về khi chúng ta gọi hàm open() ở user-space chính là INDEX của mảng này.
fdtable->open_fds là con trỏ tới một mảng đánh dấu, mục đích của mảng này là để kiểm tra xem giá trị file descriptor có khả dụng (0) hay không (1). Giá trị next_fd của files_struct chính là vị trí tiếp theo chúng ta nên kiểm tra trong mảng này nếu như process yêu cầu một opened file descriptor mới.
fdtable->close_on_exec cũng là một mảng đánh dấu, giá trị 1 nghĩa là file descriptor nên được giải phóng khi exec() được gọi tới.
files_struct->fd_array có kích thước ban đầu khi khởi tạo process là NR_OPEN_DEFAULT Note: Mục đích của việc tạo ra struct fdtable để support RCU.
Ban đầu (ở task init), thì files_struct->fdt sẽ trỏ đến files_struct->fdtab, tuy nhiên nếu process mở quá nhiều files và fd_array không còn khả năng lưu trữ chúng nữa thì một đối tượng fdtable mới sẽ được tạo ra và nó fdt sẽ trỏ tới đối tượng mới này.

Ví dụ về một call stack khi process muốn tạo một opened file descriptor mới:

#0  expand_files (files=files@entry=0xffff888011dd4b80, nr=nr@entry=0) at fs/file.c:201
#1  0xffffffff81dd0cec in alloc_fd (start=start@entry=0, end=1024, flags=flags@entry=0) at fs/file.c:495
#2  0xffffffff81dd127b in __get_unused_fd_flags (nofile=<optimized out>, flags=0) at fs/file.c:530
#3  0xffffffff8efed163 in init_dup (file=file@entry=0xffff888049dbc040) at fs/init.c:264

Hàm alloc_fd() sẽ tìm một file descriptor mới (giá trị index nhỏ nhất của mảng fdt còn khả dụng), ngoài ra nó sẽ gọi tới hàm expand_files() để thực hiện việc mở rộng fdtable nếu cần thiết. (line 8)

1
2
3
4
5
6
7
8
9
/* Cut */
if (fd < files->next_fd)
	fd = files->next_fd;

if (fd < fdt->max_fds)
	fd = find_next_fd(fdt, fd);
/* Cut */
error = expand_files(files, fd);
/* Cut */

Hàm expand_files() sẽ thực hiện việc mở rộng fdtable trong trường hợp file descriptor mới được cấp phát có giá trị lớn hơn max_fds hiện tại, nó sẽ gọi đến expand_fdtable(). Hàm expand_fdtable() sẽ cấp phát một vùng nhớ cho fdtable và fd_array mới(? Đây là function comment trong source code, nhưng có vẻ không đúng).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static int expand_fdtable(struct files_struct *files, unsigned int nr)
{
  struct fdtable *new_fdt, *cur_fdt;
  spin_unlock(&files->file_lock);
  new_fdt = alloc_fdtable(nr); /* Cấp phát fdtable mới có thể chứa được nr file descriptor*/
  /*Cut*/
  cur_fdt = files_fdtable(files); 
	BUG_ON(nr < cur_fdt->max_fds);
	copy_fdtable(new_fdt, cur_fdt); /* Sao chép dữ liệu từ fdtable hiện tới tới fdtable mới cấp phát */
	rcu_assign_pointer(files->fdt, new_fdt); /* Gán giá trị fdt của files_struct tới fdtable mới cấp phát */
	if (cur_fdt != &files->fdtab)
		call_rcu(&cur_fdt->rcu, free_fdtable_rcu); /* Giải phóng fdtable cũ */
	/* coupled with smp_rmb() in fd_install() */
	smp_wmb();
	return 1;
}

Kể từ sau lần gọi đầu tiên đến expand_fdtable() thì fdtable->fd không còn trỏ tới files_struct->fd_array nữa.

1
2
3
4
5
struct files_struct {
	/* cut */
	struct file __rcu * fd_array[NR_OPEN_DEFAULT];
	/* cut */
}

2. Struct file - Đối tượng biểu diễn một opened file, và phương thức process tương tác với file đó.

Mỗi đồi tượng struct file là một phần tử trong open file table, một đối tượng struct file mới sẽ được thêm vào table này khi hàm open() được gọi, nhiều file object có thể trỏ tới cùng một file vật lý. Đây chính là những object được trỏ tới bởi file descriptor table (fdtable->fd và fd_array).

Các trường quan trọng của file object:

struct llist_node fu_llist
struct path f_path
struct fmode_t f_mode
loff_t f_pos
const struct file_operations *f_op Đã đề cập trong bài về character device driver

file pointer f_pos sẽ cho biết vị trị hiện tại của file, tức là vị trí trong file mà thao tác tiếp theo của file_operations sẽ tác động tới.
File object được cấp phát bằng hàm __alloc_file(), và các file object đều nằm trong slab cache filp_cache

1
2
3
4
5
6
7
static struct file *__alloc_file(int flags, const struct cred *cred)
{
	struct file *f;
	int error;

	f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
	/* Cut */

Bây giờ mình sẽ viết một kernel module mà khi insert vào nó sẽ in một chuỗi ký tự ra terminal (stdout không phải dmesg) bằng cách sử dụng file descriptor được lưu trữ trong file_struct. Việc này có thể được thực hiện là do Linux kernel sử dụng terminal như một file thông thường, nó cũng hỗ trợ mở, đọc ghi qua file descriptor. Mình sẽ chỉ viết hàm init của module, và sẽ chú thích trong code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
static int nr_pid = 0; /* Tham số truyền vào của kernel module này là pid của một process */
module_param(nr_pid, int, 0644);
static int __init vfs_layer_init(void)
{
        struct files_struct *files; 
        struct file *stdout_fd = NULL;
        struct pid *bpid;
        struct task_struct *btask_struct;
        loff_t offset = 0;
        char *hello_user = "Hello userspace\n"; /* Đây là chuỗi sẽ được in ra màn hình */

        bpid = find_get_pid(nr_pid); /* Dòng này sẽ lấy pid_t object tương ứng với pid truyền vào */
        if (!bpid)
                return -EINVAL;
        rcu_read_lock();
        btask_struct = pid_task(bpid, PIDTYPE_PID); /* Lấy task_struct object của process chúng ta muốn thao tác */
        rcu_read_unlock();

        files = btask_struct->files; // Lấy ra files_struct object của process

		// Tiếp theo, chúng ta lấy ra file descriptor của stdout.
		// Trong linux thì open fd của stdout có giá trị là 1, tức là files->fdt[1], 
		// Tuy nhiên chúng ta nên sử dụng các hàm cung cấp bởi kernel để truy cập giá trị này thay vì truy cập trực tiếp
        stdout_fd = files_lookup_fd_raw(files, 1); //1 is open fd of stdout

        if (stdout_fd) {
				//Sử dụng stdout_fd để ghi ra terminal
				// Lưu ý rằng hàm __kernel_write() đã bao gồm cả code gọi tới hàm f_op->write
				// Mình gọi hàm f_op->write ở đây chỉ để show ra rằng chúng ta có thể truy cập
				// các hàm này thông qua task_struct của process.
                if (stdout_fd->f_op->write)
                        stdout_fd->f_op->write(stdout_fd,hello_user, strlen(hello_user), &offset);
                else if (stdout_fd->f_op->write_iter)
                        __kernel_write(stdout_fd, hello_user, strlen(hello_user), &offset);
        }

        return 0;
}

Sử dụng kernel module này như sau:

1
2
root@oni:~# insmod vfs_layer.ko nr_pid=$(echo $$)
Hello userspace

File object sẽ được kết nối tới các inode (in-memory inode) thông qua dentry object, phần tiếp theo mình sẽ viết về dentry và path lookup

3. Dentry và path lookup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
struct dentry {
	/* RCU lookup touched fields */
	unsigned int d_flags;		/* protected by d_lock */
	seqcount_spinlock_t d_seq;	/* per dentry seqlock */
	struct hlist_bl_node d_hash;	/* lookup hash list */
	struct dentry *d_parent;	/* parent directory dentry object */
	struct qstr d_name;
	struct inode *d_inode;		/* Where the name belongs to - NULL is
					 * negative */
	unsigned char d_iname[DNAME_INLINE_LEN];	/* small names */

	/* Ref lookup also touches following */
	struct lockref d_lockref;	/* per-dentry lock and refcount */
	const struct dentry_operations *d_op;
	struct super_block *d_sb;	/* The root of the dentry tree */
	unsigned long d_time;		/* used by d_revalidate */
	void *d_fsdata;			/* fs-specific data */

	union {
		struct list_head d_lru;		/* LRU list */
		wait_queue_head_t *d_wait;	/* in-lookup ones only */
	};
	struct list_head d_child;	/* list of children from the parent directory (our siblings) */
	struct list_head d_subdirs;	/* list of our children (files and subdirectories)  */
	/*
	 * d_alias and d_rcu can share memory
	 */
	union {
		struct hlist_node d_alias;	/* inode alias list */
		struct hlist_bl_node d_in_lookup_hash;	/* only for in-lookup ones */
	 	struct rcu_head d_rcu;
	} d_u;
} __randomize_layout;

Dentry của file object được wrap trong struct path f_path.
Dentry giúp cho Linux có thể sử dụng thưc mục như thể nó là một file bình thường, ngoài ra nó cũng giúp đơn giản hóa việc phân giải đường dẫn (path resolving). Trong Linux thì thư mục đơn giản là một file có nội dung là danh sách các file con của thư mục đó:

1
2
3
4
5
6
7
8
9
10
11
# Nội dung của /tmp khi mở bằng ứng dụng vi
/tmp/
▸ cscope.1018443/
▸ nvimYeSwDV/
▸ ssh-0DuqRUmLe20F/
▸ ssh-4YzTJFipav60/
▸ ssh-7hZUUTpWcEZr/
▸ ssh-CpraiX7DPMpJ/
test1
test2
test3

Khi một file object muốn thực hiện thao tác với dữ liệu, linux kernel cần phân giải đường dẫn thông thường (ví dụ: /usr/bin/gdb) thành inode number tương ứng. Việc này được thực hiện thông qua các dentry, lưu giữ trong trong main memory để tăng tốc độ phân truy cập.
Ví dụ, đối với việc truy cập /usr/bin/gdb, linux kernel sẽ tạo ra dentry cho : /, usr, bin, gdb, và mỗi dentry này sẽ được kết nói với một inode nhất định thông qua trường d_inode. Thông qua các trường d_parent, d_child, d_subdirs, các dentry objects sẽ được liên với nhau để tạo ra một cây thư mục, có cấu trúc cây giống như những gì chúng ta thường thấy qua các file explorer.

"Cây" thư mục

Mỗi dentry có thể tồn tại ở một trong bốn trạng thái sau đây:

free : Không chứa bất kỳ thông tin nào quan trọng, nó không được sử dụng bởi VFS.
unused : Đã từng được sử dụng, tuy nhiên hiện tại nó không còn được sử dụng nữa (d_lockref.count bằng không), nhưng d_node vẫn trỏ tới inode.
used : Sử dụng bởi kernel, d_lockref.count > 0 và d_inode trỏ tới inode.
empty : d_inode NULL, dentry này vẫn có thể được sử dụng trong các thao tác tìm kiếm trong tương lai, tuy nhiên inode liên kết với dentry này đã bị xóa, hoặc dentry được tạo ra để phân giải một file vật lý không tồn tại.

Trường d_op của struct dentry là chứa các con trỏ hàm giúp thao tác với dentry object, Một số hàm được d_op hỗ trợ bao gồm:

d_revalidate(dentry, nameidata) trước khi phân giải đường dẫn tới file, hàm này sẽ được gọi để kiểm tra tính hợp lệ cảu dentry object; đa số các disk fs không hỗ trợ hàm này, tuy nhiên hầu hết các net fs đều hỗ trợ.
d_delete(dentry) hàm này được gọi khi dentry reference counter chuyển về giá trị 0.
d_release(dentry) VFS gọi hàm này để giải phóng dentry.
d_iput(dentry, ino) gọi khi dentry object bị xóa mất inode (chuyển sang trạng thái empty)
d_hash(dentry, name) Tạo hash value cho dentry.
d_compare(dir, name1, name2) So sánh hai file name. Do việc tạo các đối tượng dentry tương ứng từ directory entry tốn thời gian đáng kể, nên VFS sử dụng dentry cache (dcache) để lưu trữ một số đối tượng dentrykhông sử dụng trong bộ nhớ chính, do những đối tượng này có thể cần tới về sau.

static struct kmem_cache *dentry_cache __read_mostly;

Các dentry object đều được link tới bởi các entry trong dentry_hashtable thông qua trường d_hash, bảng băm này sẽ tăng tốc độ tìm kiếm dentry. dentry_hashtable có kiểu struct hlist_bl_head, về cơ bản nó là một mảng các struct hlist_bl_node, các node này là node đầu tiên trong một danh sách liên kết các dentry có cùng hash value. Sức chứa của dentry_hashtable phụ thuộc vào dung lượng RAM,

1
2
3
# 2GB RAM system
root@syzkaller:~# dmesg |grep "Dentry cache"
[    0.717333] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, vmalloc)

Dentry Hashtable

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Simpelifed code
static unsigned int d_hash_shift __read_mostly;
static struct hlist_bl_head *dentry_hashtable __read_mostly;
static inline struct hlist_bl_head *d_hash(unsigned int hash)
{
	return dentry_hashtable + (hash >> d_hash_shift);
}

# Block code thêm một dentry vào hash table
{
	struct hlist_bl_head *b = d_hash(entry->d_name.hash);
	hlist_bl_lock(b);
	hlist_bl_add_head_rcu(&entry->d_hash, b);
	hlist_bl_unlock(b);
}

Ngoài ra, tất cả các unused dentry đều được liên kết với nhau trong một double-linked LRU list thông qua trường d_lru, hầu hết các dentry nằm trong LRU này đều góp mặt trong dentry_hashtable.

Việc phân giải tên sẽ được thực hiện thông qua hàm link_path_walk(), hàm này sẽ convert một pathname thành inode number, nó được gọi tới bởi các function như : open(), stat(),…

1
2
3
4
5
6
7
# Stacktrace của system call tới sys_open()
(gdb) bt
#0  0xffffffff81d93d90 in link_path_walk (nd=<optimized out>, name=<optimized out>) at fs/namei.c:2270
#1  path_openat (nd=nd@entry=0xffffc90001c77c30, op=op@entry=0xffffc90001c77df0, flags=flags@entry=65) at fs/namei.c:3605
#2  0xffffffff81d98d41 in do_filp_open (dfd=dfd@entry=-100, pathname=pathname@entry=0xffff88801992a480, op=op@entry=0xffffc90001c77df0) at fs/namei.c:3636
#3  0xffffffff81d4116b in do_sys_openat2 (dfd=dfd@entry=-100, filename=filename@entry=0x7f56072b6466 "/proc/self/oom_score_adj", how=how@entry=0xffffc90001c77ea8) at fs/open.c:1214
#4  0xffffffff81d45bd3 in do_sys_open (dfd=-100, filename=0x7f56072b6466 "/proc/self/oom_score_adj", flags=<optimized out>, mode=<optimized out>) at fs/open.c:1230

Hàm link_path_walk() nhận vào hai tham số là path name và nameidata object VFS sẽ bắt đầu việc phân giải pathname từ nameidata->path, phụ thuộc vào giá trị của trường nameidata->dfd mà vị trí bắt đầu tìm kiếm có thể là dentry lien kết với root hoặc pwd. Quá trình phân giải path name được thực hiện như sau:

Tìm kiếm địa chỉ inode tương ứng với element gần nhất (từ trái qua)
Kiểm trả xem process có quyền thực thi không (execute permission).
Lấy element tiếp theo từ path name.
Kiểm tra các trường hợp đặc biệt (. hoặc ..)
Tìm kiếm dcache entry cho dentry object tương ứng với element gần nhất, nếu việc tìm kiếm trong dcache thất bại thì VFS phải load dentry object từ đĩa và lưu vào dcache. kiểm tra xem element hiện tại có phải là mount point không? Nếu có thể inode hiện tại sẽ thay đổi thành root inode của mounted file system.
Nếu element đang xử lý không phải là element cuối cùng của pathname thì tiếp tục thực hiện các bước trên cho element tiếp theo.

4. Inode và Super block

Note: Cho ngắn gọn dễ nghe thì tui tự quy ước file vật lý nghĩa là file nằm trong disk. Superblock là block đầu tiên của một mounted file system, nó chứa mounted file system’s metadata, chẳng hạn như số blocks, số inodes, etc,…
Inode là một thành phần quan trọng của các UNIX-style file system (được trên thiết bị lưu trữ vật lý - on-disk inode), đồng thời cũng là một thành phần quan trọng của VFS (in-memory inode). Mỗi inode là một định danh về một file vật lý cũng như các thông tin về file đó (uid, gid, permission, etc), mặc dù vậy, inode không có thông tin về tên file, tên file là thông tin thuộc về struct dentry object liên kết với inode này. Tên file chỉ là một label để người dùng có thể dễ dàng ghi nhớ và nhận diện, nó có thể thay đổi tùy thuộc vào thao tác của người dùng, tuy nhiên inode và inode number của một file sẽ không bao giờ thay đổi. Khi một process gọi hàm open() thì nó sẽ tạo ra một file object liên kết với inode object, tại cùng một thời điểm có thể có nhiều file object cùng tham chiếu tới một inode. Tương tự như đối với dentry, VFS cũng sử dụng một bảng băm tên là inode_hastable và một LRU list để truy xuất và tái sử dụng inode một cách hiệu quả. LRU list này được lưu trữ bởi in-memory superblock:

list_lru_add(&inode->i_sb->s_inode_lru, &inode->i_lru)

Một số trường quan trọng của struct inode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct inode {
	struct super_block *i_sb; /* pointer tới superblock sử hữu inode này */
	dev_t i_rdev; /* Device number chứa mounted fs*/
	unsigned long i_ino; /* Inode number trong disk inode table*/
	u8 i_blkbits;
	umode_t i_mode; /*file type: regular, directory, named pipe, etc...*/
	kuid_t i_uid;
	kgid_t i_gid;
	loff_t i_size;
	struct timespec i_mtime, i_atime, i_ctime;
	i_nlink;
	blkcnt_t i_blocks;
	const struct inode_operations *i_op;
	const struct file_operations *i_fop;	
	atomic_t i_count;
}

Trong đó i_op là con trỏ tới kiểu dữ liệu inode_operations, kiểu dữ liệu này là một lớp trừu tượng chứa các con trỏ hàm dùng để tương tác với dữ liệu của inode, một số trường quan trọng của inode_operations:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct inode_operations {
	/* Hàm mknod sẽ tạo ra một node mới ở mounted fs hiện tại */
	int (*mknod) (struct user_namespace *, struct inode *,struct dentry *,
		      umode_t,dev_t);
	/* Hàm create được gọi khi user muốn tạo một file thông thường */
	int (*create) (struct user_namespace *, struct inode *,struct dentry *,
		       umode_t, bool);
	/* Hàm myfs_mkdir có tác dụng tạo một thư mục mới */
	int (*mkdir) (struct user_namespace *, struct inode *,struct dentry *,
		      umode_t);
	/* Hàm lookup có tác dụng tìm kiếm */
	struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
	/* Hàm link*/
	int (*link) (struct dentry *,struct inode *,struct dentry *);
}

Một đối tượng in-memory inode mới được tạo ra bằng cách sử dụng hàm new_inode(), hàm này sẽ yêu cầu bộ nhớ cho Inode mới, và thêm inode này vào cuối list s_inodes của super block được truyền vào:

1
2
3
4
5
6
7
8
9
10
11
12
struct inode *new_inode(struct super_block *sb)
{
	struct inode *inode;

	spin_lock_prefetch(&sb->s_inode_list_lock);

	inode = new_inode_pseudo(sb); /* Gọi tới inode_alloc() để yêu cầu vùng nhớ cho inode mới */

	if (inode) /* Nếu việc cấp phát diễn ra thành công thì thêm inode vào list s_inodes */
		inode_sb_list_add(inode);
	return inode;
}

Hàm inode_alloc() sẽ sử dụng con trỏ hàm từ struct super_operations để cấp phát inode mới, ví dụ với ext4 fs thì con trỏ hàm này sẽ trỏ tới hàm:

static struct inode *ext4_alloc_inode(struct super_block *sb)

Như đã nói ở trên, thì super_block chứa các thông tin về một mounted fs, các super block sẽ được tạo ra khi người dùng thực hiện mount một phân vùng mới thông qua hàm mount. VFS sử dụng các hàm fill_super để load các thông tin về fs vừa được mount vào trong super_block. Ngoài ra VFS cũng hỗ trợ việc truyền vào các tùy chọn cho một mount fs, (ví dụ: mount -t iso9660 -o ro /dev/cdrom /mnt) hay việc giải phóng các tài nguyên bộ nhớ liên quan đến một mounted fs khi chúng ta umount. Tất cả các nhiệm vụ này được VFS thực hiện thông qua một cấu trúc dữ liệu tên là fs_context_operations.

Subsection: File system context (kernel 5.4)

Trước đây, việc mount một fs mới được thực hiện thông qua con trỏ hàm mount() của cấu trúc dữ liệu struct file_system_type, tuy nhiên kể từ phiên bản kernel 5.4, linux kernel đã giới thiệu một cơ chế mới có tên là file system context, cơ chế này cung cấp cho VFS khả năng tham số hóa qua trình khởi tạo/tìm kiếm/tái cấu hình super block. Qúa trình tạo một mount point mới của VFS sẽ được thực hiện qua các bước sau:

Bước 1: Tạo ra một file system context.
Bước 2: Phân tích các tham số đầu vào và gắn nó vào fs context.
Bước 3: Kiểm tra tính hợp lệ.
Bước 4: Tạo mới hoặc load một super block và root inode.
Bước 5: Thực hiện việc mount
Bước 6: Trả về một errorf (nếu có lỗi)
Bước 7: Giải phóng fs context.

Việc tạo và tái cấu trúc một superblock được quản lý bởi một fs context, VFS sử dụng cấu trúc dữ liệu struct fs_context để lưu giữ các thông tin về một fs context.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
struct fs_context {
	/* ops là các thao tác có thể được thực hiện trên một fs context, đây là một trường quan trọng và bắt buộc phải được gán giá trị tại thời điểm khởi tạo một fs context */
	const struct fs_context_operations *ops;
	/* Một con trỏ tới fs type (chủ của fs context này), trường này giúp cho việc thay đổi các giá trị của fs type đơn giản hơn */
	struct file_system_type *fs_type;
	/* Chứa private data, cấu trúc dữ liệu có thể được định nghĩa bởi developer của fs type */
	void			*fs_private;
	/* Root của mountable tree */
	struct dentry		*root;
	/* Namespace */
	struct user_namespace	*user_ns;
	struct net		*net_ns;
	/* Credentials */
	const struct cred	*cred;
	/* Source, chẳng hạn như /dev/sda1 hoặc host:/path */
	char			*source;
	char			*subtype;
	/* Security data của super block */
	void			*security;
	/* Dùng để phân biệt các supber block */
	void			*s_fs_info;
	unsigned int		sb_flags;
	unsigned int		sb_flags_mask;
	unsigned int		s_iflags;
	unsigned int		lsm_flags;
	/* FS_CONTEXT_FOR_MOUNT, FS_CONTEXT_FOR_SUBMOUNT hoặc FS_CONTEXT_FOR_RECONFIGURE */
	enum fs_context_purpose	purpose:8;
	/* Cut... */
};

Linux kernel sử dụng hàm alloc_fs_context() để tạo mới một đối tượng thuộc kiểu dữ liệu này. Trường ops của cấu trúc dữ liệu này là một con trỏ tới một đối tượng fs_context_operations, đối tượng này chứa các con trỏ hàm được sử dụng ở các giai đoạn khác nhau trong cơ chế mount của fs context.

1
2
3
4
5
6
7
8
9
10
11
12
13
struct fs_context_operations {
	/* Cleanup fs context */
	void (*free)(struct fs_context *fc); 
	/* Duplicate the fs-private data. */
	int (*dup)(struct fs_context *fc, struct fs_context *src_fc);
	/* Parse options */
	int (*parse_param)(struct fs_context *fc, struct fs_parameter *param);
	int (*parse_monolithic)(struct fs_context *fc, void *data);
	/* Sẽ gọi đến hàm fill_super() dùng để tạo mountable và superblock */
	int (*get_tree)(struct fs_context *fc);
	/* Reconfigure */
	int (*reconfigure)(struct fs_context *fc);
};

VFS cung cấp một số hàm để sử dụng cho mục đích tạo super block và root node (Được gọi từ get_tree() của fs context operations):

int get_tree_nodev(struct fs_context *fc,
		  int (*fill_super)(struct super_block *sb,
				    struct fs_context *fc));
int get_tree_single(struct fs_context *fc,
		  int (*fill_super)(struct super_block *sb,
				    struct fs_context *fc));
int get_tree_single_reconf(struct fs_context *fc,
		  int (*fill_super)(struct super_block *sb,
				    struct fs_context *fc));
int get_tree_keyed(struct fs_context *fc,
		  int (*fill_super)(struct super_block *sb,
				    struct fs_context *fc),
		void *key);

Cả 4 hàm trên đều là wrapper của hàm vfs_get_super(). vfs_get_super() có tác dụng tìm kiếm hoặc khởi tạo mới một super block nếu nó chưa tồn tại. Hàm này sẽ sử dụng con trỏ hàm fill_super được truyền vào để tạo một super block mới nếu cần thiết. Quá trình tìm kiếm được điều khiển bởi @keyring, @keyring có thể có các giá trị khác nhau như sau:

vfs_get_single_super Chỉ một super block của fs type này có thể tồn tại trong hệ thống.
vfs_get_keyed_super Các super block của fs type này cần có giá trị key khác nhau (key được lưu trong s_fs_info),
vfs_get_idependent_super Có thể tồn tại nhiều super block của fs type này và không cần key.

int (*parse_param)(struct fs_context *fc, struct fs_parameter *param);

sử dụng struct fs_parameter_spec và hàm fs_parse() để phân tích các tham số truyền vào. Mỗi đối tượng struct fs_parameter_spec giống như một entry trong từ điển, nó có một key, một value và có type, ví dụ:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct fs_parameter_spec {
	const char		*name;
	fs_param_type		*type;	/* The desired parameter type */
	u8			opt;	/* Option number (returned by fs_parse()) */
	unsigned short		flags;
	const void		*data;
};

static const struct fs_parameter_spec proc_fs_parameters[] = {
	fsparam_u32("gid",	Opt_gid),
	fsparam_string("hidepid",	Opt_hidepid),
	fsparam_string("subset",	Opt_subset),
	{}
};

Tùy thuộc vào kiểu dữ liệu khai báo mà VFS sẽ sử dụng hàm parser phù hợp, danh sách các hàm/kiểu dữ liệu được hỗ trợ bởi VFS có thể xem ở đây

VFS schema

Virtual File System was originally published by Nguyễn Đình Phi at Oni Ranger on January 26, 2022.

Hardware io

2019-04-15T00:00:00+08:00

Việc điều khiển các thiết bị đọc ghi ngoại vi thông thường sẽ bao gồm việc đọc và ghi vào các thanh ghi của các thiết bị đó. Các thanh ghi này thường được gọi là I/O ports.

1 Memory barriers.

Việc đọc ghi các bộ nhớ thông thường đều khá đơn giản: Ghi có nghĩa là lưu một giá trị vào một địa chỉ trong bộ nhớ, còn đọc là lấy ra giá trị gần đây nhất được ghi vào địa chỉ đó, nó không tạo ra side efect náo. Tuy nhiên, đối với I/O Register thì mọi việc lại khác, bởi vì việc đọc/ghi một I/O register có thể sẽ khiến device thực hiện một số hành động khác nhau nào đó. Do vậy việc caching hay reordering các instruction (thường được thực hiện bởi quá trình tối ưu hóa của Compiler) là không thể sử dụng được.

Kernel cung cấp giải pháp sử dụng các memory barrier để tránh các rủi ro này bằng các hàm sau:

barrier: Hàm này sẽ khiến cho compiler lưu các giá trị đang được thay đổi vào một thanh ghi CPU, nhưng không tạo ra bất kỳ ảnh hưởng nào đến hardware.
rmb() : Chèn một barrier vào mem và đảm bảo rằng các lệnh đọc trước barrier phải được hoàn thành trước khi bất kỳ lệnh đọc nào sau barrier được thực thi.
wmb() : Tương tự rmb(), nhưng là đối với lệnh ghi
mb() : Tương tự rmb(), nhưng áp dụng cho cả đọc và ghi.

Ngoài ra còn có các hàm smp_rmb(), smp_read_barrier_depends(), smp_wmb(), smp_mb() được sử dụng cho các hệ thống SMP. Bởi vì các barrier sẽ ảnh hưởng đến hiệu năng chung, nên chỉ sử dụng chúng khi thực sự cần thiết.

2. Đăng ký I/O ports.

Trước khi sử dụng I/O ports, chúng ta cần đăng ký với kernel việc sử dụng các port muốn dùng thông qua hàm request_region() và giải phóng vùng nhớ đã đăng ký bằng release_region sau khi sử dụng xong.

#include <linux/ioports.h>
struct resource *request_region(unsinged long from, unsigned long extent, const char *name);
void release_region(unsigned long from, unsigned long extent);

Trong các hàm này thì from chính là base address của I/O region, còn extent là số lượng port mà chúng ta muốn đăng ký/ giải phóng. Ngoài ra, chúng ta có thể kiểm tra xem các I/O port region nào đã được sử dụng bằng command cat /proc/ioports, nhớ phải chạy lệnh này bằng quyền sudo, ngược lại thì nó in ra toàn số 0.

Lưu ý là việc trên là không bắt buộc, bạn thậm chí có thể truy cập vào một I/O region kể cả khi việc đăng ký thất bại, tuy nhiên nguy cơ tiềm ẩn các BUG không đoán trước được và khó debug có thể xảy ra.

Một ví dụ đơn giản, module sample_ioport sẽ đăng ký một số I/O port sau đó sẽ giải phóng nó khi module exit.

#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");

int __init oni_init(void) {
  struct resource *res;
  //request region
  res = (struct resource *)request_region(0x380, 5, "oni_dev");
  if (res != NULL) {
    printk(KERN_INFO "Oni: Register region from 0x%llx to 0x%llx \n", res->start, res->end);
  } else {
    printk(KERN_ERR "Oni: Region has been claimed by other device\n");
    return -EBUSY;
  } 
	return 0;
}

void __exit oni_exit(void) {
  //release region
  release_region(0x380, 5);
  printk(KERN_INFO "Region freed\n");
}

module_init(oni_init);
module_exit(oni_exit);

Ở đây mình request 5 port bắt đầu từ vị trí 0x380, đây là một region mà mình thấy còn trống khi kiểm tra bằng cách cat nội dung của file proc/ioports. Sau khi insert module vừa viết vào hệ thống, thì dmesg sẽ có log như sau:

[ 7504.265791] Oni: Register region
[ 7764.511573] Oni: Register region
[ 8072.719936] Oni: Register region from 0x380 to 0x384

Hơn nữa, trong file ioports cũng có một entry mới được thêm vào:

$cat /proc/ioports | grep oni_dev
0380-0384 : oni_dev

Hàm request_region sẽ trả về một con trỏ tới cấu trúc struct resource, cấu trúc này đã được đề cập trong bài Platform device. Thực tế thì các hàm *_region() thật ra là wrapper của các hàm request_resource và release_resource, do đó bạn cũng có thể sử dụng các hàm *_resource để quản lý các I/O port.

3. Đọc và Ghi Dữ liệu với các I/O register.

Trong file asm/io.h, kernel định nghĩa các hàm đọc và ghi cho 8-bit, 16-bit và 32-bit ports.

Các hàm Đọc I/O Register

//Đọc một lần.
unsinged char inb(unsigned long port_address);
unsinged short inw(unsigned long port_address);
unsinged long inl(unsigned long port_address);
//Đọc nhiều lần : Đọc count bytes từ I/O port và ghi vào addr.
void insb(unsigned long port_address, void * addr, unsigned long count);
void insw(unsigned long port_address, void * addr, unsigned long count);
void insl(unsigned long port_address, void * addr, unsigned long count);

Các hàm Ghi I/O Register

//Đọc một lần.
unsinged char outb(unsigned char value, unsigned long port_address);
unsinged char outw(unsigned short value, unsigned long port_address);
unsinged char outl(unsigned long value, unsigned long port_address);
//Ghi nhiều lần : Ghi count bytes bắt đầu từ addr vào I/O port.
void insb(unsigned long port_address, void * addr, unsigned long count);
void insw(unsigned long port_address, void * addr, unsigned long count);
void insl(unsigned long port_address, void * addr, unsigned long count);

Nếu muốn test các hàm đọc ghi và bạn đang sử dụng một con PC intel, thì bạn có thể thử dùng I/O port từ 0x378 đến 0x37a của parallel port, nhưng đừng request_region mà cứ dùng thẳng các hàm outb() và inb().

4. Cấp phát, Mapping, và sử dụng I/O Memory.

Mặc dù phổ biến trong các thiết bị intel x86, nhưng I/O port không phải là kỹ thuật chính được sử dụng để Processor kết nối với các thiết bị ngoại vi, mà kỹ thuật đó chính là I/O Memory. I/O memory đơn giản là một vùng nhớ của thiết bị ngoại vi khả dụng để Processor có thể truy cập thông qua Bus. Vùng nhớ này có thể được sử dụng cho nhiều mục đích, chẳng hạn như để giữ các Gói dữ liệu, hoặc được sử dụng như các register tương tự I/O ports. Cách truy cập tới I/O memory phụ thuộc vào platform, nhưng việc này được implement bởi Kernel và nó là Transperent với Device driver.

Trước khi sử dụng I/O memory chúng ta cần cấp phát một vùng nhớ để sử dụng, và tương tự như đối với I/O ports, thì sau khi sử dụng chúng ta cần giải phsong nó:

struct resource *request_memory_region(unsigned long start, unsigned long len, char *name);
void release_mem_region(unsigned long start, unsigned long len);
int check_mem_region(unsigned long start, unsigned long len);

Tuy nhiên, với I/O memory thì việc cấp phát bộ nhớ là chưa đủ, bạn phải đảm bảo rằng kernel có thể truy cập vùng nhớ I/O memory của device, thông qua việc sử dụng ioremap(), hàm này sẽ map địa chỉ bộ nhớ ảo tới vùng nhớ I/O memory.

Việc đọc/ghi từ I/O memory được thực hiện bằng các hàm sau:

unsinged int ioread8(void *addr);
unsinged int ioread16(void *addr);
unsinged int ioread32(void *addr);

usinged int iowrite8(u8 val, void *addr);
usinged int iowrite16(u16 val, void *addr);
usinged int iowrite32(u32 val, void *addr);

Địa chỉ sử dụng trong các hàm này là địa chỉ được trả về bởi ioremap() + offset

Nếu bạn muốn đọc hay ghi nhiều giá trị thì có thể dùng các hàm thuộc họ io*_rep, tương tự như I/O port.

void ioread8_rep(void *addr, void *buf, unsigned long count);
void ioread16_rep(void *addr, void *buf, unsigned long count);
void ioread32_rep(void *addr, void *buf, unsigned long count);
void iowrite8_rep(void *addr, void *buf, unsigned long count);
void iowrite16_rep(void *addr, void *buf, unsigned long count);
void iowrite32_rep(void *addr, void *buf, unsigned long count);

Các thao tác đối với một block I/O Memory được thực hiện bởi các hàm:

void memset_io(void *addr, u8 value, unsigned int count);
void memcpy_fromio(void *dest, void *source, unsigned int count);
void memcpy_toio(void *dest, void *source, unsigned int count);

5. Ví dụ I/O memory.

Sau khi đã trình bày đầy đủ các lý thuyết rườm rà buồn ngủ, thì việc đưa ra một ví dụ về việc sử dụng các API trên để hiểu rõ hơn về chúng là điều cần thiết. Tốt nhất nếu có device thật thì nên thử viết các module tương tác với I/O mem của device đó, để xe các side effect của nó, tuy nhiên nếu không có device thật thì cũng đừng lo, vẫn có thể làm quen với việc sử dụng các API này bình thường. Sau đây mình sẽ tạo một module tương tác với một vùng nhớ ảo của hệ thống, sử dụng các API về I/O memory. Chương trình này sẽ là một character device driver, trong đó các hàm đọc ghi thay vì truy cập vào một vùng nhớ được tạo ra bằng kmalloc thì mình sẽ request và map một I/O memory region vào device này, và các hàm đọc ghi sẽ sử dụng các hàm ioread* và iowrite* để đọc và ghi dữ liệu vào vùng nhớ.

Chương trình này sẽ tương đối giống với chương trình ví dụ trong bài Character device, chỉ thêm bớt một số điểm nho nhỏ :v.

Mình sẽ chọn ghi vào I/O Memory region của VRAM, đầu tiên cần xác định xem region của nó là từ đâu đến đâu đã. Đầu tiên là dùng lspci để in ra danh sách các PCI device, và trên máy của mình thì entry của VGA là:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

Tức là chúng ta tìm device có id là 00:02.0 trong proc/iomem.

e0000000-efffffff : 0000:00:02.0
    f0000000-f0003fff : 0000:02:00.0
  f7800000-f7bfffff : 0000:00:02.0
    f7d00000-f7d00fff : 0000:02:00.0

Tức là base address của nó là 0xe0000000. Bây giờ define hai biến sau:

  #define VRAM_BASE 0xe0000000
  #define VRAM_SIZE 0x00020000

Lưu ý là cái địa chỉ này nó phụ thuộc vào máy của bạn, và các side effect xảy ra khi bạn đọc ghi trên vùng nhớ đó cũng phụ thuộc vào máy của bạn.

Trong hàm init của module, chúng ta sẽ request và remap cho memory region này:

oni_res = request_mem_region(VRAM_BASE, VRAM_SIZE, DEV_NAME);
if (oni_res == NULL) {
  printk(KERN_ERR "Memory region is busy\n");
  return EBUSY;
}

Ở đây biến oni_res là biến có kiểu strut resource * (code full sẽ có cuối bài).

Tiếp theo, thêm các hàm release và unmap vào hàm exit của module, để trả lại các địa chỉ này khi chúng ta không cần đến nó nữa.

iounmap(oni_vram);
release_mem_region(VRAM_BASE, VRAM_SIZE);

Tiếp theo, trong hàm read và writecủa file_operations mình sẽ dụng các hàm ioread8() và iowrite8 để đọc và ghi các giá trị vào vùng nhớ I/O memory đã yêu cầu. Sau đây là source code đầy đủ của chương trình.

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/version.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/uaccess.h>
#include <linux/ioport.h>
#include <asm/io.h>

#define MINOR_BASE 0
#define MINOR_COUNT 1
#define DEV_NAME "oni_map"
#define VRAM_BASE 0xe0000000
#define VRAM_SIZE 0x00020000

static void __iomem *oni_vram;
static struct cdev oni_mapdev;
static struct class *oni_class;
static struct device *oni_device;
static dev_t dev_num;
static struct resource *oni_res;

static int oni_open(struct inode* node, struct file* filp){
  printk(KERN_INFO "Device file just open\n");
  return 0;
}

static int oni_close(struct inode* node, struct file* filp){
  printk(KERN_INFO "Device file just close\n");
  return 0;
}

static ssize_t oni_read(struct file* filp, char __user *buffer, size_t count, loff_t* offset) {
  u8 byte;
  int i;
  if (*offset > VRAM_SIZE) {
    return -1;
  } 

  if (*offset + count > VRAM_SIZE) {
    count = VRAM_SIZE - *offset;
  }

  for (i = 0; i< count; i++){
    byte = ioread8(oni_vram + *offset + i);
    if (copy_to_user(buffer + i, &byte, 1)) {
      return -EFAULT;
    }
  }

  *offset += count;
  return count;
}

static ssize_t oni_write(struct file* filp, const char __user *buffer, size_t count, loff_t* offset) {
  u8 byte;
  int i;
  if (*offset > VRAM_SIZE){
    return -1;
  }
  
  if (*offset + count > VRAM_SIZE) {
    count = VRAM_SIZE - *offset;
  }

  for (i = 0; i < count; i++) {
    if (copy_from_user(&byte, buffer + i, 1)){
      return -EFAULT;
    }
    iowrite8(byte, oni_vram + *offset + i);
  }
  *offset += count;
  return count;
}

struct file_operations oni_fops = {
  .owner = THIS_MODULE,
  .open = oni_open,
  .release = oni_close,
  .write = oni_write,
  .read = oni_read
};

int __init oni_init(void) {
  int ret;

  //request memory region
  oni_res = request_mem_region(VRAM_BASE, VRAM_SIZE, DEV_NAME);
  if (oni_res == NULL) {
    printk(KERN_ERR "Memory region is busy\n");
    return EBUSY;
  }
  
  oni_vram = ioremap(VRAM_BASE, VRAM_SIZE);
  if (oni_vram == NULL) {
    printk(KERN_ERR "Memory remapping failed\n");
    release_mem_region(VRAM_BASE, VRAM_SIZE);
    return EBUSY;
  }

  ret = alloc_chrdev_region(&dev_num, MINOR_BASE, MINOR_COUNT, DEV_NAME);
  if (ret != 0)
    goto done;

  cdev_init(&oni_mapdev, &oni_fops); 
  ret = cdev_add(&oni_mapdev, dev_num, MINOR_COUNT);
  if (ret != 0){
    goto un_region;
  }

  oni_class = class_create(THIS_MODULE, DEV_NAME);
  if (IS_ERR(oni_class)) {
    goto del_dev;
  }

  oni_device = device_create(oni_class, NULL, dev_num, NULL, DEV_NAME);
  if (IS_ERR(oni_device)) {
    goto destroy_all;
  }

  return 0;

destroy_all:
  class_destroy(oni_class);
del_dev:
  cdev_del(&oni_mapdev);
  printk(KERN_ERR "Cannot create class\n");
un_region:
  unregister_chrdev_region(dev_num, MINOR_COUNT);
  printk(KERN_ERR "Cannot add device to kernel\n");
done:
  printk(KERN_ERR "Cannot allocate a device number\n");
  return -1;
}

void __exit oni_exit(void){
  device_destroy(oni_class, dev_num);
  class_destroy(oni_class);
  cdev_del(&oni_mapdev);
  unregister_chrdev_region(dev_num, MINOR_COUNT);
  iounmap(oni_vram);
  release_mem_region(VRAM_BASE, VRAM_SIZE);
}

module_init(oni_init);
module_exit(oni_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Phi Nguyen");

Sau khi đã hoàn thành source code, mình sẽ compile nó, và insert nó vào hệ thống

$sudo insmod onimap.ko

Sau đấy mình sẽ ghi nội dung linh tinh vào device file (tức là sẽ gọi đến hàm write), lệnh này phải chạy bằng quyền root.

$echo -n "132415645646598741346546467985413215676" > /dev/oni_map

Bây giờ đọc giá trị đã ghi vào bằng lệnh sau:

$sudo cat /dev/onimap

Kết quả là trên màn hình sẽ hiện ra giá trị mà mình đã ghi vào cộng với một lô một lốc các ký tự đặc biệt theo sau vì cái vùng nhớ này giá trị mặc định của các ô nhớ là cái gì đấy không thể hiện lên dưới dạng ascii.

Hardware io was originally published by Nguyễn Đình Phi at Oni Ranger on April 15, 2019.

Gpio Subsystem

2018-05-10T00:00:00+08:00

GPIO Pins trên máy Pi

A. GPIO Subsystem

GPIO là gì? GPIO là viết tắt của General Port Input output, các port này xử lý cả tín hiệu số cả vào lẫn ra. Khi hoạt động như một cổng vào, nó có thể được sử dụng để kết nối CPU với tín hiệu ON/OFF nhận được từ các công tắc (ví dụ các nút bấm trên router), hoặc đọc các tín hiệu số từ các sensor. Còn nếu hoạt động như một cổng ra, nó có thể truyền các tín hiệu điều khiển đến các thiết bị dựa trên kết quả của các lệnh thực thi trong CPU, chẳng hạn như điều khiển tín hiệu bật tắt của đèn LED (Cái này sẽ trình bày trong ví dụ). Các giá trị số vào/ra của GPIO chỉ có thể là 0 (LOW) hoặc 1(HIGH). Trong Linux kernel, để sử dụng GPIO, trước hết LKM cần phải giành lấy nó từ kernel, để trở thành chủ nhân của GPIO này, ngăn chặn việc các LKM khác truy cập vào cùng GPIO. Sau khi đã thành chủ sở hữu của GPIO, bạn có thể cài đặt chiều truyền tín hiệu số (Vào hoặc ra), thay đổi giá trị truyền vào đối với chiều ra, đọc giá trị nhận được đối với chiều vào, cấu hình các thứ linh tinh khác…

Có hai cách để làm việc với GPIO trong kernel, bao gồm:

Cách truyền thống (đã depreciate): biểu diễn các GPIO bằng các số int.
Cách mới: Biểu diễn bằng GPIO description.

I. Legacy GPIO interface trong Linux.

Mặc dù cách này đã bị đánh dấu là depreciate nhưng nó vẫn là cách được biết đến rộng rãi nhất. Các GPIO port được định danh bằng các số integer. Các function cần thiết được include từ header:

#include <linux/gpio.h>

1. Giành quyền sử dụng GPIO và cấu hình GPIO.

Bạn có thể chỉ định và giành quyền sử dụng của một GPIO bằng hàm gpio_request():

static int gpio_request(unsigned gpio, const char *label);

Tham số unsigned gpio chính là GPIO number, được biểu diễn dưới dạng số nguyên và label là tên sẽ được sử dụng bởi kernel trong sysfs. Hàm này sẽ trả về 0 nếu như việc request thành công, ngược lại nó sẽ trả về giá trị âm. Sau khi sử dụng xong GPIO, bạn nên giải phóng nó để những người khác có thể sử dụng:

static int gpio_free(unsigned gpio);

Ngoài ra, bạn cũng có thể kiểm tra xem GPIO number có hợp lệ hay không trước khi request nó:

static bool gpio_is_valid(int number);

Sau khi đã giành quyền sử dụng GPIO, bước tiếp theo cần làm là cài đặt chiều truyền tín hiệu số của nó, có 2 chiều: input và output được setup bằng hai hàm sau:

static int gpio_direction_input(unsigned gpio);
static int gpio_direction_output(unsigned gpio, value);

Tham số value trong trường hợp gpio output sẽ là giá trị mặc định được gán cho GPIO port đấy. Các hàm này nên được dùng trong context có thể ngủ được, thông thường chúng ta sẽ gọi những hàm này ở trong phần probe của driver.

2. Sử dụng legacy gpio để đọc ghi tín hiệu.

Việc truy cập GPIO thường liên quan đến các atomic context, đặc biệt là trong một interrupt handler, các đoạn code trong context này phải đảm bảo rằng GPIO controller callback function sẽ không thể ngủ. Một controller driver được thiết kế tốt sẽ có khả năng thông báo với các drivers khác việc lời gọi hàm có thể ngủ hay khôn. Việc này có thể được kiểm tra bằng : gpio_cansleep().

2.1 Trong atomic context.

Một số GPIO controller, đặc biệt là trên các SoC, có thể truy cập và quản lý thông qua các thao tác đọc ghi bộ nhớ thông thường, do đó việc ngủ nghỉ là không cần thiết. Đối với những GPIO này, gpio_cansleep() luôn luôn trả về giá trị false, và bạn có thể đọc/ghi giá trị ngay trong IRQ Handler với gpio_get_value() và gpio_set_value().

2.2 Trong non-atomic context.

Các GPIO controllẻ được nối vào buses, chẳng hạn như SPI và I2C thì những function truy cập các bus này là có thể dẫn đến việc sleep, do đó gpio_cansleep() function sẽ luôn luôn trả về true. Trong trường hợp này, bạn không nên truy cập các GPIO này bên trong IRQ handled (thay vào đó, truy cập nó trong bottom half thông qua threaded irq). Hơn nữa, hãy sử dụng các hàm đọc ghi thay thế sau là gpio_get_value_cansleep() và gpio_set_value_cansleep().

3. Ví dụ: sử dụng nút Reset đê bật tắt đèn LED trên Router wifi: Compex WPJ563.

Phần này mình sẽ ví dụ về việc sử dụng GPIO để thao tác với đèn LED và nút bấm, cũng như mapping từ GPIO Number sang IRQ number, ví dụ được thực hiện trên Board WPJ563, chạy firmware OpenWRT/LEDE. Bạn có thể xem hardware specific của nó ở đây: https://www.compex.com.sg/product/wpj563/. Dựa vào hardware specific, Board có 4 Đèn LED liên kết với các GPIO number:

GPIO1 : RSS1/EEPROM CLK
GPIO5 : RSS2/EEPROM data
GPIO6 : RSS3
GPIO7 : RSS4/Diag

Và một button: GPIO2: RESET. Ở ví dụ này mình sẽ dùng Button RESET trên để bật tắt các LED: RSS3 và RSS4. Module sẽ có tên là: wpj563_led

Trước hết, clone lede source ở đây: https://github.com/lede-project/source.git

Chúng ta sẽ tạo một package trong section kernel module để chứ module wpj563_led Chuyển đến thư mục chứa section kernel và tạo thư mục:

cd packages/kernel
mkdir wpj563-led

Bây giờ, bạn tạo một Makefile cho package mới, với nội dung như sau:

#copyright (C) 2018 Phi Nguyen
#
#

include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk

PKG_NAME:=wpj563-led
PKG_VERSION:=0.1
PKG_RELEASE:=1

include $(INCLUDE_DIR)/package.mk

define KernelPackage/wpj563-led
  SUBMENU:=Oni Modules
  TITLE:=Simple GPIO Button driver by Oni
  FILES:=$(PKG_BUILD_DIR)/gpio_legacy.ko
  AUTOLOAD:=$(call AutoLoad,30,gpio_legacy,1)
  KCONFIG:=
endef

define KernelPackage/wpj563-led/description
	legacy gpio
endef

MAKE_OPTS:= \
        $(KERNEL_MAKE_FLAGS) \
        SUBDIRS="$(PKG_BUILD_DIR)"

define Build/Compile
        $(MAKE) -C "$(LINUX_DIR)" \
                $(MAKE_OPTS) \
                modules
endef

$(eval $(call KernelPackage,wpj563-led))

Tiếp theo tạo thư mục src để chứa file source:

mkdir src
cd src

Chúng ta sẽ viết file C cho module ở đây, đặt tên là wpj563-led.c Đầu tiên, include các header cần thiết:

#include <linux/init.h> 
#include <linux/module.h> 
#include <linux/kernel.h> 
#include <linux/gpio.h>        /* For Legacy integer based GPIO */ 
#include <linux/interrupt.h>   /* For IRQ */

Khai báo các GPIO number sẽ dùng:

//Declare GPIO number of LEDs and BTNs
static unsigned int GPIO_LED_GREEN2 = 6;
static unsigned int GPIO_BTN1 = 2;
static unsigned int GPIO_LED_GREEN = 7;
static unsigned int irq;

Cũng như những module khác, chúng ta cần khai báo hàm init cho module

static int __init gpiohello_init(void)
{
    int retval;
}

Phần tiếp theo sẽ áp dụng những gì đã nói trong phần 1, 2 ahíhí. Trước hết check xem các GPIO number đã khai báo có chính xác không, bằng cách thêm đoạn code sau vào hàm gpiohello_init()

...
if (!gpio_is_valid(GPIO_LED_GREEN)||!gpio_is_valid(GPIO_BTN1)||!gpio_is_valid(GPIO_LED_GREEN2))
    {
        pr_info("Invalid GPIO\n");
        return -ENODEV;
    }

Tiếp theo chúng ta gửi yêu cầu quyền sử dụng các GPIO trên tới kernel:

...
gpio_request(GPIO_LED_GREEN, "green-led");
gpio_request(GPIO_LED_GREEN2, "green2-led");
gpio_request(GPIO_BTN1, "button-1");

Sau khi đã dành được quyền sử dụng, bước tiếp theo là set direction. Đối với GPIO tương ứng với button, thì mục đích của nó là đọc tín hiệu từ button truyền đến kernel, nên chúng ta sẽ set nó theo chiều input, còn GPIO của các đèn LED sẽ được setup là output, vì chúng ta muốn ghi giá trị HIgh/low vào nó để tắt/bật LED. Đối với WPJ563 thì High(1) nghĩa là tắt đèn còn Low(0) nghĩa là bật đèn. Chúng ta sẽ truyền giá trị khởi tạo là High(1).

...
gpio_direction_input(GPIO_BTN1);
gpio_direction_output(GPIO_LED_GREEN,1);
gpio_direction_output(GPIO_LED_GREEN2, 1);

Việc bấm nút sẽ tạo ra interrupt, chúng ta sẽ điều khiển đèn khi có interrupt xảy ra, do đó cần liên kết Button GPIO trên với một Interrupt Line và đăng ký threaded handler cho nó:

    ...
    irq =  gpio_to_irq(GPIO_BTN1);
    retval = request_threaded_irq(irq, NULL, (irq_handler_t)btn1_pushed_irq_handler, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT, "Oni GPIO", NULL);
    if(retval < 0){
        pr_err("ONI_GPIO: Interrupt number %d isn't free\n",irq);
        gpio_free(GPIO_LED_GREEN2);
        gpio_free(GPIO_LED_GREEN);
        gpio_free(GPIO_BTN1);

        pr_info("ONI_GPIO: The Earth rejected you\n");
        return retval;
    }

Hàm gpio_to_irq() sẽ trả về interrupt line tương ứng với GPIO number mà chúng ta truyền vào. Hàm request_threađe_irq() ở trên sẽ gán hàm btn1_pushed_irq_handler() như là bottom half của interrupt handler cho irq line, và sử dụng hàm top half mặc định. (Cái này mình đã trình bày trong bài về Interrupt).

Rõ ràng chúng ta đang thiếu hàm btn1_pushed_irq_handler(), định nghĩa hàm này ở trước hàm init của module (ngay sau phần khai báo các gpio number):

static irq_handler_t btn1_pushed_irq_handler(unsigned int irq, void *dev_id, struct pt_regs *regs)
{
    int state, oni_led_state;
    state = gpio_get_value(GPIO_BTN1);
    oni_led_state = gpio_get_value(GPIO_LED_GREEN2);
    oni_led_state = 1-oni_led_state;
    gpio_set_value(GPIO_LED_GREEN2, oni_led_state);
    gpio_set_value(GPIO_LED_GREEN, oni_led_state);

    pr_info("GPIO_BTN1 interrupt: Interrupt! GPIO_BTN1 state is %d\n", state);
    return (irq_handler_t)IRQ_HANDLED;
}

Giải thích về hàm này: Trong hàm này chúng ta sẽ in ra giá trị của button (0 hoặc 1). Cùng với 1 biến oni_led_state để lưu giá trị hiện tại của led, mỗi lần gọi hàm chúng ta sẽ đổi giá trị của biến này và ghi nó vào các LED GPIO để thay đổi trạng thái của các đèn LED.

Phần còn lại là hàm exit module và các Macro linh tinh:

static void __exit gpiohello_exit(void)
{
    free_irq(irq, NULL);
    gpio_free(GPIO_LED_GREEN2);
    gpio_free(GPIO_LED_GREEN);
    gpio_free(GPIO_BTN1);

    pr_info("End of the world\n");
}

module_init(gpiohello_init);
module_exit(gpiohello_exit);

MODULE_AUTHOR("Phi Nguyen");
MODULE_LICENSE("GPL");

Lưu file này lại, sau đó cũng trong thư mục src này, chúng ta tạo file Makèile cho module:

echo "obj-m += gpio_legacy.o" > Makefile

OK. Done, Package đã xong, bây giờ đến đoạn config và build firmware mới. Đầu tiên phải cd quay lại thư mục source của LEDE:

./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig

Tại đây, config các trường cần thiết như sau:

    Target System (Atheros AR7xxx/AR9xxx)
    Subtarget (Generic)
    Target Profile (Compex WPJ563 (16M flash))

    Kernel modules —> 
        Oni Modules ->
            (*) Simple GPIO Button driver by Oni

build nó nào: make

Sau khi hoàn thành, file firmware sẽ là: bin/targets/ar71xx/generic/openwrt-ar71xx-generic-wpj563-squashfs-sysupgrade.bin

Flash nó bằng các command sau (chạy trong uboot):

tftp 0x80060000 openwrt-ar71xx-generic-wpj563-squashfs-sysupgrade.bin
erase 0x9f030000 +$filesize;cp.b $fileaddr 0x9f030000 $filesize;boot

Lúc mới khởi động xong thì cả 2 đèn LED đều bị tắt. Sau khi nó khởi động xong, bạn cần vào /etc/rc.button xóa hết các file trong này đi rồi reboot lại, nếu không lúc bấm nút nó sẽ Reboot board =)).

Đây là nút bấm: (push button): OK, bây giờ bấm nút và tận hưởng thành quả thôi. Sau khi bấm nút thì đèn sẽ sáng lên như này, bây giờ bấm 1 lần nữa thì đèn sẽ bị tắt.

II. GPIO interface dựa trên descriptor.

Đối với descriptor-based GPIO, một GPIO được mô tả bằng cấu trúc:

struct gpio_desc{
    struct gpio_chip *chip;
    unsigned log flags;
    const char *label;
};

Cấu trúc này nằm trong header:

	#include <linux/gpio/consumer.h>

Trước khi cấp phát và giành quyền sử dụng GPIO, những GPIO này phải được ánh xạ tới đâu đó, tức là chúng phải được gắn với device của bạn (đối với integer-based, thì chúng ta chỉ cần request gpio number và dùng là được). Các phương pháp ánh xạ (mapping) gồm có:

Platform data mapping: Thực hiện trong board file.
Device tree: Thực hiện bằng device tree.
ACPI: Sử dụng ACPI mapping, thường được sử dụng trong các system x86.

1. Cấp phát và sử dụng descriptor-base GPIO

Bạn có thể sử dụng gpiod_get() hoặc gpio_get_index() để cấp phát một GPIO descriptor:

struct gpio_desc *gpiod_get_index(struct device *dev, const char *const_id, unsigned int idx, enum gpio_flags flags);
struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags);

Hai hàm này trả về cấu trúc GPIO descriptor tương ứng với GPIO đã được truyền vào, điểm khác nhau là hàm đầu tiên thế trả về GPIO theo index trong biến idx, còn hàm thứ hai sẽ trả về GPIO ở index 0, (nếu bạn kiểm tra kernel sourc, thì sẽ thấy hàm thứ 2 thật ra chỉ là 1 lời gọi đến hàm thứ nhất). dev là device mà GPIO descriptor thuộc về. flag dùng để cấu hình chiều truyền của GPIO, nó là một thể hiện của enum gpio_flags:

enum gpio_flags{
    GPIOD_ASIS = 0,
    GPIOD_IN = GPIOD_FLAGS_BIT_DIR_SET,
    GPIOD_OUT_LOW = GPIOD_FLAGS_BIT_DIR_SET |
                    GPIOD_FLAGS_BIT_DIR_OUT,
    GPIOD_OUT_HIGH = GPIO_FLAGS_BIT_DIR_SET |
                    GPIO_FLAGS_BIT_DIR_OUT |
                    GPIO_FLAGS_BIT_DIR_VAL,
};

Sau khi đã cấp phát và dành quyền sử dụng GPIO, chúng ta có thể thao tác đọc, ghi thay đổi debounce với các hàm sau:

int gpiod_direction_input(struct gpio_desc *desc); 
int gpiod_direction_output(struct gpio_desc *desc, int value);
int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
struct gpio_desc *gpio_to_desc(unsigned gpio); 
int desc_to_gpio(const struct gpio_desc *desc);
int gpiod_get_value(const struct gpio_desc *desc); 
void gpiod_set_value(struct gpio_desc *desc, int value);

B. GPIO Controller Driver.

Bây giờ chẳng may chúng ta vào kernel config và set CONFIG_GPIO_ATH79 bằng No, và quay lại insert cái module vừa viết vào kernel thì sẽ không thấy con bò gì xảy ra nữa, có thể sẽ xuất hiện những pha chửi thề mạnh mẽ: sao *** chạy nữa. Không chạy là chuẩn cmnr, vì trong Linux thì GPIO subsystem được hiện thực bằng một cái giống như provider-consumer design pattern ấy. Cái module ở trên vừa viết nó chỉ là consumer thôi, còn cái provider là một thằng khác, thường được implement bằng struct gpio_chip hoặc struct irq_chip gọi là gpio controller (sai thì thôi). :v

Gpio Subsystem was originally published by Nguyễn Đình Phi at Oni Ranger on May 10, 2018.

Platform Device

2018-05-01T00:00:00+08:00

I. Platform Devices và drivers.

Platform device là gì ? Một số người cho rằng platform device là các device được tích hợp sẵn trong các SoC. Tuy nhiên thực tế điều này không hoàn toàn đúng. Các platform device là các thiết bị không thể liệt kê được bởi hệ thống (tức là not-hotplug, khi bạn cắm một thiết bị mới vào thì OS không hề biết rằng bạn vừa thêm vào 1 cái gì đấy, khác với hotplug như USB hay PCI), do đó kernel cần phải biết về những thiết bị này từ trước lúc khởi động (tức là chúng ta phải đăng ký những thiết bị này với kernel lúc build kernel). Một số ví dụ về các thiết bị này gồm có: I2C, UART, SPI, …

Nhìn từ góc độc kernel, những thiết bị này là các thiết bị gốc, và không kết nối đến bất kỳ cái gì cả (tức là nó là 1 phần của kernel). Trong kernel, nó sử dụng các pseudo platform bus, còn được gọi là các platform bus như là một bus ảo của kernel cho các thiết bị không nằm trên các Bus vật lý mà kernel có thể biết đến.

Trong file header linux/platform_device.h có định nghĩa 2 driver model interface cho platform bus nêu ở trên, gồm có:

struct platform_device;
struct platform_driver;

1. Platform drivers

Platform driver tuân theo quy ước chuẩn của driver model, ở đó việc phát hiện/liệt kê các thiết bị được thực hiện bên ngoài các driver, và các driver cung cấp hàm probe() và remove. Chúng cung cấp các công cụ quản lý năng lượng theo tiêu chuẩn cơ bản.

    struct platform_driver{
        int (*probe)(struct platform_device *);
        int (*probe)(struct platform_device *);
        void (*shutdown)(struct platform_device *);
        int (*suspend)(struct platform_device *, pm_message_t state);
        int (*resume_early)(struct platform_device *);
        int (*resume)(struct platform_device *);
        struct device_driver driver;
    };

lưu ý rằng hàm probe() nói chung nên xác thực xem phần cứng của thiết bị đã được chỉ ra thực sự tồn tại. Probing có thể sử dụng device resource bao gồm clock, và device platform_data.

Platform drivers đăng ký nó với hệ thống bằng cách sau:

int platform_driver_register(struct platform_driver *drv);

Hoặc sử dụng hàm sau trong init section:

int platform_driver_probe(struct platform_driver *drv, int(*probe)(struct platform_device*))

Các kernel module có thể được bao gồm nhiều platform drivers. Platform core cung cấp các hàm trợ giúp để đăng ký và hủy đăng ký một mảng các driver:

	int __platform_register_drivers(struct platform_driver * const *drivers,
				      unsigned int count, struct module *owner);
	void platform_unregister_drivers(struct platform_driver * const *drivers,
					 unsigned int count)

Nếu một trong các driver đăng ký thất bại thì tất cả các drivers trong batch đều bị unregister. (Transaction)

Lưu ý là không phải tất cả platform device được được handle bằng platform driver.

Platform driver phải hiện thực một hàm probe(), được gọi bởi kernel khi module được inserted hoặc khi một device yêu cầu driver đó. Khi phát triển một platform driver, cấu trúc chính mà chúng ta cần sử dụng là struct platform_driver, bạn cần định nghĩa các trường (functions) cơ bản của cấu trúc này trước khi đăng ký nó với platform bus core.

Ví dụ

static struct platform_driver mydrv = {
    .probe  = my_pdrv_probe,
    .remove = my_pdrv_remove,
    .driver = {
        .name = "my_platform_driver",
        .owner = THIS_MODULE,
    },
};

- probe(): Đây là hàm được gọi khi thiết bị đòi hỏi driver ở lần đầu tiên, nó được khai báo như sau:

            static int my_pdrv_probe(struct platform_device *pdev);

- remove(): hàm này được gọi khi device không còn sử dụng driver nữa, khai báo như sau:

            static int my_pdrv_remove(struct platform_device *pdev);

Đăng ký platform driver với kernel rất bằng cách gọi hàm platform_driver_register() hoặc platform_driver_probe() trong hàm init. Hai hàm này khác nhau ở điểm nào? - platform_driver_register() đăng ký và đặt driver vào danh sách các driver được bảo trì bởi kernel, do đó hàm probe() của driver có thể được gọi theo yêu cầu (tức là gọi khi có một device mới xuất hiện và match với signature). - palatform_driver_probe(), kernel ngay lập tức chạy một vòng lặp, kiểm tra xem nếu có một platform device match với driver (bằng trường .name) và sau đó gọi hàm probe() nếu nó thấy device match. Điều này có nghĩa là device phải đang kết nối với bus slot khi đăng ký, ngược lại nó sẽ bị bỏ qua. Hàm này nên đặt trong __init() section để đảm bảo là nó sẽ bị giải phóng sau khi quá trình khởi động kết thúc (ngược lại vòng lặp tiếp tục chạy sẽ rất tốn tài nguyên)

Tiếp theo chúng ta sẽ thử viết một platform driver đơn giản, nhiệm vụ của nó là tự đăng ký nó với kernel.

/*File oni_pdriver.c*/
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>

static int my_pdrv_probe(struct platform_device *pdev){
    pr_info("Hello! device probed! \n");
    return 0;
}

static void my_pdrv_remove(struct platform_device *pdev){
    pr_info("Good bye!!!!!!!!!");
}

static struct platform_driver mydrv = {
    .probe      = my_pdrv_probe,
    .remove     = my_pdrv_remove,
    .driver     = {
        .name = "oni_pdev",
        .owner = THIS_MODULE,
    },
};

static init __init my_drv_init(void){
    pr_info("Hello Guy\n");

    /*Registering with Kernel */
    platform_driver_register(&mypdrv);
    return 0;
}

static void __exit my_pdrv_remove(void){
    pr_info("Good bye Guy\n");
    /*Unregistering from Kernel*/
    platform_driver_unregister(&my_drv);
}

module_init(my_pdrv_init);
module_exit(my_pdrv_remove);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Phi Nguyen");
MODULE_DESCRIPTION("HIHI");

Hãy compile vào insert nó vào kernel xem có chuyện gì xảy ra.

2. Platform device

Bao gồm: các device sử dụng I/O port truyền thống, các host bridges đến các peripheral bus, và hầu hết các controller được tích hợp vào SoC. Platform device không kết nối đến các bus vật lý mà nó chỉ kết nối đến psuedo bus. Điểm chung của các thiết bị này là: đánh địa chỉ trực tiếp từ một CPU bus. Đôi khi (rất hiếm), một platform_device sẽ được kết nối thông qua một hoặc một số loại bus khác; nhưng các thanh ghi cảu nó vẫn được đánh địa chỉ một cách trực tiếp.

Các platform device có một tên (name field), được sử dụng trong driver binding, và một danh sách các tài nguyên chẳng hạn như addresses và IRQs. Sau khi bạn đã thực hiện xong driver, bạn sẽ phải đưa cho kernel một hoặc nhiều device sẽ cần đến driver đó. Một platform driver được biểu diễn trong kernel như một thực thể của cấu trúc sau:

struct platform_device{
    const char      *name;
    u32             id;  
    struct device   dev;
    u32             num_resources;
    struct resource *resource;
};

Trường name cần phải trùng với trường name của platform_driver ở phần 1.

2.1 Tài nguyên và thông tin dữ liệu của platform device

Đối với các hot-pluggable devices, kernel biết rằng device đó là gì, có khả năng gì và cần gì để có thể hoạt động tốt, ngược lại, kernel không hề biết về các platform device, do đó, việc cung cấp thêm các thông tin cho kernel là cần thiết. Có hai phương thức để thông tin cho kernel về các tài nguyên (irq, dma, mem, region, bus, I/O ports) và dữ liệu (những dữ liệu riêng tư mà driver có thể cần đến) là device provisioning và [?]

2.1.2. Device provisioning (cũ và không khuyên dùng)

Khai báo trong mach files

a. Tài nguyên (resource).

Nhìn từ góc độ phần cứng, tài nguyên hay resource là tất cả các thành phần đặc tả cho đevice, và đấy là những gì device cần cho mục địch cài đặt và hoạt động chính xác. Có 6 loại resource trong kernel, được liệt kê trong header include/linux/ioport.h, các loại resource này được define và sử dụng như các cờ để định loài cho resouce.

#define IORESOURCE_IO  0x00000100  /* PCI/ISA I/O ports */ 
#define IORESOURCE_MEM 0x00000200  /* Memory regions */ 
#define IORESOURCE_REG 0x00000300  /* Register offsets */ 
#define IORESOURCE_IRQ 0x00000400  /* IRQ line */ 
#define IORESOURCE_DMA 0x00000800  /* DMA channels */ 
#define IORESOURCE_BUS 0x00001000  /* Bus */

Trong kernel, một resource được biểu diễn như là một thực thể của cấu trúc sau:

struct resource {
    resource_size_t start;
    resource_size_t end;
    const char *name;
    unsigned long flags;
};

Ở đây: start/end : là vị trí bắt đầu và kết thúc của resource. ĐỐi với I/O hoặc memory regions, thì đây chính là nơi chúng bắt đầu/kết thúc (address). ĐỐi với các kiểu resource IRQ lines, buses hay DMA channels thì start và end phải có cùng giá trị. Flags là một mặt nạ để định loại cho resource (các IORESOURCE_* đã nêu ở trên). Tên là định danh của resource.

Khi chúng ta khai báo resource cho platform device thì chúng ta cần lấy nó ra trong driver code để làm việc với nó. Hàm probe() là một vị trí thích hợp cho việc này. Tham số *pdev trong hàm probe() được điền một cách tự động bởi kernel với đầy đủ data và resource đã khai báo ở trên. Để lấy resource ra từ pdev chúng ta sử dụng hàm sau:

struct resource *platform_get_resource(struct platform_device *pdev, unsigned int type, unsigned int num);

Nếu resource là một IRQ, thì chúng ta có thể dùng cách đơn giản hơn, là sử dụng hàm sau:

int platform_get_irq(struct platform_device *pdev, unsigned int num);

b. Data (Dữ liệu).

Bao gồm các dữ liệu không nằm trong các Resource type ở trên, ví dụ như GPIO. Như chúng ta đã biết struct platform_device có chứa trường dev có kiểu struct device, cấu trúc này là chứa một trường có kiểu struct platform_data, đây là nơi chúng ta lưu platform data. THử tìm hiểu một ví dụ sau (code này mình tóm từ trên mạng về, hí hí):

struct my_gpios{
    int reset_gpio;
    int led_gpio;
};

static struct my_gpios needed_gpios={
    .reset_gpio = 47,
    .led_gpio = 41
};

static struct resource needed_resources[] = {
    [0] = {/*The first memory region*/
        .start = JZ4740_UDC_BASE_ADDR,
        .end = JZ4740_UDC_BASE_ADDR + 0x10000 - 1,
        .flags = IORESOURCE_MEM,
        .name = "mem1",
    },
    [1] = {
        .start  = JZ4740_UDC_BASE_ADDR2,
        .end    = JZ4740_UDC_BASE_ADDR2 + 0x10000 - ,
        .flags  = IORESOURCE_MEM,
        .name   = "mem2",
    },
    [2] = {
        .start  = JZ4740_IRQ_UDC,
        .end    = JZ4740_IRQ_UDC,
        .flags  = IORESOURCE_IRQ,
        .name   = "mc",
    }
};

static struct platform_device my_device = {
    .name   = "my-platform-device",
    .id     = 0,
    .dev    = {
        .platform_data  = &needed_gpios,
    },
    .resource   =  needed_resources,
    .num_resources = ARRY_SIZE(needed_resources),
},

platform_device_register(&my_device);

Để lấy platform_data đã khai báo, chúng ta làm như sau:

void *dev_get_platdata(const struct device *dev);
struct my_gpios *picked_gpios = dev_get_platdata(&pdev->dev);

II. Kernel Kết hợp platform device với platform driver như thế nào?

Làm thế nào kernel biết được device nào được điều khiển bởi driver nào? Câu trả lời là MODULE_DEVICE_TABLE. Macro này sẽ giúp driver đưa ra một bảng ID của nó, bảng này mô tả những device mà nó có thể hỗ trợ. Trong khi chờ đợi, nếu như driver có thể được biên dịch như là một module (thay vì built-in), trường driver.name nên trùng với module name. Nếu không, module sẽ không thể load một cách tự động, trừ khi chúng ta đã sử dụng MODULE_ALIAS macro để thêm một tên khác cho module. Ở thời điểm biên dịch, những thông tin này sẽ được đọc từ tất cả các driver để tạo ra một bảng device table. Khi kernel phải tìm kiếm driver cho một device, kernel sẽ duyệt qua device table. Nếu kernel tìm thấy một driver (table row) phù hợp với compatible, hoặc device/vendor id, hoặc name của device được thêm vào, thì module đã cung cấp thông tin để tạo nên row đó sẽ được load, và probe function sẽ được gọi với tham số truyền vào là device tương ứng.

#include <linux/module.h>
#define MODULE_DEVICE_TABLE(type, name)

Ở đây trường type có thể là i2c, spi, of, platform, usb, pci hoặc bất kỳ bus nào khác đã được định nghĩa bởi kernel trong file mod_devicetable.h. Nó phụ thuộc vào bus mà device ngồi, và phục thuộc vào kỹ thuật matching bạn muốn dùng. CÒn trường name là một con trỏ đến một mảng xxx_device_id, được sử dụng cho mục đích matching device. xxx chính là tên của bus bạn muốn dùng, hoặc of_device_id nếu bạn dùng device tree.

Kernel thực hiện việc match platform device với driver thông qua hàm platform_match được định nghĩa trong file /drivers/base/platform.c:

static int platform_match(struct device *dev, struct device_driver *drv)
{
    struct platform_device *pdev = to_platform_device(dev);
    struct platform_driver *pdev = to_platform_driver(dev);

    /*Nếu driver_override được định nghĩa, thì chỉ bind với matching driver */
    if(pdev->driver_override)
        return !strcmp(pdev->driver_override, drv->name);
    /*Thực hiện match theo style OF trước */
    if(of_driver_match_device(dev, drv))
        return 1;
    /* Thực hiện ACPI match */
    if(acpi_driver_match_device(dev,drv))
        return 1;
    /*Id table */
    if(pdrv->id_table)
        return platform_match_id(pdrv->id_table, pdev) != NULL;
    
    /*Fall-back to driver name match */
    return (strcmp(pdev->name, drv->name) == 0);
}

Thật ra mấy cái hàm matching trên chỉ là so sánh xâu mà thôi.

Bây giờ, mình sẽ viết một platform device để phối kết hợp với cái platform driver ở trên. Mình sẽ viết platform device trong một file mới đặt tên là oni_pdev. Trước hết chúng ta sẽ định nghĩa ra một struct để lưu giữ platform data. Cấu trúc này mình sẽ định nghĩa ra 2 trường là tên và tuổi (y như bài tập hồi sing viên :v). Tuy nhiên thay vì định nghĩa vào file oni_pdev.c, mình thực hiện điều này trong một file header mới tên là oni_pp.h vì chúng ta cần sử dụng struct này trong file platform driver.

/*file oni_pp.h*/
struct oni_pdata{
    char* name;
    int age;
};

Quay lại file oni_pdev.c, điều đầu tiên tất nhiên là include file header ở trên vào. Tiếp theo chúng ta khai báo platform data instance và resource cho device như sau:

/*resource là mảng các struct, chúng ta chỉ cần 1 element thôi*/
struct resource oni_rs[]={
    {
        .name = "oni_rs",       //Tên !important
        .flags = IORESOURCE_MEM,
        .start = 0x00,
        .end = 0x10,
    },
};

/*platform data instance*/
struct oni_pdata oni_pdev={
    .name = "Phi Nguyen",
    .age = 25,
};

Sau khi đã có data và resource, mình sẽ khai báo platform_device của mình:

struct platform_device oni_device = {
    .name = "oni_device",   //Tên ở đây phải trùng với tên ở struct platform_driver đã viết ở phần trước*/
    .id = 0,
    .resource = oni_rs,
    .num_resources = 1,
    .dev = {
        .platform_data = &oni_pdev,
    }
};

Tiếp theo mình sẽ đăng ký platform device này ở trong hàm init của module và insmod module vào hệ thống.

Bây giờ mình sửa lại file oni_pdriver.c ở phần I một chút để có thể hiển thị rõ hơn việc pdriver và pdevice đã được matching với nhau. Trong hàm my_pdriver_probe() mình sẽ thay dòng code

    pr_info("Hello! device probed! \n");

bằng đoạn code sau:

    struct oni_pdata* odp = dev_get_platdata(&pdev->dev);
    pr_info("Our device has name %s and age %d\n", odp->name, odp->age);

Quên mất là phải include file header đã tạo vào nữa. Sau đấy rebuild nó và insmod vào kernel. Kiểm tra dmesg, bạn sẽ thấy dòng log sau: Our device has name Phi Nguyen and age 25 Đây là data chúng ta đã khai báo cho platform device.

Platform Device was originally published by Nguyễn Đình Phi at Oni Ranger on May 01, 2018.

Interrupts

2018-03-21T00:00:00+08:00

Các interrupt được tạo ra từ các tín hiệu điện từ thiết bị phần cứng dùng để thông báo cho interrupt controler khi có sự kiện gì đó xảy ra, và nó cần được xử lý. Khi Interrupt controler nhận được một interrupt, nó sẽ gửi một tín hiệu tới Processor. Processor phát hiện tín hiệu này và nó sẽ tạm ngắt công việc nó đang thực thi để xử lý interrupt. Processor có thể thông báo cho OS, và OS sẽ xử lý interrupt này một cách hợp lý. Các device khác nhau được liên kết với các interrupt khác nhau. Điều này cho phép OS phân biệt được các interrupt và biết được thiết bị nào tạo ra ịnterrupt đó.

Lưu ý: Interrupt handler chạy trong interrupt context, khác với process context, interrupt context không ngắt được

1. Cài đặt một interrupt handler.

Interrupt handler là một software handler được cấu hình để xử lý các interrupt. Tất nhiên, cũng như driver, chúng ta cần đăng ký interrupt với Linux kernel, nếu không nó sẽ không biết và bỏ qua.
Trong kernel chỉ một có một số lượng hữ hạn resource cho các interrupt line (theo ldd3 là 15-16 line, nhưng sách này cũ rồi, không biết giờ đã thay đổi gì chưa). Kernel giữ một sổ đăng ký (giống reg trong windows) các interrupt line. Một module muốn yêu cầu một interrupt channel( hoặc IRQ) trước khi sử dụng nó và sẽ giải phóng nó khi hoàn thành (Vì số lượng có hạn nên phải giải phóng để đứa khác còn dùng), trong nhiều trường hợp, các module cũng có thể chia sẻ interrupt line với các driver khác.
Để đăng ký interrupt, chúng ta sử dụng hàm sau:

int request_irq(unsigned int irq, irqreturn_t (*handler)(int, void *, struct pt_regs *),
				unsigned long flags, const char *dev_name, void *dev_id);

Hàm này trả về giá trị 0 nếu việc request thành công, ngược lại nó sẽ trả về giá trị âm nếu thất bại. Hàm này sử dụng các tham số với ý nghĩa cụ thể như sau:
unsigned int irq Interrupt number đang được request.
irqreturn_t (*handler)(int, void*, struct pt_regs *) Đây là con trỏ tới handler function sẽ được cài đặt.
unsiged long flags Trong các Moderm kernel thì có thể k cần quan tâm nó nữa
const char *dev_name Đây là tên sẽ được show ra trong file /proc/interrupts
void *dev_id Con trỏ được sử dụng cho các shared interrupt line. Tốt nhất là kể cả khi không có shared interrupt thì vẫn nên trỏ con trỏ này đến device structure.

Sau đó sử dụng hàm sau để giải phóng nó

void free_irq(unsigned int irq, void *dev_id);

Cả hai hàm này đều được khai báo trong file linux/interrupt.h

Interrupt handler có thể được cài đặt tại thời điểm khởi tạo driver hoặc thời điểm device được open lần đầu tiên (hàm open của file_operations). Do số interrupt line là có hạn nên việc cài đặt interrupt handler ở thời điểm khởi tạo driver là không nên, bởi vì khả năng cao là số lượng device trong máy tính sẽ nhiều hơn số interrupt line, các device đến sau sẽ không thể lấy được interrupt line, kể cả khi các device đến trước chỉ giữ interrupt line mà để nó mốc meo không động gì dến nó. Vì thế recommend là request interrupt line ở thời điểm device open lần đầu tiên và sau đó giải phóng nó tại thời điểm device được đóng, sau khi hardware inform rằng sẽ không interrupt nữa. Hạn chế của kỹ thuật này đó là chúng ta cần phải giữ một biến đếm (cho mỗi driver) để biết khi nào thì có thể giải phóng interrupt.

Mỗi khi một hardware interrupt đến được processor, một counter sẽ được tăng lên, cung cấp một công cụ hữu ích để kiểm tra xem device có đang hoạt động như mong muốn hay không. Các interrupt được show trong file /proc/interrupts. Ví dụ

           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:       8115          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          2          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:          4          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:         25          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, snd_hda_intel
 23:         28          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb2
 40:          0          0          0          0          0          0          0          0  DMAR_MSI-edge      dmar0
 41:          0          0          0          0          0          0          0          0  DMAR_MSI-edge      dmar1
 42:          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      PCIe PME, pciehp
 43:          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      PCIe PME
 44:          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      PCIe PME
 45:   19112759          0          0          0          0          0          0          0  IR-PCI-MSI-edge      eth0
 46:        113          0          0          0          0          0          0          0  IR-PCI-MSI-edge      xhci_hcd
 47:   48445205          0          0          0          0          0          0          0  IR-PCI-MSI-edge      ahci
 48:        290          0          0          0          0          0          0          0  IR-PCI-MSI-edge      snd_hda_intel
NMI:      47262      34998      32245      34010      15699      15260      15118      15351   Non-maskable interrupts
LOC:   37630561   27204803   26168237   25823765   14453398   14292455   15021111   15100351   Local timer interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
PMI:      47262      34998      32245      34010      15699      15260      15118      15351   Performance monitoring interrupts
IWI:          0          0          0          0          0          0          0          0   IRQ work interrupts
RES:   13920936   18893192   16083423   14075673    1484409    1376323    1211626    1590645   Rescheduling interrupts
CAL:       1707       2180       2155       2230       2342       2344       2326       2231   Function call interrupts
TLB:    2073986    1829542    1841565    1829222    3144535    3116096    3104140    3125559   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0          0          0          0          0   Machine check exceptions
MCP:       8075       8075       8075       8075       8075       8075       8075       8075   Machine check polls
ERR:          0
MIS:          0

Cột đầu tiên là IRQ number, nó chỉ show ra các IRQ của các handlers đã được cài đặt (tại thời điểm in file này ra). Các cột tiếp theo là số interrupt đã tiếp nhận của mỗi CPU. Cột cuối cùng device name (lúc request interrupt có ghi vào).

Một trong những vấn đề thách thức nhất khi khởi tạo driver là làm thế nào để xác định xem IRQ line nào sẽ được sử dụng bởi device. Driver cần thông tin này để đăng ký handler một cách chính xác. Trong trường hợp này, kernel cung cấp 2 funciton để probing irq là:

unsigned long probe_irq_on(void);
int probe_irq_off(void);

Kỹ thuật sử dụng: Đầu tiên lấy mask bằng cách gọi probe_irq_on(), sau đó generate một số interrupt, rồi kiểm tra bằng probe_irq_off xem có thành công hay không.

2. Viết một interrupt handler trong driver.

Về cơ bản, một interrupt handler chỉ là một hàm C thông thường. Điểm khác biệt ở đây là hàm này sẽ chạy ở interrupt context, do đó nó có một số hạn chế đối với các hàm chạy trong process context: Một handler không thể truyền dữ liệu hoặc nhận dữ liệu từ user space, không thể sleep, không thể lock một semaphore và chỉ có thể cấp phát bộ nhớ với cờ GFP_ATOMIC.

Nhiệm vụ của interrupt handler là feedback cho device về việc nhận được interrupt và đọc hoặc ghi dữ liệu dựa vào ý nghĩa của interrupt (IRQ) nhận được. Thông thường, các hardware device có một “interrupt-pending” bit, khi bit này bị clear thì device sẽ không tạo thêm interrupt khác, do đó bước đầu tiên cần thực hiện với interrupt handler là phải xóa bit này. (Không phải tất cả các device đều thế, cái này là hardware depend).
Một task phổ biến đối với một interrupt handler là đánh thức các process đang ngủ trên device nếu interrupt thông báo tín hiệu về một sự kiện mà chúng đang chờ đợi. Ví dụ việc có data mới đến trong các network driver.
Một interrupt handler sẽ có cấu trúc như sau:

static irqreturn_t my_irq_handler(int irq, void *dev_id)

Trong đó, có 2 tham số:
int irq là giá trị của interrupt line number đang phục vụ. Giá trị chỉ có tác dụng trong việc in log.
void *dev_id là một con trỏ giống với *dev_id trong hàm request_irq. Nó cũng có thể là một con trỏ trỏ đến một giá trị hoạt động như một cookie để phân biệt giữa các device khác nhau có khả năng sử dụng chung một interrupt handler.

3. Enabling và Disabling interrupts.

Mặc dù interrupt giúp cho device giao tiếp với processor, tuy nhiên đôi lúc các device driver phỉa block việc nhận các interrupt trong một khoảng thời gian ngắn (Thường liên quan đến sleep, wait các thứ). Thông thường, các interrupt phải bị block khi device driver đang giữ một spinlock( để tránh deadlock). Có các cách để disable interrupts mà không gọi đến spinlocks. Tuy nhiên, lưu ý là việc disable interrupt là không nên, chỉ sử dụng khi thực sự không còn cách khác.

Disable một interrupt line:

void disable_irq(int irq);
void disable_irq_nosync(int irq);
void enable_irq(int irq);

Disable một Toàn bộ các interrupt (Cái này không tốt gì cả, không nên biết).

4. Top và Bottom Halves

Một trong những vấn đề chính đối với interrupt handling đó là làm cách nào để thực hiện tác task dài trong một handler. Thông thường, một lượng lớn công việc phải làm đối với device interrupt signal, tuy nhiên, interrupt handler cần hoàn thành nhanh nhất có thể, để đảm bảo là nó không block các interrupt khác quá lâu.
Để giải quyết vấn đề này, Linux (cũng như nhiều hệ điều hành khác), chia interrupt handler thành 2 halves (hai nửa, halves là số nhiều của half), gọi là top half và bottom half. Trong đó top half sẽ thực hiện việc phản ứng với interrupt, đây là hàm handler mà chúng ta đăng ký trong request_irq(). Trong khi bottom half được lên lịch bởi top half để thực hiện sau đó, tại thời điểm an toàn hơn. Bottom half được thực hiện trong bối cảnh mà tất cả các interrupt đều được enable( không bị block). Thông thường, top half sẽ lưu device data vào một device-specific bufer, lên lịch cho bottom half, và kết thúc công việc: rất nhanh gọi. Bottom half sau đó sẽ thực hiện những công việc yêu cầu, chẳng hạn như đánh thức các process khác, sử dụng I/O… Ngoài ra, bằng cách này, top half có thể phục vụ một interrupt mới trong khi bottom half vẫn đang thực hiện.
Bottom half được thực hiện bằng Tasklet hoặc workqueues. Tasklets = all atomic >< Workqueues = có thể sleep. (Pending)

4.1 Tasklet

Tasklet luôn luôn chạy trên một CPU duy nhất, đó là CPU đã lập lịch nó, và nhận một tham số kiểu long không dấu. Tuy nhiên, lập lịch ở đây không có nghĩa là chỉ định thời điểm chạy cho tasklet, thay vào đó, đơn giản chỉ là chúng ta thông báo cho kernel rằng hãy chạy function này sau đó, bất cứ lúc nào. Ứng dụng điều này, chúng ta có thể nhận interrupt, phản hồi cho device, lập lịch tasklet rồi exit, tasklet sẽ tự chạy sau đó (nhỏ 1 hơn 1 time tick).

Bây giờ, thử thực hiện một tasklet cực kỳ đơn giản.
Tạo file simple_tasklet.c

Include các header cần thiết vào

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/interrupt.h>

MODULE_LICENSE("GPL");

Tiếp theo khai báo một tring làm data, chúng ta sẽ in ra nó trong tasklet.

char tasklet_data[]="Something here";

Tiếp theo là khai báo hàm callback cho tasklet, hàm này thực hiện các chức năng chính của tasklet.

void tasklet_function(unsigned long data)
{
	printk("%s\n",(char*)data);
	return;
}

Hàm này nhận một time số kiểu unsigned long, về cơ bản chúng ta sẽ truyền mảng ký tự đã khai báo vào làm tham số, sau đấy chúng ta convert nó ngược lại và in ra.

Khởi tạo tasklet struct bằng macro - cách này chỉ dùng khi muốn khởi tạo tasklet struct ở compile time

DECLARE_TASKLET(my_tasklet, tasklet_function, (unsigned long)&tasklet_data);

Các tham số lần lượt là: tên của struct muốn khởi tạo, hàm call back của tasklet struct và tham số đầu vào của hàm tasklet callback. Trong hàm init, chúng ta lập lịch cho tasklet như sau:

tasklet_schedule( &my_tasklet );

Bây giờ khi load module vào thì dmesg sẽ in ra dòng: “Something here”, và chúng ta gần như không nhận thấy được độ trễ về thời gian, vì nó quá nhanh quá nguy hiểm.

4.2 Workqueues

Workqueue, cũng tương tự như tasklet, cho phép kernel code yêu cầu một function thực hiện tại một thời điểm trong tương lai. Tuy nhiên có nhiều điểm khác biệt lớn giữa tasklet và workqueue:

Tasklet chạy trong software interrupt context, nên tasklet code phải là atomic. Trong khi, workqueue function chạy trong context của một kernel process đặc biệt, kết quả là nó linh hoạt hơn, thực tế, nó có thể ngủ được.
Cả Workqueue và Tasklet luôn luôn chạy trong processor đã submit lệnh yêu cầu chạy nó.
Kernel code có thể yêu cầu workqueue function được gọi sau một khoảng delay rõ ràng, chứ không phải kiểu sống chết mặc bay của tasklet. Do những khác biết trên, tasklet thực thi nhanh hơn và an toàn hơn nên được ưa dùng trong các interrupt handler. Như hầu hết các kỹ thuật Sleep khác, Workqueue cũng sử dụng một strucutre để khai báo, cầu trúc này định nghĩa trong header linux/workqueue.h. Để sử dụng workqueue, cần tạo nó trước khi sử dụng bằng một trong hai hàm sau

struct workqueue_struct *create_workqueue(const char *name);
struct workqueue_struct *create_singlethread_workqueue(const char *name);

Sau đấy chúng ta tạo work_struct, đây là các struct chứa các callback function sẽ thực hiện bởi workqueue, một workqueue có thể có nhiều work_struct được add vào.

Tạo work_struct ở run time bằng một trong hai cách sau:

INIT_WORK(struct work_struct *work, void(*function)(void *), void *data);
PREPARE_WORK(struct work_struct *work, void(*function)(void *), void *data);

Công việc của INIT_WORK chỉ đơn giản là khởi tạo một struct với hàm call back là func, và dữ liệu truyền vào là data.

Sau khi đã có work_struct, cần phải submit nó vào workqueue với một trong hai hàm sau:

int queue_work(struct workqueue_struct *queue, struct work_struct* work);
int queue_delayed_work(struct workqueue_struct *queue, struct work_struct *work, unsigned long delay);

Nhìn tên hai hàm chúng ta cũng thấy được 1 cái là có thêm khoảng delay vào, một cái thì không. Lưu ý là một work_struct chỉ được add vào workqueue một lần

Các hàm tiện ích khác đối với workqueue

int cancel_delayed_work(struct work_struct *work);
void flush_workqueue(struct workqueue_struct *queue);
void destroy_workqueue(struct workqueue_struct *queue);

4.3 Đưa Interrupt Handler vào các kernel thread riêng.

Như có thể thấy ở phần 4.1 và 4.2, tasklet và workqueue sẽ có một độ trễ (dù rất nhỏ) so với thời điểm xảy ra interrupt. Trong các tác vụ thông thường, việc này coi như tạm chấp nhận được, nhưng đối với các thiết bị, ứng dụng Real-time thì độ trễ này vẫn là một vấn đề. Vì thế các phiên bản linux kernel mới đã cập nhật thêm một giải pháp mới cho việc xử lý interrupt, gọi là threaded interrupt.

Các thread interrupt chạy độc lập trên các kernel thread của nó.

Việc yêu cầu một threađe interrupt handler được thực hiện bằng một cách dễ dàng bằng cách sử dụng lời giọi hàm sau:

int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t threaded_fn, unsigned long irqflags, const char *devname, void *dev_id);

Lưu ý rằng (hard) IRQ handler (handler) có thể là NULL, trong trường hợp này default handler sẽ được thực thi, tức là nó sẽ trả về IRQ_WAKE_THREAD để đánh thức kernel thread liên kết với nó và kernel thread này sẽ chạy thread_fn (bottom half). Trong trường hợp này thì irqflags phải bao gồm IRQF_ONESHOT, ngược lại sau khi thực hiện top half, thì interrupt sẽ được enable trở lại và sẽ gây ra stack overflow.

Các flag khả dụng có thể xem được trong file: /include/linux/interrupt.h

Nhiều device có thể dùng chung một interrupt line.

5.1 Cài đặt một Shared Handler.

Shared interrupt vẫn được cài đặt bằng hàm request_irq() giống như các interrupt thông thường, nhưng có 2 điểm khác biệt:
SA_SHIRQ phải được set trong cờ khi yêu cầu interrupt. dev_id phải là độc lập.(main key) Truường hợp này, dev_id được dùng như một identifier để phân biệt các handler được lưu giữ trong kernel.

5.2 Interrupt handler

Khi nhận interrupt phải kiểm tra xem interrupt đấy có phải là của nó không, nếu không phải thì phải exit ngay.

6. Interrupt-Driven I/O.

Cái này nói về việc buffer dữ liệu. Sau viết.

7. Ví dụ thực tế: Interrupt handler cho keyboard driver, PC intel.

Bây giờ mình thử viết một kernel module để nghịc cái interrupt của bàn phím, lưu ý là cái module này chỉ dùng trên máy Intel thôi, và nếu muốn test thì chỉ nên test trên máy ảo. Trên Intel arch thì bàn phím sử dụng interupt line number 1. Và bởi vì hầu hết các bản Linux đều có device driver cho bàn phím tích hợp sẵn (built-in), và tất nhiên driver này đã đăng ký interrupt handler với kernel, một non-shared handler, nên trong module keyboard tự tạo của mình, thì công việc đầu tiên làcần phải giải phóng interrupt line. Mặc dù chỉ làm một số thao tác đơn giản, nhưng interrupt handler ví dụ này cũng sẽ được chia làm hai phần là bottom half và top half. Phần bottom half sẽ dùng workqueue để xử lý. Do đó cần khai báo một workqueue.

#define WORK_QUEUE_NAME "OniWQ" // Tên của workqueue.
static struct workqueue_struct *my_workqueue;

Như đã nói ở trên, một workqueue sẽ gồm có nhiều work_struct, mỗi work_struct có một call back function, bây giờ, cần định nghĩa một callback function cho work_struct sẽ sử dụng.

static void read_char(void *scancode)
{
	printk(KERN_INFO "Scan code %x %s.\n",(int)*((char*)scancode) & 0x7F, *((char*)scancode)&0x80? "Release:Pressed");
}

Nhìn đoạn printk có vẻ lộn xộn và khó hiểu, nhưng thự tế là nó sẽ in ra xem phím nào gây ra interrupt, và phím được ấn hay được nhả ra. Hàm này chính là bottom half. Bây giờ chúng ta định nghĩa một hàm top half, theo mặt lý thuyết thì đây mới thực sự là interrupt handler. Định nghĩa một hàm với protype và một số local variable như sau như sau:

irqreturn_t irq_handler(int irq, void *dev_id)
{
	static int isInit = 0;
	static unsigned char scancode;
	static struct work_struct task;
	unsigned char status;
}

Tiếp theo chúng ta đọc keyboard status bằng các cmd sau:

status = inb(0x64);
scancode = inb(0x60);

Sau khi biết được status rồi, nếu bottom half chưa chạy, thì chúng ta sẽ schedule cho nó

if(isInit == 0){
	INIT_WORK(&task, read_char, &scancode);
	isInit = 1;
}else{
	PREPARE_WORK(&task, read_char, &scancode);
}

queue_work(my_workqueue, &task);

return IRQ_HANDLED;

Việc request interrupt được thực hiện trong hàm init của module, và như đã nói ở trên, thì trước khi cài đặt custome driver, mình sẽ giải phóng interrupt line khỏi driver hiện tại của Linux.

free_irq(1, (void*)irq_handler);
return request_irq(1, irq_handler, SA_SHIRQ, "test_key_board",(void *)(irq_handler));

Ở đây có sử dụng function inb(port). Vậy function này là một hàm dùng để access port của IOP. chữ b ở đây có nghĩa là byte-width tức là nó sẽ đọc 1byte từ port được truyền vào ở tham số. Trong ví dụ của mình, hàm này sẽ đọc 1byte từ port 0x64 như status code và port 0x60 như scancode.

Interrupts was originally published by Nguyễn Đình Phi at Oni Ranger on March 21, 2018.

Memory Allocation

2018-02-07T00:00:00+08:00

1 Bộ nhớ vật lý và bộ nhớ ảo.

Tương tự như các hệ điều hành khác trong thời đại chó lên cung trăng ngày nay, Linux cũng sử dụng một hệ thống gọi là : Hệ thống bộ nhớ ảo - Virtual Memory (VM), tất nhiên là kích thước của VM có thể lớn hơn kích thước của bộ nhớ thật. Trong Linux (mà OS khác cũng thế), mỗi process có một không gian địa chỉ riêng. Các địa chỉ này đều là các địa chỉ ảo, và khi process muốn truy cập đến Memory thì kernel sẽ giúp nó ánh xạ các địa chỉ này sang các địa chỉ vật lý tương ứng, việc này được thực hiện hoàn toàn bởi kernel, process trong Userspace không có ý thức về hành động này. Kể cả trong kernel thì địa chỉ cũng là các địa chỉ ảo, tuy nhiên việc ánh xạ địa chỉ ảo trong kernel sang địa chỉ vật lý đơn giản hơn nhiều so với các process trong User space. Trong kernel phép ánh xạ từ địa chỉ ảo sang địa chỉ vật lý (và ngược lại) đơn giản chỉ là một phép cộng (hoặc trừ) một đơn vị offset nào đó, giá trị của offset phụ thuộc vào platform đang sử dụng.

2 Kmalloc.

Mình đã từng dùng kmalloc trong bài ioctl, tuy nhiên bây giờ mới đến đoạn tìm hiểu về nó (hí hí). Prototype của hàm này như sau:

#include <linux/slab.h>
void *kmalloc(size_t size, int flags);

Hàm kmalloc nhận 2 tham số, tham số đầu tiên là kích thước của vùng nhớ sẽ được cấp phát. Tham số thứ hai, được gọi là allocation flags, là một cờ dùng để điều khiển hoạt động của kmalloc.
Flag phổ biến nhất là GFP_KERNEL, khi dùng flag này, việc cấp phát được thực hiện bằng cách gọi đến hàm __get_free_pages, GFP là tên viết tắt của hàm này. Cờ này dùng trong các process context. Sử dụng GFP_KERNEL có nghĩa là kmalloc có thể đưa process hiện tại vào hàng đợi để chờ đến khi có một page khả dụng (nếu bộ nhớ không còn đủ). Do có thể gây ra sleep nên hàm gọi đến kmalloc sử dụng cờ GFP_KERNEL không được phép chạy trong các atomic context (interrupts,…). Trong lúc process đi ngủ thì kernel sẽ thực hiện các hành động hợp lý để tìm được một vùng nhớ khả dụng, hoặc bằng cách đẩy hết buffer vào đĩa cứng, hoặc swapping mem từ một user-process.

Đôi khi kmalloc cũng có thể được gọi từ bên ngoài process context, điều này có thể xảy ra trong các interrupt handlers, tasklets hay kernel timers. Trong trường hợp này, process hiện thời sẽ đi ngủ và driver code không thể sử dụng GFP_KERNEL được, thay vào đó, GFP_ATOMIC sẽ được dùng. Thông thường kernel sẽ cố gắng giữ một vài free pages nhằm mục đích xử lý các atomic allocation. Khi GFP_ATOMIC được sử dụng, kmalloc có thể sử dụng đến những page này, trong trường hợp không còn page nào khả dụng, thì việc cấp phát bộ nhớ sẽ thất bại.

GFP_KERNEL và GFP_ATOMIC được gọi là các combinations of flags, hoặc các allocation priorities. Chúng được khai báo trong header linux/gfp bên cạnh các flag thông thường, các flag này thường có prefix là __. Kernel còn có một số allocation priorities cụ thể như sau:
GFP_ATOMIC : ĐƯợc sử dụng để cấp phát mem từ interrupt handler và các code nằm ngoài process context. Không bao giờ sleep, có thể thành công hoặc không.
GFP_KERNEL : Cấp phát bộ nhớ thông thường, có thể ngủ.
GFP_USER : Cấp phát bộ nhớ từ user-space pages; có thể ngủ.
GFP_HIGHUSER : Cấp phát bộ nhớ từ user-spaces pages, sử dụng high memory. GFP_NOIO, GFP_NOFS: Hoạt động giống như GFP_KERNEL nhưng chúng thêm các ràng buộc mà kernel cần làm để thỏa mãn yêu cầu. GFP_NOFS không cho phép thực hiện bất kỳ filesystem call nào, trong khi GFP_NOIO không cho phép khởi tạo bất kỳ I/O nào. Mục đích chính của các cờ này là để sử dụng trong các file system và virtual mem code, nơi mà việc allocation được cho phép ngủ, nhưng việc thực hiện các lời gọi filesystem không phải là ý kiến hay.

Các flag nêu trên có thể được kết hợp với một số flag sau đây bằng phép bitwise OR:
__GFP_DMA Yêu cầu việc cấp phát phải diễn ra trong DMA-capable mem zone.
__GFP_HIGHMEM Chỉ ra rằng bộ nhớ cấp phát có thể được đặt ở high mem.
__GFP_COLD Thông thường, memory allocator cố gắng trả về các page được tìm thấy trong processor cache - cache warm page. Cờ này sẽ yêu cầu các cold page. Cờ này hữu ích trong trường hợp cấp phát page để đọc DMA.
__GFP_NOWARN Đây là cờ hiếm khi được sử dụng. no warning.</br> __GFP_HIGH Đánh dấu request có độ ưu tiên cao, khẩn cấp. __GFP_REPEAT Trong trường hợp cấp phát không thành công, nó sẽ thử lại (nhưng có thể việc cấp phát vẫn lỗi).
__GFP_NOFAIL Việc cấp phát không bao giờ được thất bại, nó sẽ thử lại đến khi nào thành công thì thôi.
__GFP_NORETRY Bỏ cuộc ngay khi vùng nhớ yêu cầu không khả dĩ.

Trong phần giải thích các flag ở trên, có đề cập đến Memory zone, vậy mem zone là gì?
Trong linux kernel có ít nhất 3 mem zone: DMA, normal và high memory. Thông thường việc cấp phát diễn ra ở normal zone, tuy nhiên có thể được setup bằng cách sử dụng một số cờ nhất định. DMA mem là bộ nhớ cho phép thực hiện DMA access. High mem là kỹ thuật sử dụng để cho phép truy cập đến một lượng memory tương đối lớn trên 32-bit platforms.

3 Size argument

Kernel quản lý system’s physical mem, nó chỉ khả dụng trong các page-sized chunk. Kernel sử dụng page-oriented allocation technique để cấp phát bộ nhớ (thay vì head-oriented như malloc).
Linux xử lý các yêu cầu cấp phát bộ nhơ bằng cách tạo ra một tập các pool của các mem objects có kích thước cố định. Các yêu cầu cấp phát được xử lý bằng cách tìm đến một pool đang giữ số lượng object đủ lớn và trao toàn bộ một mem chunk cho người đã request.
Kernel chỉ có thể cấp phát một mảng cố định về kích thước (đã được định nghĩa từ trước) các bytes. Nếu bạn yêu cầu một lượng bộ nhớ bất kỳ, thông thường bạn sẽ nhận được nhiều hơn một ít những gì bạn yêu cầu (fragmentation), có thể lên đến gấp đôi.
memory chunk được cấp phát bởi kmalloc có giới hạn tùy thuộc vào config và arch, lớn nhất là 128KB thì phải. Trong trường hợp cần nhiều bộ nhớ hơn, thì kmalloc không phải là lựa chọn tốt nhất.

4 Lookaside caches.

Lookaside cache là một pool đặc biệt, được sử dụng cho các high-volume object (các object sử dụng nhiều bộ nhớ).
Cache manager trong kernel được gọi là slab allocator, khai báo trong linux/slab.h header. Slab allocator implement các cache có kiểu dữ liệu kmem_cache_t; chúng được tạo ra bằng cách gọi hàm kmem_cache_create. Prototye như sau:

kmem_cache_t *kmem_cache_create(const char *name, size_t size,
								size_t offset,
								unsigned long flags,
								void (*constructor)(void *, kmem_cache_t *, unsigned long flags),
								void (*constructor)(void *, kmem_cache_t *, unsigned long flags));

-Hàm này tạo ra một cache object, cache object này có thể host một số lượng bất kỳ các vùng nhớ có cùng kích thước, được chỉ ra trong tham số size.
-Tham số name hoạt động như một housekeeping cho cache và các function (cons, des). Nó rất hữu ích trong việc theo dõi các vấn đề xảy ra nhờ việc nắm giữ được đầy đủ các thông tin cần thiết. Thông thường, nó là tên của struct được cache. Cache giữ một contror tới name thay vì copy nó, do đó driver nên truyền một pointer vào name trong static storage.
-Tham số offset là offset của object đầu tiên trong page; thông thường sẽ là 0.
-Tham số flags : việc cấp phát sẽ được thực hiện như thế nào và nó là bitmask của các flags sau:
SLAB_NO_REAP Bảo vệ cache khỏi việc bị giảm dung lượng khi system tìm kiếm bộ nhớ cho những requester mới. Việc sử dụng cờ này là ý tồi, vì nó gây ra tình trạng process có mem thì không dùng đến, trong khi các process không có mem thì tìm không ra.
SLAB_HWCACHE_ALIGN
SLAB_CACHE_DMA

Constructor và destructor là optional.
Constructor và destructor có thể hữ ích trong một số trường hợp, nhưng có một số điểm cần lưu ý. Một constructor được gọi khi mem của một tập các objects được allocated; bởi vì mem đó có thể giữ nhiều object nên constructor có thể được gọi nhiều lần, nên ta không thể giả thuyết là constructor sẽ được gọi ngay lập tức sau khi cấp phát bộ nhớ cho một object. Tương tự, destructor có thể được gọi ở bất kỳ thời điểm nào trong tương lai, không nhất thiết phải là ngay lập tức sau khi một object được giải phóng.
Một khi cache of objects đã được tạo, chúng ta có thể cấp phát các mem object từ cache này bằng cách gọi kmem_cache_alloc:

void *kmem_cache_alloc(kmem_cache_t *cache, int flags);

Để free một mem object:

void kmem_cache_free(kmem_cache_t *cache, const void *obj);

Khi driver code làm xong việc với cache, nó phải free cache:

int kmem_cache_destroy(kmem_cache_t *cache);

5 Memory Pools

Đôi lúc, việc cấp phát bộ nhớ bắt buộc phải không được thất bại. Để handle được các trường hợp này, linus cung cấp một abstraction tên là mempool. Một mempool thực tế chỉ là một dạng của lookaside cache, nó luôn luôn có gắng gữ lại một list các vùng nhớ free để dùng cho trường hợp khẩn cấp.
Để tạo một mempool, cần thực hiện như sau:

#include <linux/mempool.h>

mempool_t *mempool_create(int min_nr, mempool_alloc_t *alloc_fn, mempool_free_t *free_fn, void *pool_data);

ở đây min_nr là lượng allocated object ít nhất mà pool cần phải đảm bảo. alloc_fn là hàm thực hiện việc cấp phát thực sự, có prototype như sau:

typedef void *(mempool_alloc_t)(int gfp_mask, void *pool_data);

free_fn là hàm thực hiện việc giải phóng thực sự, có prototype như sau:

typedef void *(mempool_free_t)(void *element, void *pool_data);

Thông thường, chúng ta sẽ không viết hàm free_fn và alloc_fn làm gì cả, mà sẽ sử dụng các hàm có sẵn của slab allocator:

cache = kmem_cache_create(. . .);
pool = mempool_create(MY_POOL_MINIMUM, mempool_alloc_slab, mempool_free_slab, cache);

Sau khi pool đã được tạo, các object có thể được allocate và free bằng cách sử dụng hai hàm sau:

void *mempool_alloc(mempool_t *pool, int gfp_mask);
void mempool_free(void *element, mempool_t *pool);

Mempool có thể được resize bằng hàm

int mempool_resize(mempool_t *pool, int new_min_nr, int gfp_mask);

Khi không còn sử dụng nữa, hãy giải phóng pool cho hệ thống:

void mempool_destroy(mempool_t *pool);

Lưu ý là cần phải return tất các các allocated object (mempool_free) trước khi giải phóng pool, hoặc sẽ gặp kernel oops.

6 get_free_page and Friends.

Nếu một module muốn sử dụng rất nhiều mem, thì tốt nhất là nên sử dụng kỹ thuật page-oriented. Để allocate page, sử dụng một trong các hàm sau:

get_zeroed_page(unsigned int flags);
/*Trả về con trỏ đến page mới với các mem slot đều là 0*/
__get_free_page(unsigned int flags);
/*Trả về con trỏ đến page mới nhưng không clear các mem slot */
__get_free_pages(unsigned int flags, unsigned int order);
/*Trả về con trỏ đến byte đầu tiên của một loạt page mới nhưng không clear các mem slot. Các page này là liên tục trên bộ nhớ vật lý */

Cả 3 hàm trên, tham số flags đều giống kmalloc, còn order ở cuối là số page sẽ get, theo quy tắc số page = 2^order. thường thì ta dùng order bằng 0 hoặc 3, tức là 1 page hoặc 8 page liên tục, việc dùng số order quá cao sẽ khiến việc lấy page thất bại.
Sau khi đã sử dụng xong, cần phải free page, bằng cách dùng một trong 2 hàm sau:

void free_page(unsigned long addr);
void free_pages(unsigned long addr, unsigned long order);

6. Per-CPU variables.

Memory Allocation was originally published by Nguyễn Đình Phi at Oni Ranger on February 07, 2018.

Linux Time

2018-02-06T00:00:00+08:00

1. Linux Time .

Trong Linux kernel, thời gian được đo bằng một biến golbal tên là jiffies . Jiffies là biến kiểu usigned long và có giá trị bằng số lần xảy ra ngát của iterrrupt timer kể từ khi hệ thống được khởi động. Tần số của ngắt này được khai báo trong biến HZ và biến này có thể được cấu hình ở thời điểm biên dịch (CONFIG_HZ), tuy nhiên nếu như không có nhu cầu gì đặc biệt thì tốt nhất nên để nó ở giá trị mặc định (250HZ trên x86_64).

2. Linux Standard timer.

Có nhiều mục đích cần đến jiffies, tuy nhiên phổ biến nhất có lẽ là dùng để tính timeout cho timer. Trong Linux có 2 bộ timer là: Standard timer, hay còn gọi là timer wheel và một bộ timer có độ chính xác cao (đến nanosecond) gọi là high resolution timers (hrtimer). Mặc dụ timer wheel ít chính xác hơn so với hrtimer tuy nhiên nó là giải pháp hiệu quả trong trường hợp timer có thể bị hủy bỏ trước khi nó kịp timeout (thường dùng để kiểm tra timeout của peer trong networking).

struct timer_list {
	/*
	 * All fields that change during normal runtime grouped to the
	 * same cacheline
	 */
	struct hlist_node	entry;
	unsigned long		expires;
	void			(*function)(struct timer_list *);
	u32			flags;

#ifdef CONFIG_LOCKDEP
	struct lockdep_map	lockdep_map;
#endif
};

Standard Timer cung cấp các hàm để tạo, hủy bỏ và quản lý timer: Trong Linux kernel, mỗi Timer là một biến với kiểu struct timer_list, cấu trúc này có chứa một callback function được gọi khi timer hết hạn, cấu trúc này và các hàm liên quan được khai báo trong linux/timer.h. Dĩ nhiên là để sử dụng Timer chúng ta cần khởi tạo nó, bằng cách sử dụng init_timer hoặc setup_timer. (ngoài ra còn có 1 cái macro tên DEFINE_TIMER nữa).

void init_timer( struct timer_list *timer );
void setup_timer( struct timer_list *timer, 
                     void (*function)(unsigned long), unsigned long data );

Hàm setup_timer sẽ khởi tạo timer_list và gán hàm truyền vào (tham số thứ 2) cho callback function của timer_líst vừa được khởi tạo. Trong khi hàm init_timer thì chúng ta phải tự gán các giá trị cần thiết của timer sau đó gọi init_timer để đăng ký với kernel. (THật ra thì macro setup_timer sẽ gọi đến macro init_timer). Note Trong các version kernel mới(từ 4.15) thì setup_timer được đổi thành timer_setup

Sau khi đã khởi tạo timer, ta có thể đặt thời gian timeout cho nó thông qua hàm mod_timer hay xóa timer với del_timer.

3. Timer example.

Sau đây mình sẽ thử viết một module đơn giản để demo khả năng của timer api. Trong module này mình sẽ khai báo một timer trong hàm init_module và đặt timeout cho nó là 200ms. Và gán hàm oni_callback làm callback function cho nó. Hàm này sẽ được gọi sau 200ms. Trong code có giải thích cụ thể bằng comment.

//Kernel 4.15.0
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/timer.h>

MODULE_LICENSE("GPL");

static struct timer_list my_timer;					//Khai báo timer list.

/*Đây là hàm callback. Như đã nói ở trên
kể tử kernel 4.15 timer api đã có sự thay đổi. Và hàm callback nhận tham
số kiểu <i>struct timer_list *</i> thay vì <i>unsigned long</i>
*/
void oni_callback(struct timer_list* timer) {
	//jiffies ở đây chính là thời điểm timer timeout + delta nhỏ.
  printk("Oni callback function (%ld).\n", jiffies); 
}

int init_module(void) {
  int ret;
  printk("Oni Timer module installing\n");
  
  timer_setup(&my_timer, oni_callback, 0);						//Khởi tạo timer_list và gán callback function.

  //Ở đây mình sẽ in ra thời điểm timer bắt đầu chạy để đối chiếu.
  printk("Starting timer, current time (%ld)\n", jiffies);	
  ret = mod_timer(&my_timer, jiffies + msecs_to_jiffies(200));	//Đặt timeout cho timer (200ms).
  
  if (ret) {
    printk("Error in mod_timer\n");

    return 0;
  }
}

void cleanup_module(void) {
  int ret;
  //Xóa bỏ timer khi không sử dụng nữa
  ret = del_timer(&my_timer);
  if (ret) {
    printk("Oni timer could not be removed...\n");
  }
  printk("Bye bye timer\n");
  return;
}

Khi insert module này vào hệ thống, dmesg sẽ hiển thị log sau:

[12390.892122] Oni Timer module installing
[12390.892124] Starting timer, current time (4297990083)
[12391.092317] Oni callback function (4297990134)

Mình đang chạy thử nó trên x86_64, và như nói ở trên thì HZ của platform này là 250, tức là 1 jiffies sẽ tương đương với 4ms. Theo log trên ta có fired_time - started_time = 4297990134 - 4297990083 = 51 jiffies * 4ms = 204 ms. (4ms là delta nhỏ ở trên). Tức là timer của mình chạy đủ 200ms.

4. High-resolution timer API

Như đã nói ở phần đầu thì kernel còn một loại timer nữa là hrtimer - high resolution timer, tạm dịch là timer độ chính xác cao: hrtimer cho độ chính xác tới nano secs. Khác với standard timer được xây dụng dựa trên giá trị jiffer, thì hrtimer lại sử dụng giá trị ktime làm đơn vị đo, kernel cung cấp hàm ktime_set để chuyển đổi từ thời gian thông thường thành ktime. Hrtimer cũng được biểu diễn bằng một struct tên là hrtimer. Hrtimer sẽ dùng một cấu trúc cây (red-black tree) - struct rbtree_node của kernel để quản lý các timer, các timer được thêm vào cây theo thứ tự thời gian trước-sau để giảm thiệu chi phí xử lý. Để sử dụng được HRT thì kernl cần phải enable CONFIG_HIGH_RES_TIMERS. Để biết HRT có được enable trên thiết bị mà đang sử dụng hay không, ta có thể dùng cmd sau:

cat /proc/timer_list |grep resolution

Nếu kết quả trả về có ít nhất 1 entry ghi “.resolution: 1 nsecs” thì có nghĩa là HRT đã được enable. Vậy câu hỏi là: khi nào thì dùng HRT? tất nhiên là khi cần độ chính xác cao - như cái tên rồi :gach:. Thật ra nó thường được dùng trong multimedia là chính thì phải, có lần đọc được thế ở đâu quên rồi, ahihi.

//Kernel 4.19
//file: linux/hrtimer.h 
/**
 * struct hrtimer - the basic hrtimer structure
 * @node:	timerqueue node, which also manages node.expires,
 *		the absolute expiry time in the hrtimers internal
 *		representation. The time is related to the clock on
 *		which the timer is based. Is setup by adding
 *		slack to the _softexpires value. For non range timers
 *		identical to _softexpires.
 * @_softexpires: the absolute earliest expiry time of the hrtimer.
 *		The time which was given as expiry time when the timer
 *		was armed.
 * @function:	timer expiry callback function
 * @base:	pointer to the timer base (per cpu and per clock)
 * @state:	state information (See bit values above)
 * @is_rel:	Set if the timer was armed relative
 *
 * The hrtimer structure must be initialized by hrtimer_init()
 */
struct hrtimer {
	struct timerqueue_node		node;
	ktime_t				_softexpires;
	enum hrtimer_restart		(*function)(struct hrtimer *);
	struct hrtimer_clock_base	*base;
	u8				state;
	u8				is_rel;
};

Một HRT được khởi tạo thông qua hàm hrtimer_init, hàm này nhận 3 tham số: timer struct, clock được sử dụng và timer mode. Clock được định nghĩa trong file timer.h, đại diện cho các loại clock mà hệ thống hỗ trợ (ví dụ như CLOCK_MONOTONIC hay CLOCK_REALTIME), còn timer mode có hai dạng là thời gian tương đối (HRTIMER_MODE_RLL) và thời gian tuyệt đối (HRTIMER_MODE_ABS).

void hrtimer_init( struct hrtimer *time, clockid_t which_clock, 
            enum hrtimer_mode mode );
int hrtimer_start(struct hrtimer *timer, ktime_t time, const 
            enum hrtimer_mode mode);

Một khi đã khởi tạo timer, thì ta có thể bắt đầu nó bằng cách gọi hàm hrtimer_start, trong hàm này sẽ có thời gian timeout được truyền vào. Và tương tự như standard timer thì HRT cũng cung cấp khả năng hủy bọ timer bằng các hàm hrtimer_cancel hoặc hrtimer_try_to_cancal. Điểm khách nhau giữa hai hàm cancel này là nếu như chúng được gọi khi timer đã gọi hàm callback, thì hàm đầu tiên sẽ đợi hàm callback hoàn thành rồi, còn hàm thứ hai sẽ kệ nó và báo lỗi là không cancel được. Ngoài ra ta cũng có thể kiểm tra xem timer đã gọi hàm callback của nó chưa bằng cách sử dụng hrtimer_callback_running function. Hai hàm khác cũng có thể được dùng để kiểm tra trạng thái timer là : hrtimer_get_remaining và hrtimer_cb_get_time, một hàm dùng để kiểm tra thời gian còn lại của timer, một hàm dùng để kiểm tra thời gian đã chạy của timer.

Kernel cũng cung cấp hai hàm hrtimer_forward và hrtimer_forward_now để thay đổi thời gian timeout của timer sau khi nó đã start.

u64 hrtimer_forward (struct hrtimer * timer, ktime_t now, ktime_t interval);
u64 hrtimer_forward_now(struct hrtimer *timer, ktime_t interval);

5. HRT example.

Một ví dụ tương tự phần trước, nhưng thay vì sử dụng timer_list, mình sẽ dùng hrtimer.

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/hrtimer.h>
#include <linux/ktime.h>

MODULE_LICENSE("GPL");

static struct hrtimer oni_hrt;

//Chọn timer không restart.
enum hrtimer_restart oni_hrt_callback(struct hrtimer *timer){
  printk("oni_hrt_cb called (%ld). \n", jiffies);
  return HRTIMER_NORESTART;
}

int init_module(void) {
  printk("ONI: Module installing\n");
  ktime_t ktime = ktime_set(0, 200 * 1000000); //0s + 200ms
  //Sử dụng thời gian tương đối.
  hrtimer_init(&oni_hrt, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
  oni_hrt.function = &oni_hrt_callback;
  printk("ONI: Timer started at (%ld) jiffies\n", jiffies);
  hrtimer_start(&oni_hrt, ktime, HRTIMER_MODE_REL); //Bắt đầu chạy timer.
  return 0;
}

void cleanup_module(void) {
  int ret;
  ret = hrtimer_cancel(&oni_hrt);
  if (ret) {
    printk("Cannot cancel hrtimer\n");
  }

  printk("HRtimer: bye bye\n");
  return;
}

Khi thêm module trên vào hệ thống, ta thu được log sau. Có thể thấy là nó chính xác đúng 200ms luôn 0o0.

[17185.811269] ONI: Module installing
[17185.811270] ONI: Timer started at (4299188837) jiffies
[17186.011273] oni_hrt_cb called (4299188887).

Linux Time was originally published by Nguyễn Đình Phi at Oni Ranger on February 06, 2018.

Poll and select

2018-01-29T00:00:00+08:00

I. Poll and Select

Các ứng dụng(user-app) sử dụng nonblocking I/O sẽ thường sử dụng thêm poll, select và epull system call. poll, select, epoll có cùng 1 chức năng: cho phép một process xác định xem nó có thể đọc hoặc ghi từ một hoặc nhiều open file mà không bị block hay không. Những lời gọi hàm này cũng có thể block một process đến khi có một tập file descriptors(fd) trở nên khả dụng cho việc đọc hoặc ghi. Bởi thế, chúng thường được sử dụng trong các user-app cần phải sử dụng nhiều luồng đọc/ghi cùng lúc mà không có bất kỳ luồng nào bị stuck(V/d: network).

Những system call kể trên được hỗ trợ bởi một driver method duy nhất là poll:
unsigned int (*poll) (struct file *filp, poll_table *wait);

Driver method được gọi mỗi khi một user-app thực hiện lời gọi đến một trong các system call poll, select, epoll trên một file descriptor được liên kết với driver. Nhiệm vụ của driver method có 2 bước:

Gọi hàm poll_wait trên một hoặc nhiều hàng đợi, hàng đợi này được yêu cầu là phải có thể chỉ ra được sự thay đổi của poll status. Nếu không có file descriptor nào khả dụng cho I/O ở thời điểm hiện tại, thì kernel sẽ đẩy process vào hàng đợi để đợi đến khi tất cả các file descriptors được truyền đến system call.
Trả về một bit mask miêu tả operation nào (nếu có) có thể được thực hiện ngay lập tức mà không bị block.

Driver có thể thêm một wait queue vào poll_table bằng cách sử dụng lời gọi hàm:
void poll_wait(struct file *, wait_queue_head_t *, poll_table *);

Các bitmask có thể được trả về ở bước 2 gồm có:
POLLIN Bit này được set nếu như device có thể đọc mà không bị block
POLLRDNORMBit này được set nếu như “normal” data là khả dụng cho việc đọc. Một readable device sẽ trả về (POLLIN|POLLRDNORM)
POLLRDBANDout-of-band data is available for reading from the device
POLLPRI High-priority data(out-of-band) có thể được đọc mà không bị blocking. Nếu bit này được set, lời gọi select sẽ thông báo rằng một exception condition đã diễn ra trong file, bời vì select report out-of-band data như một exception condition
POLLHUP Khi một process đọc đến EOF, driver phải set bit POLLHUP(hang-up). Một process gọi select sẽ được nói rằng device là có thể đọc, vì được yêu cầu bởi chức năng của hàm này.
POLLERR Một error condition đã xảy ra trong thiết bị. Khi poll được gọi, thiết bị được báo cáo là có thể đọc và cũng có thể ghi được, vì cả read và write đều trả về 1 error code without blocking
POLLOUTDevice cÓ thể được ghi mà không bị block
POLLWRNORMGiống với POLLOUT
POLLWRBANDNonzero-priority data có thể được ghi vào device

Out of band data là gì? Data truyền qua socket.

Peding for an example

II. Interaction with read and write.

Mục đích của việc gọi poll và select là để xác định trước xem một I/O operation sẽ bị block hay không. Poll và select rất hữu dụng, bởi vì chúng cho phép user-app chờ đợi nhiều data stream một cách đồng thời. (Sẽ tìm ví dụ sau).

Để 3 system call (poll, select, epoll) hoạt động đúng, chúng ta cần lưu ý đến một số luật sau.

1. Đọc dữ liệu từ device.

a,Nếu có dữ liệu trong input buffer, read call sẽ return ngay tức thì, với độ trễ không đáng kể, kể cả khi như lượng dữ liệu trong input buffer ít hơn lượng dữ liệu được yêu cầu bởi user-app nhưng driver đảm bảo là lượng dữ liệu còn lại sẽ được chuyển đến input buffer sớm. Trong trường hợp này, poll nên trả về POLLIN|POLLRDNORM.
b,Nếu không có data trong input buffer, mặc định, read phải block đến khi có ít nhất 1 byte data ở trong input buffer. Ngược lại, nếu như O_NONBLOCK được set, read sẽ return ngay lập tức với giá trị trả về là -EAGAIN. Trong trường hợp này, poll phải report rằng device hiện tại là unreadable cho đến khi có ít nhất 1 byte data đc truyền đến. Ngay khi data đc truyền đến buffer, chúng ta sẽ quay lại case a.
c, Nếu đang ở EOF, read sẽ return ngay lập tức với giá trị trả về là 0. poll trả về POLLUP.

2. Ghi vào device.

a,Nếu output buffer không đủ không gian trống, write sẽ return ngay lập tức. Nó có thể cấp nhận ít data hơn request, nhưng nó không chấp nhận việc không có bất cứ một byte dữ liệu nào. Trong trường hợp này, poll sẽ trả về POLLOUT|POLLWRNORM.
b,Nếu output buffer đầy, mặc định, write sẽ block đến khi có không gian trống. Nếu O_NONBLOCK được set, write sẽ ngay lập tức trả về giá trị -EAGAIN. Trong trường hợp này, poll sẽ thông báo là không thể ghi vào file được. Ngược lại, nếu device không thể tiếp nhận them dữ liệu, write sẽ trả về -ENOSPC (always)
c, Kể cả O_NONBLOCK không được set, thì write cũng không bao giờ đợi data transsmission trước khi return. Điều này là bởi vì nhiều ứng dụng sử dụng select để tìm xem write có bị block không? Nếu device là có thể ghi, system call phải bị block. Nếu như user-app đang sử dụng device muốn đảm bảo rằng data trong hàng đợi để vào output buffer đã được truyền đi thực sự, driver phải cung cấp fsync method.

3. Flushing pending output

Như đã đề cập ở trên, write không có phương pháp nào để tính toán lượng output data. Để làm điều này driver phải cung cấp fsync:
int(*fsync)(struct file *filp, struct detry *dentry, int datasync);
Khi user-app gọi đến fsync, lời gọi này chỉ nên được return khi device đã hoàn thành việc flush data (đẩy hết data trong output buffer sang device), bất kể việc làm này mất bao nhiêu thời gian đi chăng nữa thì nó cũng k nên đợi.

III. The underlying data structure

Poll and select was originally published by Nguyễn Đình Phi at Oni Ranger on January 29, 2018.

Blocking Operation

2018-01-25T00:00:00+08:00

Blocking operations dịch một cách đơn giản nghĩa là thực thi đơn luồng, tức là tác vụ chỉ có thể được thực thi sau khi một hay một số tác vụ nhất định nào đấy đã được hoàn thành. Ví dụ như chương trình Word chỉ có thể đọc một file văn bản sau khi nó đã mở được file đó.

Trong character driver, có implement hai hàm: read() và write(). Thử tưởng tượng, nếu như driver không thể thỏa mãn được yêu cầu một cách tức thời, chẳng hạn như driver sẽ làm gì nếu như hàm read() được gọi khi dữ liệu chưa sẵn có, nhưng có thể nó sẽ có trong tương lai gần. Hoặc một process cố gắng thực hiện lệnh write() nhưng device chưa sẵn sàng nhận dữ liệu bởi vì buffer đang full. Trong trường hợp này, driver nên block process (user-space) lại, đưa nó vào tình trạng sleep cho đến khi các yêu cầu đó có thể được thực thi.

1 Sleeping trong kernel

-Khi một process ở trạng thái sleep, nó sẽ bị loại bỏ khỏi Run queue của bộ lập lịch cho đến khi trạng thái của nó được thay đổi bởi một sự kiện nào đó.
-Một process đang ở trạng thái sleep sẽ không được lập lịch trong CPU.

Để một đoạn code có thể được đưa vào trạng thái sleep thì nó cần thỏa mãn các điều kiện sau đây:
-Điều kiện 1: Không được đưa vào trạng thái sleep khi đang trong một atomic context. Tức là driver không được sleep khi đang giữ spinlock, seqlock hoặc RCU lock.
-Điều kiện 2: Không thể sleep khi đang có các disabled interrupt.
-Điều kiện 3: Sleep trong semaphore là được phép, nhưng cần phải cẩn thận. Nếu một đoạn code sleep trong khi nó đang giữ semaphore thì thread đang đợi semaphore đó cũng sẽ bị đưa vào trạng thái sleep, do đó cần đảm bảo rằng bạn không block luôn kthread sẽ đánh thức sleeping process. (Phần này copy trong sách ldd3, tuy nhiên semaphore đã bị xóa khỏi kernel từ lâu rồi nên không cần quan tâm).
-Điều kiện 4: Khi một sleeping kthread được đánh thức thì nó không thể biết là nó đã bị loại ra khỏi CPU được bao lâu, và trong thời gian đó, đã xảy ra những thay đổi nào. Do đó, chúng ta không thể tạo ra một giả thuyết nào về trạng thái của hệ thống sau khi đánh thức kthread, mà phải kiểm tra xem những điều kiện cần thiết có đảm bảo không.
-Điều kiện 5: Chỉ sleep khi chắc chắn rằng có một ai đó sẽ đánh thức bạn trong một thời điểm nào đó. Ngược lại hệ thống sẽ bị hang. Để làm được điều này thì có một yêu cầu nữa là awaker cần phải tìm được bạn để đánh thức.

2 Wait Queue là gì?

Wait queues được sử dụng khi một task có trạng thái RUNNING trong kernel phải đợi một điều kiện nào đó xảy ra để có thể tiếp tục thực thi. Ví dụ như như hàm read() write() ở phần intro đã nói.

Đối với những task này, việc đưa nó vào trạng thái sleep (không làm gì cả) cho đến khi điều kiện (flag) nó chờ chuyển thành true hoặc tài nguyên nó cần có thể sử dụng được. Lúc này ta cần phải được đưa nó về trạng thái thực thi, bằng cách đánh thức nó. Trong kernel, các thao tác này thực hiện bằng WAIT QUEUE

Các task đang có trạng thái là TASK_INTERRUPTIBLE, TASK_UNINTERRUPTIBLE hoặc TASK_KILLALBLE là các task đang nằm trong tình trạng sleep. Các task đang sleep được chia vào 2 loại: interruptible và uninterruptible. Các task uninterruptible là các task không thể đánh thức bằng các signal(tức là bạn không CTRL+C từ userspace app được), những cái này nên hạn chế sử dụng, vì nó có thể sẽ làm treo hệ thống, và bạn không cách nào tắt nó đi được. Một hệ quả thường thấy nếu như bạn dùng uninterruptible không đúng cách là việc máy của bạn không thể reboot được. b Trong một hệ thống có thể có nhiều wait queue, chúng được kết nối với nhau trong một linked list. Hơn nữa, mỗi wait queue có thể có một hoặc nhiều task.

Linux kernel dùng một structure tên là wait_queue_head_t để biểu diễn một wait_queue. một queue head có thể được khởi tạo bằng các cách sau:
-Initialize statically: DECLARE_WAIT_QUEUE_HEAD(name); -Initialize dynamicly:

	wait_queue_head_t my_queue;
	init_waitqueue_head(&my_queue);

3.Simple Sleep

Một khi đã khởi tạo wait queue, chúng ta có thể sử dụng các hàm được cung cấp để thực hiện việc sleep và wake up các task trong wait queue. -Linux cung cấp function family: wait_event để thực hiện sleeping:
wait_event(queue, condition)
wait_event_interruptible(queue, condition)
wait_event_timeout(queue,condition,timeout)
wait_event_interruptible_timeout(queue, condition, timeout)

-Sau khi đã sleep, linux cung cấp các hàm sau để đánh thức sleeping process:
wake_up(wait_queue_head_t *queue)
wake_up_interruptible(wait_queue_head_t *queue)

Hàm wake_up đánh thức tất cả các process trong hàng đợi, phiên bản interruptible đánh thức các process thực hiện một interruptible sleep.
Thông thường chúng ta sẽ dùng hàm wait_event_interruptible, vì task được sleep bằng hàm này có thể được đánh thức bằng một SIGNAL hoặc một lời gọi đến hàm wake_up, nên việc kiểm tra xem có phải nó được đánh thức bằng một SIGNAL hay không, để đưa ra các phép xử lý đúng là tương đối cần thiết, việc này có thể được thực hiện bằng hàm signal_pending. Ngoài ra nếu bạn không muốn task của bạn sleep quá lâu, thì bạn có thể sử dụng các hàm wait có timeout ở trên. Nếu bạn đọc kernel code thì bạn sẽ thấy là hàm wait sẽ thực hiện 2 việc: thông báo cho trình lập lịch thực hiện lập lịch một task mới và việc thứ hai là chạy một vòng lặp for để kiểm tra điều kiện nó đang đợi.

Nếu như trong wait queue có nhiều task, hàm wake_up sẽ đánh thức tất cả các task có trong wait_queue, và nó không đảm bảo thứ tự của việc đánh thức này. Điều này khá bất tiện trọng một số trường hợp, chẳng hạn như nếu bạn có một số task đang chờ đợi cùng một resource, khi resource này thỏa mãn thì tất cả các task trong wait queue đều được đánh thức, tuy nhiên resource này chỉ cho phép một task sử dụng tại một thời điểm, thì việc đánh thức này rõ ràng tỏ ra không hiệu quả và có thể dẫn đến lỗi. Để giải quyết trường hợp này, kernel cung cấp các hàm sau:

wait_event_interruptible_exclusive(wait_queue_head_t wq, int condition);
void wake_up_all(wait_queue_head_t *wq);
void wake_up_interruptible_all(wait_queue_head_t *wq);
void wake_up_nr(wait_queue_head_t *wq, int nr);
void wake_up_sync_nr(wait_queue_head_t *wq, int nr);
void wake_up_interruptible_nr(wait_queue_head_t *wq, int nr);
void wake_up_interruptible_sync_nr(wait_queue_head_t *wq, int nr);

Ở đây nr là số lượng task sẽ được đánh thức.(thường là 1). Thông thường thì các hàm wait sẽ kiểm tra điều kiện truyền vào (condition flag) ngay tại thời điểm gọi hàm, nếu điều kiện này không thỏa mãn thì nó mới tạo ra một mục mới trong WAIT QUEUE, ngược lại nó sẽ return ngay lập tức, và đoạn code sau lời gọi hàm wait sẽ được thi ngay mà không phải đợi chờ gì cả. WAIT QUEUE về cơ bản chỉ là một cái danh sách liên kết chứa các con trỏ struct wait_queue_entry*

4.Blocking and Nonblocking Operations

Phần này sẽ nói về việc xác định xem khi nào chúng ta sẽ đưa process vào trạng thái sleep?
-Một số operation trong UNIX yêu cầu rằng không được block nó, kể cả nếu như nó không thể thực hiện một cách hoàn toàn. Ngoài ra cũng có một số thời điểm mà process thông tin cho bạn rằng nó không muốn bị block, kể cả nó có thực hiện I/O hay không. Những nonblocking operation rõ rằng này được thông tin bởi cờ O_NONBLOCK trong filp->f_flags.

Ở trường hợp blocking operation, đây là mặc định, các thao tác sau đây nên được impelement:
-Nếu một process gọi hàm read nhưng dữ liệu chưa khả dụng, thì process block. Process được đánh thức ngay khi dữ liệu đến, và dữ liệu được trả về cho người gọi hàm, kể cả nếu lượng dữ liệu trả về ít hơn lượng dữ liệu được yêu cầu (trong argument count).
-Nếu một process gọi hàm write và buffer đầy, process phải block, và nó phải nawmgf ở một wait queue khác so với wait queue đang được sử dụng cho việc reading. Khi một số dữ liệu được ghi vào hardware device, và buffer bắt đầu có không gian trống, process sẽ được đánh thức và write được gọi thành công, mặc dù dữ liệu có thể chỉ được ghi một nửa so với lượng dữ liệu được yêu cầu.

Trường hợp O_NONBLOCK flag được set, nonblocking operations nó sẽ return ngay lập tức, cho phép application lấy dữ liệu. Application phải cẩn thận khi sử dụng các stdio function khi đang sử lý các nonblocking files. Cần phải check errno.
Một cách tự nhiên, O_NONBLOCK rất có ý nghĩa đối với open. Điều này diễn ra khi lời gọi có thể bị block một thời gian dài, ví dụ, khi mở một FIFO mà tạm thời nó chưa có writer, hoặc khi truy cập một disk file với pending lock. Thông thường, việc mở một device có thể thành công hoặc thất bại, mà không cần phải đợi các event bên ngoài. Tuy nhiên, đôi khi việc mở một device yêu cần một thời gian lâu hơn, và chúng ta có thể chọn sử dụng O_NONBLOCK trong hàm open bằng cách trả về lỗi -EAGAIN ngay lập tức nếu như cờ block được set, sau khi bắt đầu tiến trình khởi tạo device.

5.Example

Sau đây mình sẽ trình bày một ví dụ sleep đơn giản. Đầu tiên tạo file source code oni_sleep.c. Tiếp theo là include các header cần thiết:

#include <linux/module.h>
#include <linux/uaccess.h>

Tiếp theo chúng ta define các hằng số cần thiết cho việc xác định device number:

#define MINOR_FIRST 0
#define MINOR_COUNT 1

Khai báo các biến cần thiết cho device driver

static struct cdev oni_sleep_cdev;
static struct class *oni_sleep_class;
static struct device *oni_sleep_device;
static dev_t device_number;
static int sleep_flag=0;

Để thực hiện việc sleep, cần phải khai báo một head queue, ở đây mình khai báo head queue bằng cách dùng DECLARE (Statically)

DECLARE_WAIT_QUEUE_HEAD(oni_wait_queue);

Ở đây ngoài các cấu trúc quen thuộc với một device driver, mình có khai báo thêm biến sleep_flag, biến này sẽ được dùng để làm điểu kiện wake up cho process đã bị sleep trước đó (sleeping process sẽ được đánh thức khi sleep_flag=1)
Tiếp đến là định nghĩa 2 function của file_operations: open() và release()

int sleep_open(struct inode *node, struct file *filp)
{
	//Do nothing at the moment
	return 0;
}

int sleep_release(struct inode *node, struct file *filp)
{
	//Do nothing at the moment
	return 0;
}

Tạm thời 2 function này sẽ không làm gì cả
Kế tiếp là function read. Ở đây hàm read sẽ không thực hiện đọc dữ liệu hay làm gì khác cả. Nó chỉ ghi ra các log để trace quá trình sleep và wakeup mà thôi.

ssize_t sleep_read(struct file *filp, char __user *buf, size_t count, loff_t *pos)
{
	printk(KERN_INFO "[READ] Enter read function\n");
	printk(KERN_WARNING "[READ] About to sleep\n");
	wait_event_interruptible(oni_wait_queue, sleep_flag == 1);
	printk(KERN_INFO "[READ] read woken up\n");
	sleep_flag = 0;
	return 0;
}

Ở hàm read, sau khi in ra 2 log line (dmesg), mình đã block hàm read, và chờ cho điều kiện sleep_flag==1 thì sẽ đánh thức nó dậy. Mình sử dụng head queue đã khai báo ở đầu, đưa process vào wait_interruptible, tức là người dùng có thể Ctrl+C để thoát user-app khi nó đang đợi read trả về.
Bây giờ, mình sẽ wake up hàm read từ hàm write, hiện tại hàm write cũng chỉ được dùng để đánh thức hàm read từ hàng đợi mà không có ghi dữ liệu gì sất. Mình sẽ dùng wake_up để đánh thức tất cả các entry trung head queue dậy.

ssize_t sleep_write(struct file *filp, const char __user *buf, size_t count, loff_t *pos)
{
	printk(KERN_INFO "[WRITE] Enter write function\n");
	printk(KERN_INFO "[WRITE] Wake read up ZZZZZZ\n");
	wake_up(&oni_wait_queue);
	printk(KERN_INFO "[WRITE] Exit write\n");
}

Chúng ta đã có đầy đủ các file operation cần thiết, bây giờ chúng ta có thể khai báo struct file_operations cho oni_sleep

static struct file_operations oni_fops={
	.open = sleep_open,
	.release = sleep_release,
	.read = sleep_read,
	.write = sleep_write,
	.owner = THIS_MODULE	
};

Bây giờ chúng ta đã có đủ các thành phần để bắt đầu khởi tạo module, hãy bắt tay vào việc:

static int __init oni_sleep_init(void)
{
	int ret;
	ret = alloc_chrdev_region(&device_number, MINOR_FIRST, MINOR_COUNT, "oni_sleep");
	if(ret != 0)
	{
		printk(KERN_WARNING "Cannot alloc a region of device number\n");
		return ret;
	}

	cdev_init(&oni_sleep_cdev, &oni_fops);
	ret = cdev_add(&oni_sleep_cdev, device_number, MINOR_COUNT);
	if ( ret != 0 )
	{
		printk(KERN_WARNING "Cannot register module with kernel\n");
		return ret;	
	}
	printk(KERN_INFO "Regitered module with kernel\n");

	oni_sleep_class = class_create(THIS_MODULE, "oni_sleep");
	if (IS_ERR(oni_sleep_class))
	{
		unregister_chrdev_region(device_number, MINOR_COUNT);
		printk(KERN_WARNING "Cannot create device class\n");
		return PTR_ERR(oni_sleep_class);	
	}
	printk(KERN_INFO "Created device class\n");

	oni_sleep_device = device_create(oni_sleep_class, NULL, device_number, NULL, "oni_sleep");
	if (IS_ERR(oni_sleep_device))
	{
		class_destroy(oni_sleep_class);
		cdev_del(&oni_sleep_cdev);
		unregister_chrdev_region(device_number, MINOR_COUNT);
		printk(KERN_WARNING "Cannot create device file\n");
		return PTR_ERR(oni_sleep_device);	
	}	
	printk(KERN_INFO "Created device file\n");
	return 0;
}

Tiếp theo tất nhiên là hàm exit

static void __exit oni_sleep_exit(void)
{
	device_destroy(oni_sleep_class, device_number);
	class_destroy(oni_sleep_class);
	cdev_del(&oni_sleep_cdev);
	unregister_chrdev_region(device_number, MINOR_COUNT);
	printk(KERN_INFO "Say goodbyte to your hand!\n");
}

Những thứ râu ria khác, nhưng rất cần thiết

MODULE_LICENSE("GPL");            ///< The license type -- this affects available functionality
MODULE_AUTHOR("Oni Ranger");    ///< The author -- visible when you use modinfo
MODULE_DESCRIPTION("A simple Linux char driver for explain sleeping");  ///< The description -- see modinfo
MODULE_VERSION("0.1");            ///< A version number to inform users
module_init(oni_sleep_init);
module_exit(oni_sleep_exit);

Tiếp theo chúng ta cần tạo ra một user-app để tương tác với device driver đã tạo tên là test.c

#include<stdio.h>
#include<stdlib.h>
#include<errno.h>
#include<fcntl.h>
#include<string.h>
#include<unistd.h>

#define BUFFER_SIZE 256;

int read_device(int fd)
{
	char fakeRecv[BUFFER_SIZE];
	printf("Press anykey to block your read function\n");
	getchar();
	read(fd, fakeRecv, strlen(fakeRecv));
	printf("Woken up\n");
}

int write_device(int fd)
{
	char fakeInput[]="hello";
	printf("Press anykey to wake up your read function\n");
	getchar();
	write(fd, fakeInput, strlen(fakeInput));
}

int main(int argc, char* argv[])
{
	int fd;
	fd = open("/dev/oni_sleep",O_RDWR);
	if(fd<0)
	{
		perror("Failed to open the device ....");
		return errno;
	}

	if(argc == 2)
	{
		//nếu có tham số dòng lệnh thì nghĩa là write to device
		write_device(fd);
	}else
	{
		read_device(fd);
	}
}

Tiếp theo cần một Makefile để compile những source code dã mổ cò

obj-m+=oni_sleep.o
all:
 make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
 $(CC) test.c -o test
clean:
 make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean
 rm test

Bây giờ hãy thử xem nó hoạt động như thế nào.
Sau khi đã compile, chúng ta nhận được file oni_sleep.ko và test. Việc tiếp theo là insert oni_sleep: sudo insmod oni_sleep.ko
Mở một tab mới với thực hiện việc đọc từ device với command: sudo ./test
Ở tab này bạn sẽ nhìn thấy output như sau:

Press anykey to block your read function
....

Sau khi bạn gõ Enter, tab này sẽ bị block tại đây thay vì return. Mở một tab khác với thực hiện việc ghi vào device với command: sudo ./test write. Như đã đề cập ở trên, hàm write sẽ unblock hàm read.
Bây giờ quay lại tab read, gõ Enter xem process còn bị block hay không? Wth, hàm read vẫn bị block @@. Tất nhiên là thế rồi, vì mặc dù mình đã gọi hàm wake_up để đánh thức hàm read, nhưng điều kiện sleep_flag==1 vẫn chưa được thảo mãn nên nó vẫn tiếp tục bị block. Gõ Ctrl+C để kill nó.
Bây giờ, mình sẽ set cờ sleep_flag bằng 1 trước khi gọi wake_up, thêm dòng code vào hàm sleep_write như sau:

......
sleep_flag = 1;
wake_up(&oni_wait_queue);
.............

Bây giờ compile lại, sau đấy insmod và thực hiện test như cũ. Bạn sẽ thấy tab read được unblock sau khi thực hiện sudo ./test write.
Bây giờ kiểm tra dmesg:

[READ] Enter read function
[READ] About to sleep
[WRITE] Enter write function
[WRITE] Wake read up ZZZZZZ
[WRITE] Exit write
[READ] read woken up

Bây giờ, thử xem wait_event khác wait_event_interruptible như thế nào. Thay wait_event_interruptible trong hàm sleep_write thành wait_event, các tham số vẫn dữ nguyên như cũ, compile lại module, và insert nó vào hệ thống. Tiếp theo, thực hiện test bằng command sudo ./test. Bây giờ, user-app sẽ bị block ở đây, bạn ấn tổ hợp Ctrl+C xem có gì xảy ra? @@ không thể kill chương trình được. Đúng vậy, wait_event sẽ không cho phép chúng ta ngắt process đang bị block, khác với wait_event_interruptible.
Các hàm wait timeout sẽ return sau một khoảng thời gian(timeout), đơn vị tính là Jiffies

Blocking Operation was originally published by Nguyễn Đình Phi at Oni Ranger on January 25, 2018.

Input Output Control Ioctl

2018-01-19T00:00:00+08:00

Như đã biết thì Linux OS chia bộ nhớ thành 2 phần riêng biệt là user space và kernel space. Kernel space dùng để thực thi kernel, các extensions của nó và hầu hết các device driver. Ngược lại Userspace là vùng nhớ mà tất cả các ứng dụng thường người làm việc, tất nhiên là tồn tại nhu cầu để giao tiếp giữa 2 phần này với nhau. Trong Linux chúng ta có thể dùng một số phương pháp phục vụ mục đích này như: ioctl, procfs, sysfs,… Trong bài này diễn viên chính sẽ là ioctl.

ioctl = Input and Output Control, được sử dụng để userspace giao tiếp với device driver. Phần lớn ioctl được sử dụng trong các trường hợp mà một số thao tác đặc thù của một device không được hỗ trợ bởi một systemcall mặc định.

Ở user space, linux cung cấp ioctl system call có prototype như sau:
int ioctl(int fd, unsigned long cmd, ...);</br> Trong C, ... là va_arg (một lượng tham số truyền vào không biết trước), tuy nhiên, một system call không thể nào có va_arg được(Tại sao?). Bởi thế, ... ở đây là một argument tùy chọn (có thể có hoặc không). argument này có thể là bất kỳ type nào.

-Prototype của ioctl trong ldd:
int (*ioctl)(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg);
[kernel]inode+filp = [user-space]fd</br> (need a image here)
-Nếu lời gọi ioctl từ tầng ứng dụng muốn truyền thêm tham số thì trong kernel-space, nó luôn được truyền như là một biến unsigned long, bất kể biến truyền vào ở user-space là integer hay pointer. Nếu user-space program không truyền thêm tham số tùy chọn thì biến arg trong tầng nhân sẽ là undifined

Đối với từng command thì có một tác vụ tương ứng được thực hiện
Thông thường ioctl sẽ sử dụng switch(command) để thực hiện nhiệm vụ của nó.

1. Command number (cmd arg) và cách chọn cmd arg.

-Không nên sử dụng cách chọn một tập các số bắt đầu từ 0(hoặc 1) để dùng cho cmd arg. Lý do là các ioctl của các driver khác nhau nên sử dụng các cmd arg khác nhau, hay nói cách khác, mỗi cmd arg nên là một giá trị độc lập duy nhất trong toàn hệ thống. Vì lục này nếu user-space prog truyền cmd của driver A và ioctl của driver B thì prog sẽ nhận được giá trị trả về là EINVAL thay vì một thao tác không đoán trước được và không đúng mong muốn của người dùng.

Vậy chọn giá trị nào cho cmd arg?
Đầu tiên cần kiểm tra include/asm/ioctl.h và Documentation/ioctl-number.txt để xem những giá trị đã được xí trước để tránh dùng những giá trị này.

Command numbers (cmd) được định nghĩa bằng cách sử dụng 4 bitfields: type, number, direction, type. Mỗi bitfield có ý nghĩa như sau:
type: Magic number, ứng với một device driver có một magic number duy nhất. Bitfield này có độ rộng là 8 bits(_IOC_TYPEBITS).
number: Đây là số thứ tự. Có kích thước 8 bít (_IOC_NRBITS).
direction: Chiều truyền tải của dữ liệu (đọc/ghi/nothing): _IOC_NON(không truyền dữ liệu), _IOC_WRITE, _IOC_READ, nếu vừa đọc vừa ghi dữ liệu thì có thể dùng _IOC_WRITE|_IOC_READ. view point ở đây là từ user-space application. tức là ĐỌC từ device, GHI vào device.
size Kích thước của data. Bitfield này có độ rộng phụ thuộc và kiến trúc của hệ thống, nhưng thường là 13/14 bits. Kích thước cho từng kiến trúc (arch) cụ thể có thể được tìm thấy bằng macro _IOC_SIZEBITS, hầu hết giá trị này là 14, chỉ có một số ngoại lệ như MIPS, Sparc hay PowerPC là 13. Thật ra field này là không bắt buộc, nhưng việc sử dụng nó giúp cho driver có thể phát hiện errors. Vì chỉ có 13/14bits thì nó sẽ không đủ để ghi kích thước dữ liệu khi dữ liệu quá lớn.

2. Setup command number với asm/ioctl.h

header này cung cấp các macro giúp chúng ta dễ dàng hơn trong việc setup các command number: -_IO(type, nr) : Command không nhận argument
-_IOR(type, nr, datatype): Command đọc dữ liệu từ device
-_IOW(type, nr, datatype): Command ghi dữ liệu vào device
-_IOWR(type, nr, datatype): Dữ liệu được truyền ở cả hai chiều.
Đối với các command này: type và number được truyền như các args, ở đây chúng ta không thấy field size, thật ra, nó sẽ được macro tạo ra bằng cách sizeof(datatype)

Cũng trong header này, các macros dùng decode numbers được định nghĩa như sau:_IOC_DIR(nr), _IOC_TYPE(nr), _IOC_NR(nr), _IOC_SIZE(nr) tương ứng (direction, type, sequence number, data size).
Ví dụ về ioctl command number definations:
#define ONI_IOCREAD _IOR(ONI_MAGIC_NR,FIRST_SEQ);

3. Giá trị trả về của ioctl

Các ioctl command có thể trả về các error code có giá trị âm như đã được định nghĩa trong file errno.h. Trong trường hợp yêu cầu của user space được thực hiện thành công thì giá trị trả về nên là 0.
Trong trường hợp driver không định nghĩa giá trị cho command number được truyền vào, thì giá trị trả về có thể là -ENOTTY hoặc -ENOIOCTLCMD.

4. Sử dụng argument trong ioctl

-Argument ở đây có thể là integer number hoặc pointer
-Nếu argument truyền vào là một pointer thì cần đảm bảo rằng địa chỉ tầng ứng dụng là hợp lệ, nếu không nó có thể gây ra kernel ops… Driver cần kiểm tra tất cả các pointer được truyền vào

5. Ví dụ

“Không gì tốt hơn thực hành” Một cao nhân dấu tên, dấu cả chân đã nói thế. Sau đây sẽ là một ví dụ về ioctl.
Ví dụ này sẽ gồm 2 thành phần:

Device driver : oni_ioctl
User-space app: oni_app
Đầu tiên cần tạo ra 1 file header chứa các biến cần thiết để sử dụng.</br> oni_ioctl.h

#ifndef ONI_IOCTL_H
#define ONI_IOCTL_H
#include <linux/ioctl.h>

type def struct{
	int day, month, year;
}birthday;

//Define 3 command numbers with type (magic number) is 'o', sequen: 1,2,3. Data type query_arg_t
#define QUERY_GET_VARIABLES _IOR('o',1,birthday *)
#define QUERY_CLR_VARIABLES _IO('o',2)
#define QUERY_SET_VARIABLES	_IOW('o',3,birthday *)

Ở file header, mình đã định nghĩa ra một kiểu mới tên là birthday, là một struct gồm 3 interger number. Đây cũng là argument truyền vào cho các lời gọi ioctl ở phần sau. Sau đấy là 3 command number được sử dụng bởi Oni Ioctl.
Tất cả các cmd number đều sử dụng chung một magic number là ‘o’ (nó sẽ tự đổi ra int), theo lý thuyết thì các cmd number của cùng 1 device không bắt buộc phải có magic number giống nhau, nhưng trên thực tế, việc sử dụng 1 magic number duy nhất sẽ giúp code dễ quản lý, đẹp mắt, ảo lòi hơn.
Các cmd number có sequence number lần lượt là 1, 2, 3. Ở cmd number đầu tiên, chúng ta khai báo rằng nó sẽ đọc dữ liệu từ device và sử dụng tham số có kiểu birthday. Ở cmd number thứ 2, chúng ta k dùng tham số. (mấy cái này tượng trưng thôi, có dùng _IO hết cũng chả chết, nhưng mà code cleaning is good).
File header này sẽ được include ở cả ldd và user-space app.

Tiếp theo sẽ là file source cho ldd, mình tạo 1 file mới tên là oni_ioctl.c
Đầu tiên phải include những header cần thiết vào

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/version.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/error.h>
#include <asm/uaccess.h>

#include "query_ioctl.h"

Tiếp theo chúng ta sẽ define 2 macro cho minor
#define FIRST_MINOR 0
#define MINOR_CNT 1
ở đây chúng ta sẽ tạo 1 minor duy nhất bắt đầu từ 0.

Tiếp theo là khai báo một biến dev_t: biến này sẽ lưu device number cho device sắp tới
static dev_t dev;

Struct cdev (character device) cho device.
static struct cdev c_dev;

Struct class dùng để tạo ra device file trong thư mục /sys/class
static struct class *c1;

Đây là các giá trị mặc định ban đầu của day, month, year.
static int day = 11, month = 02, year = 1993;

Bây giờ đến file_operations, trước hết chúng ta cần declare các hàm sẽ được refer từ file_operations.

static int my_open(struct inode *i, struct file *f);
static int my_close(struct inode *i, struct file *f);
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35))
static int my_ioctl(struct inode *i, struct file *f, unsigned int cmnd, unsigned long arg);
#else
static long my_ioctl(struct file *f, unsigned int cmd, unsigned long arg);
#endif

Hàm my_open và my_close không cần thực hiện tác vụ gì cả, nên chúng ta chỉ cần định nghĩa chúng là các hàm có thân hàm rỗng là được.
Hàm my_ioctl có có prototype khác nhau, phục thuộc vào kernel đang sử dụng.
Khi đã có các function declaration rồi thì chúng ta có thể khai báo struct file_operations như sau:

statc struct file_operations oni_fops=
{
	.owner = THIS_MODULE,
	.open = my_open,
	.release = my_close,
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,35))
	.ioctl = my_ioctl
#else
	.unlocked_ioctl = my_ioctl
#endif
};

Đầu tiên khi ldd được insert vào hệt thống, nó sẽ chạy init đầu tiên, nên mình viết hàm init trước cho nó theo thứ tự ahihi. Trước hết là khai báo 2 local variables để lưu giữ result của 1 số lời gọi hàm trong lúc khởi tạo ldd

static void __init oni_init(void)
{
	int ret;
	struct device *dev_ret;
}

Tiếp theo, chúng ta sẽ đăng ký device number cho driver, sử dụng alloc_chrdev_region.

...
if((ret = alloc_chrdev_region(&dev, FIRST_MINOR, MINOR_CNT,"query_ioctl"))<0)
{
	printk(KERN_WARNING "Cannot register device number range");
	return ret;
}

Ở đây chúng ta đăng ký một device driver với major number được cấp phát động và chỉ một minor number duy nhất (0). Hàm alloc_chrdev_region sẽ trả về giá trị âm nếu việc đăng ký thất bại. Device number tạo ra sẽ được lưu vào variable dev

Tiếp theo là khởi tạo character device với cấu trúc cdev ở trên và file_operations chúng ta đã định nghĩa lúc trước. Sau đó dùng hàm cdev_add để thêm nó device vào system

...
cdev_init(&c_dev, &query_fops);

if((ret = cdev_add(&c_dev,dev,MINOR_CNT))<0)
{
	printk(KERN_WARNING "Cannot register device to kernel");
	return ret;
}

Tạo class cho device, sau bước này, device sẽ xuất hiện trong /sys/class directory.

...
if(IS_ERR(c1=class_create(THIS_MODULE,"char")))
{
	cdev_del(&c_dev);
	unegister_chrdev_region(dev, MINOR_CNT);
	printk(KERN_WARNING "Cannot create device class");
	return PTR_ERR(c1);
}

Nếu việc tạo class thất bại, thì chúng ta sẽ phải unregister device number range và xóa struct c_dev đã được khởi tạo.

Bước cuối cùng trong việc init là tạo device file

...
if(IS_ERR(dev_ret = device_create(c1,NULL,dev,NULL,"query")))
{
	class_destroy(c1);
	cdev_del(&c_dev);
	unegister_chrdev_region(dev, MINOR_CNT);
	printk(KERN_WARNING "Cannot create device file");
	return PTR_ERR(dev_ret);
}
printk(KERN_NOTICE "LDD inserted successfully");
return 0;

Hàm tiếp theo chúng ta động tới là hàm exit của module. Hàm này cực kỳ đơn giản, chỉ cần phá hết những gì đã làm trong hàm init là được. open và release cũng là một cái tạo ra và một cái đập phá những thứ được tạo ra, tuy nhiên open/release được gọi trên đơn vị fd, còn init/exit là module

static void __exit oni_exit(void)
{
	device_destroy(c1,dev);
	class_destroy(c1);
	cdev_del(&c_dev);
	unregister_chardev_region(dev, MINOR_CNT);
	return PTR_ERR(dev_ret);
}

Bây giờ đến phần chính của bài viết này: IOCTL. Hàm này không có gì ngoài một lệnh switch =))

#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35))
static int my_ioctl(struct inode *i, struct file *f, unsigned int cmnd, unsigned long arg)
#else
static long my_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
#endif
{
	birthday q;
	switch(cmd)
	{
		case QUERY_GET_VARIABLES:
			q.day = day;
			q.month = month;
			q.year = year;
			if(copy_to_user((query_arg_t *)arg, &q, sizeof(query_arg_t)))
			{
				return -EACCES;
			}
			break;
		case QUERY_CLR_VARIABLES:
			q.day = 1;
			q.month = 1;
			q.year = 1970;
		case QUERY_SET_VARIABLES:
			if(copy_from_user(&q,(query_arg_t *)arg,sizeof(query_arg_t)))
			{
				return -EACCES;
			}
			day = q.day;
			month = q.month;
			year = q.year;
			break;
		default:
			return -EINVAL
	}
	return 0;
}

Trong hàm my_ioctl, chúng ta sử dụng 1 câu lệnh switch-case để thực hiện các hành động tương ứng với mỗi cmd number đã khai báo ở file header.

Tiếp theo là chương trình (user-space) để sử dụng các ioctl cmd đã khai báo:

//filename: query_app.c
#include <stdio.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <sys/ioctl.h>

//Include để sử dụng các khai báo.
#include "query_ioctl.h"

void get_vars(int fd)
{
    query_arg_t q;
    if(ioctl(fd, QUERY_GET_VARIABLES,&q) == -1)
    {
            perror("query_apps ioctl get");
    }
    else
    {
            printf("Day: %d\n", q.day);
            printf("Month: %d\n", q.month);
            printf("Year: %d\n", q.year);
    }
}

void clr_vars(int fd)
{
    if(ioctl(fd, QUERY_CLR_VARIABLES) == -1)
    {
            printf("query_apps ioctl clr\n");
    }
}

void set_vars(int fd)
{
    int v;
    query_arg_t
    printf("Enter Day: \n");
    scanf("%d",&v);
    getchar();
    q.day = v;
    printf("ENTER Month: \n");
    scanf("%d",&v);
    q.month = v;
    getchar();
    printf("ENTER Year: \n");
    scanf("%d",&v);
    getchar();
    q.year
    if(ioctl(fd, QUERY_SET_VARIABLES, &q) == -1)
    {
            perror("query_apps ioctl set");
    }
}

int main(int argc, char *argv[])
{
	//Đây là đường dẫn đến dev file
    char *file_name = "/dev/query";
    int fd;
    enum
    {
            e_get,
            e_clr,
            e_set
    }option;

    /*
    Phần còn lại sẽ kiểm tra số tham số được truyền vào, và dựa vào đấy sẽ thực hiện các lời gọi đến hàm tương ứng
    */

    if(argc == 1)
    {
            option = e_get;
    }
    else if(argc ==2)
    {
            if(strcmp(argv[1], "-g") == 0)
            {
                    option = e_get;
            }
            else if(strcmp(argv[1], "-c") == 0)
            {
                    option = e_clr;
            }
            else if(strcmp(argv[1],"-s") == 0)
            {
                    option = e_set;
            }
            else
            {
                    fprintf(stderr, "Usage %s [-g|-c|-s]\n", argv[0]);
                    return 1;
            }
    }
    else
    {
            fprintf(stderr, "Usage %s [-g|-c|-s]\n",argv[0]);
            return 1;
    }

    //Lấy file descriptor của device file
    fd = open(file_name, O_RDWR);
    if(fd == -1)
    {
            perror("query_apps open");
            return 2;
    }

    switch(option)
    {
            case e_get:
                    get_vars(fd);
                    break;
            case e_clr:
                    clr_vars(fd);
                    break;
            case e_set:
                    set_vars(fd);
                    break;
            default:
                    break;
    }

    close(fd);
    return 0;
}

Sau khi đã hoàn thành cả ldd và app, chúng ta có thể test nó, đầu tiên cần insert module vào kernel: insmod oni_ioctl.ko Bây giờ mở terminal và enter command sudo query_app, lúc này, nó sẽ thực hiện gọi đến hàm e_get, tức là thực hiện command number QUERY_GET_VARIABLES của ldd. Kết quả in ra màn hình sẽ là giá trị mặc định đã khai báo trong file oni_ioctl.c:

Day: 11
Month: 2
Year: 1993

Bây giờ, sử dụng ioctl để thay đổi giá trị của birthday lưu trong ldd bằng cách sử dụng command: sudo query_app -s, sau đó nhập giá trị bạn muốn vào. Lúc này, nếu sử dụng sudo query_app hoặc sudo query_app -g để in thì bạn sẽ thấy giá trị mới nhập vào sẽ được in ra màn hình.

Input Output Control Ioctl was originally published by Nguyễn Đình Phi at Oni Ranger on January 19, 2018.

Mutex Complitions Spinlock

2018-01-15T00:00:00+08:00

1. Đồng bộ hóa trong Linux kernel.

Linux kernel là một hệ điều hành đa nhiệm, nó tồn tại các luồng thực thi chia sẻ dữ liệu dùng chung với nhau, do đó việc đảm bảo các tài nguyên này không bị truy cập đồng thời từ nhiều tiến trình hay đồng bộ hóa tiến trình là hết sức cần thiết. Trong lập trình, các đoạn code truy cập đến phần dữ liệu dùng chung được gọi là Critical Region. Trên góc nhìn thực tế đầy tiền mặt, thì chẳng hạn như có 1 cột ATM VCB đang dựng đấy, người nào muốn rút tiền thì phải nhét thẻ(card) và gõ pass mang tiền về. Rõ ràng là để đưa thẻ cho cây ATM thì cần tiếp cận được cái lỗ (nhận thẻ) của nó, có thể coi cãi lỗ đấy là key, ai sở hữu key đó thì mới có thể rút tiền được, ngược lại sẽ phải đứng đợi đến khi cái lỗ đấy trống để đút vào.

Còn trong thế giới phần mềm thì bạn có thể tưởng tượng ra việc bạn có một dãy đèn LED và có 2 thread (hoặc process) đều cố gắng ghi các giá trị khách nhau vào vị trí đèn, điều gì sẽ xảy ra ? Đây chính là trường hợp Race condition (sách tiếng việt gọi là miền găng). Bởi vì việc thread nào chạy trước, thread nào chạy sau hoàn toàn phụ thuộc vào giải thuật lập lịch và về cơ bản là chúng ta không đoán trước được, nên kết quả của viêc này chúng ta không đoán trước được.

. Qua hai ví dụ trên, dễ thấy việc nhiều luồng thực thi truy cập cùng một tài nguyên tại cùng một thời điểm là không an toàn, ẩn chứa nhiều hiểm nguy, côn trùng. Do đó, tốt nhất là nên ngăn chặn việc truy cập đồng thời này, tức là khi một luồng thực thi đang truy cập và sử dụng tài nguyên dùng chung, thì chúng ta cần đảm bảo nó sẽ hoàn thành việc sử dụng tài nguyên này trước khi một luồng thực thi khác có thể truy cập, hay nói cách khác, thao tác này phải là atomic, không thể bị ngắt quãng. Để tránh race condition, các nhà khoa học tiền bối đã phát minh ra một số phương pháp, đa số dựa trên kỹ thuật locking.

1. Mutex trong Linux.

Mutex là gì ? Theo 1 góc nào đó trên wiki thì: khái niệm “mutex” thường được sử dụng để mô tả một cấu trúc ngăn cản hai tiến trình cũng thực hiện một đoạn mã hoặc truy cập một dữ liệu cùng lúc. Vậy về mặt khoa học, Mutex là gì? Mutex là một khóa “loại trừ lẫn nhau”. Tại mỗi thời điểm chỉ có 1 thread có thể giữ khóa. Mutex có thể được sử dụng để tránh race condition. Một khi mutex bị lock thì chỉ có thread đã lock nó mới có thể unlock nó. Do đó, mỗi khi bạn muốn truy cập 1 tài nguyên dùng chung thì đầu tiên bạn phải khóa mutex (trong trường hợp bạn dành được khóa) rồi mới sử dụng tài nguyên, và nhớ phải unlock nó cho người khác dùng sau khi bạn đã hoàn thành công việc.

 
struct mutex {
    atomic_t        count;
    spinlock_t      wait_lock;
    struct list_head    wait_list;
};

Một mutex có thể được khởi tạo bằng DEFINE_MUTEX(name) - trong trường hợp mutex được khai báo vả khởi tạo ở compile time. Hoặc mutex_init(struct mutex *lock)- trong trường hợp chúng ta muốn khởi tạo mutex ở run-time.

Khi mutex đã được khởi tạo thì chúng ta có thể lock hay unlock nó. Kernel API cung cấp 5 hàm cho các tác vụ này, bao gồm 3 hàm được sử dụng cho việc lock, một hàm cho việc unlock, hàm còn lại dùng cho việc kiểm tra tình trạng mutex.

mutex_lock Sử dụng để lock/acquire mutex. Nếu mutex không khả dụng, thì task hiện tại sẽ được cho vào trạng thái sleep cho đến khi nó giành được mutex.
mutex_lock_interruptible Tương tự như hàm mutex_lock, tuy nhiên trong thời gian đợi mutex, ta có thể interrupt task, chẳng hạn với CTRL+C.
mutex_trylock Giống như cái tên của nó, nếu không dành được lock nó sẽ return chứ không đợi chờ gì cả.
mutex_unlock Hàm này được sử dụng để giải phóng một mutex mà nó đã khóa trước đó (cùng 1 thread - task). Ai thắt nút thì người đó phải mở nút. Lưu ý rằng khi một process đang sở hữu một mutex, thì process đó chỉ có thể kết thúc nếu nó đã unlock cho mutex nó đang nắm giữ.
mutex_is_locked kiểm tra xem mutex có đang bị lock không (có thể dùng chúng với mutex_trylock).

Tại một thời điểm thì có một và chỉ một task có thể nắm giữ mutex, hơn nữa chỉ có task đang nắm giữ Mutex mới có thể thực hiện các thay đổi trạng thái của Mutex. Quyền sở hữu mutex không có tính đệ quy, tức là khi bạn không thể gọi đến hàm lock() của một mutex mà ta đã gọi hàm lock() thành công trước đó. Khi một task không dành được quyền sử dụng thì nó sẽ được chuyển sang trạng thái “ngủ” (sleep) và scheduler sẽ đưa nó vào hàng đợi để dành processor cho một task khác. Điều này có nghĩ là mutex chỉ có thể được sử dụng trong process context, chúng ta KHÔNG thể sử dụng mutex khi đang ở trong interrupt context được.

2. Completion Variable

Một trong các pattern phổ biến trong kernel programming là khởi tạo một số activity bên ngoài luồng thực thi hiện tại, sau đó đợi đến khi activity đó hoàn thành(async), Activity này có thể là tạo một kernel thread hoặc một user-space process mới, một request đến một process đã tồn tại, hoặc một số hardware-based action. Ví dụ:

	struct semaphore sem;
	init_MUTEX_LOCKED(&sem);
	start_external_task(&sem);
	down(&sem);

(Code trên sẽ làm giảm performance, hơn nữa vì semaphore đã bị loại bỏ trong các bản kernel > 3.x nên code này không compile được đâu :gach: ) external_task sau đó có thể gọi up(&sem) khi công việc của nó hoàn thành. Completion interface được dùng trong trường hợp này, nó cho phép một thread có thể thông báo với một thread khác rằng nó đã hoàn thành công việc. Do kỹ thuật này khá thông dụng, nên Linux kernel cung cấp Completion variable để thực hiện các thao tác này. Compiletion variable trong linux kernel được biểu diễn bằng struct completion, cấu trúc dữ liệu này và các function thao tác trên nó được khai báo trong file header: linix/completion.h
Tạo một completion tại compile time bằng macro: DECLARE_COMPLETION(my_completion);
Trường hợp cần khởi tạo ở runtime: struct comletion my_completion; struct init_completion(&my_completion); Sau đấy chúng ta cần báo cho thread biết nó cần đợi completion.
wait_for_completion(struct completion *c);
function này tạo ra một uninterruptible wait(tức là chúng ta không thể kill được process cho đến khi cái completion được set là đã hoàn thành).
Thread đang được đợi, sẽ thông báo cho calling thead rằng nó đã hoàn thành công việc bằng cách gọi một trong hai hàm sau:
complete(struct completion *c); Chỉ wake up một thread duy nhất
compelete_all(struct completion *c); Weke up tất cả các thread đang đợi
Một completion thường là one-shot device, tức là nó chỉ được dùng 1 lần sau đó sẽ bị discard. Tuy nhiên, việc sử dụng lại một completion là khả dĩ. Nếu complete_all không được sử dụng, thì struct completion có thể được sử dụng lại một cách dễ dàng. Nếu complete_all đã dược gọi, thì completion variable cần được tái tạo trước khi sử dụng với macro:
INIT_COMPLETION(struct completion c);
Appendex: void complete_and_exit(struct completion *c, long retval);

Một ứng dụng phổ biến của completion variable trong Linux kernel là dùng để kiểm tra việc load các offload-firmware cho các thiết bị PCIe hay USB.

3. Spinlocks

Mặc dù mutex rất hữu ích, nhưng trong kernel việc xử lý race condition được thực hiện bằng một kỹ thuật tên là spinlock. Không giống như mutex, spinlocks có thẻ được sử dụng được ở trong các đoạn code không thể sleep, ví dụ như các interrupt handlers. Khi được sử dụng đúng cách, spinlock cung cấp hiệu năng cao hơn so với mutex. Tuy nhiên spinlock cũng có một tập các ràng buộc riêng của nó.

Một spinlock là một mutual exclusion device có thể có hai và chỉ hai trạng thái “locked” và “unlocked”. Nó thường được implement như một bit trong một số int.
Nếu như lock là khả dụng, thì “locked” bit được set và code sẽ tiếp tục thực thi (đi vào critical section). Ngược lại, nếu một ai đó đã set bit “locked” từ trước, thì code sẽ đi vào một vòng lặp nhỏ, và lặp đi lặp lại việc kiểm tra lock cho đến khi bit “locked” được unset. Vòng lặp này được gọi là spin.
Đây cũng là điểm khác biệt giữa Mutex và Spinlock. Trong thời gian spinlock đang “xoay” thì processor sẽ không thể thực thi các tác vụ khác, còn mutex thì processor có thể chuyển sang làm việc khác. Thoạt nghe thì có vẻ spinlock đã lãng phí tài nguyên (processor), tuy nhiên thực tế thì với các trường hợp mà thời gian chờ đợi để truy cập dữ liệu dùng chung của task là rất nhỏ, và tần suất vào ra miền dùng chung cao, thì việc sử dụng spinlock vẫn cho hiệu quả hơn hẳn vì nó không tốn chi phí thực hiện các context switch. Tất nhiên, việc set và unset “locked” bit cần được thực hiện trong ngữ cảnh atomic, điểu này đảm bảo rằng chỉ có một thread duy nhất có thể dành được lock, kể cả nếu như có nhiều spin đang hoạt động.
Cần cẩn thận với deadlocks trên hyperthreaded processors.
Spinlock được tạo ra để hướng đến việc sử dụng trên multiprocessor systems.

4. Spinlock API

Để sử dụng được spinlock trong kernel thì các config CONFIG_PREEMPT và CONFIG_SMP phải được enable. ( Không có preemption và multi core thì bạn không cần mấy cái kỹ thuật này làm gì cả). Các hàm và cấu trúc liên quan của spinlock được khai báo trong file header linux/spinlock.h
Và cũng giống như mutex, spinlock api cung cấp hai khả năng khởi tạo một spinlock:

Khởi tạo spinlock ở compile time: DEFINE_SPINLOCK(lock);
Khởi tạo spinlock ở runtime: void spin_lock_init(spinlock_t *lock);

Trước khi vào miền găng, cần phải dành được lock bằng lời gọi hàm sau:
spin_lock(spinlock_t *lock);
Khi code của bạn gọi hàm này, nó sẽ spin đến khi lock khả dụng, lưu ý là tất cả các spin là không thể ngắt.(Cẩn thận deadlock)
Sau khi thực hiện xong các tác vụ cần thiết, chúng ta giải phóng lock:
void spin_unlock(spinlock_t *lock);

5. Spinlocks and atomic context

Thử tưởng tượng trong lúc driver của bạn đang yêu cầu một spinlock và đang chuẩn bị thực hiện công việc của nó trong miền găng thì ở một nơi nào đó, nó bị mất quyền sử dụng processor.(Có thể nó gọi đến một hàm nào đó khiến processor sleep). Hoặc trong hệ thống SMP, kernel gạt tác vụ hiện tại ra khỏi processor để dành chỗ cho một tác vụ khác có độ ưu tiên cao hơn. Vấn đề là, hiện tại code của bạn hiện tại đang giữ lock, và nó sẽ không được giải phóng tại bất kỳ thời điểm có thể dự báo trong tương lai. Nếu một số thread khác cố gắng lấy cùng lock đó, nó sẽ đợi thời gian rất dài. Trong trường hợp tệ nhất, toàn hệ thống có thể rơi vào deadlock.

May mắn là, spinlock có thể xử lý trường hợp kernel preemption bởi chính nó. Mỗi khi task nắm giữ một spinlock. preemption sẽ bị vô hiệu hóa trên processor liên quan. Kể cả đối với hệ thống đơn tiến trình, preemption cũng cần được vô hiệu hóa theo cách này để tránh vi phạm các nguyên tắc của miền găng. (Do đó spinlock cần sử dụng một cách chính xác nếu không hiệu năng hệ thống sẽ bị giảm kinh khủng).

Tuy nhiên, việc tránh cho process sleep trong khi đang giữ lock là một điều khó khăn hơn nhiều; nhiều kernel functions có thể sleep, và điều này không phải lúc nào cũng được ghi chép một cách rõ ràng trong tài liệu. Do đó khi sử dụng spinlock, cần phải quan tâm đến tất cả function liên quan trong code của bạn.

Mặc dù spinlock có thể được sử dụng trong các hàm xử lý ngắt, tuy nhiên, trong những trường hợp này, code của bạn phải vô hiệu hóa interrupt trên processor hiện tại trước khi gọi yêu cầu sở hữu spinlock, nếu không làm như vậy, có thể xảy ra trường hợp một interrupt khác xảy ra trong lúc code của bạn đang xử lý với tài nguyên dùng chung, lúc này hàm xử lý ngắt thứ hai cũng sẽ yêu cầu spinlock từ kernel, tuy nhiên do hàm xử lý ngắt đầu tiên đang nắm giữ nó nên hàm thứ hai này sẽ phải chờ đợi. Tuy nhiên, do hàm xử lý đầu tiên đã bị hàm thứ hai dành mất Processor nên nó sẽ không bao giờ giải phóng spinlock đang nắm giữ, và gây ra deadlock trong hệ thống.

Luật lệ quan trọng cuối cùng trong việc sử dụng spinlock là spinlocks phải luôn luôn được giữ trong khoảng thời gian ngắn nhất có thể. Spinlock bị giữ càng lâu, thì processor đợi spinlock sẽ bị block càng lâu, và nguy cơ các processor này rơi vào spinning khác càng nhiều hơn. Thời gian giữ lock dài cũng khiến processor đứng trong scheduler lâu hơn, điều này khiến cho process khác có priority cao hơn phải đợi lâu hơn.

Một driver được viết tệ hại có thể khiến tất cả các process phải ngồi đợi lock quá lâu => Performance giảm tụt quần

6. Spinlock Functions.

a. Các function có thể lock một spinlock Spinock api cung cấp khá nhiều hàm lock để sử dụng trong các ngữ cảnh khách nhau

void spin_lock(spinlock_t *lock); //Đã nói ở phần trên
void spin_lock_irqsave(spinlock_t *lock, unsigned long flags);Hàm này sử dụng khi bạn cần lock giữa HARD IRQ và bottom half
void spin_lock_irq(spinlock_t *lock)
Giống hàm trên nhưng nó không lưu lại trạng thái của interrupt mà sẽ luôn enable interrupts khi code giải phóng spinlock.
void spin_lock_bh(spinlock_t *lock);
Sử dụng khi cần tạo lock giữa Process context và Bottom half interrupt. Hàm này vô hiệu hóa software interrupts trước khi obtain lock, nhưng vẫn để hardware interrupts hoạt động.
b. Tương ứng với các hàm trên chúng ta có 4 hàm để unlock một spinlock
void spin_unlock(spinlock_t *lock);
void spin_unlock_restore(spinlock_t *lock, unsigned log flags);
void spin_unlock_irq(spinlock_t *lock);
void spin_unlock_bh(spinlock_t *lock);

no blocking version

int spin_trylock(spinlock_t *lock);
int spin_trylock_bh(spinlock_t *lock);

7. Practice make perfect

Bây giờ đến phần ví dụ, phần này sẽ dùng lại device driver đã viết trong bài Character device, và thêm phần xử lý miền găng vào. Nhưng trước hết, hãy viết một user-program để việc test được dễ dàng và rõ ràng hơn. Tạo một file code mới có tên là: oni_test_app.c

#include<stdio.h>
#include<stdlib.h>
#include<errno.h>
#include<fcntl.h>
#include<string.h>
#include<unistd.h>
 
#define BUFFER_LENGTH 256               ///< The buffer length (crude but fine)
static char receive[BUFFER_LENGTH];     ///< The receive buffer from the LKM
 
int main(){
   int ret, fd;
   char stringToSend[BUFFER_LENGTH];
   printf("Starting device test code example...\n");
   fd = open("/dev/oni_chrdev", O_RDWR);             // Open the device with read/write access
   if (fd < 0){
      perror("Failed to open the device...");
      return errno;
   }
   printf("Type in a short string to send to the kernel module:\n");
   scanf("%[^\n]%*c", stringToSend);                // Read in a string (with spaces)
   printf("Writing message to the device [%s].\n", stringToSend);
   ret = write(fd, stringToSend, strlen(stringToSend)); // Send the string to the LKM
   if (ret < 0){
      perror("Failed to write the message to the device.");
      return errno;
   }
 
   printf("Press ENTER to read back from the device...\n");
   getchar();
 
   printf("Reading from the device...\n");
   ret = read(fd, receive, BUFFER_LENGTH);        // Read the response from the LKM
   if (ret < 0){
      perror("Failed to read the message from the device.");
      return errno;
   }
   printf("The received message is: [%s]\n", receive);
   printf("End of the program\n");
   return 0;
}

Compile file test vừa tạo bằng command sau:

$gcc oni_chrdev_test.c -o test

Bây giờ insert module vào kernel và chạy thử file test bằng quyền sudo, thực hiện các bước theo chỉ dẫn in ra, nhận được kết quả như sau:

$ sudo ./test
$ Starting device test code example...
$ Type in a short string to send to the kernel module"
$ Linux kernel
$ Writing message to the device [Linux kernel]
$ Press ENTER to read back from the device...
$ Reading from the device...
$ The received message is: [nguyen phi]
$ End of the program

Giải thích: khi chạy file test, nó sẽ yêu cầu nhập vào một string ngắn từ bàn phím, string này sẽ được lưu copy vào kernel space và lưu ở biến msg của module. Sau đó, khi người dùng ấn Enter, giá trị của msg sẽ được copy ngược lại ra user-app và in ra màn hình.
Bây giờ hãy thử một bài test để chứng tỏ tính không đồng bộ của device driver hiện tại:
-Mở 2 tab terminal và chạy sudo ./test ở cả 2 tab.
-Ở tab đầu tiên, nhập vào chuỗi “Temp1”, rồi để nó ở đấy, tức là chương trình đã ghi chuỗi “Temp1” vào device.
-Ở tab 2, nhập vào chuỗi “Temp2”, sau đó gõ enter để đọc, thì chương trình sẽ in ra The received message is: Temp2
-Quay lại tab đầu tiên, bây giờ gõ Enter, thì màn hình sẽ in ra The received message is: Temp2. Tức là thay vì in ra chuỗi “Temp1” thì nó lại in ra “Temp2”
. Lý do là vì cả 2 chương trình test đều dùng chung resource là device file oni_chrdev. Chương trình 2 chạy sau, nên hàm write của nó đã overwrite giá trị biến msg. Sau đó khi p2 thực hiện hàm read, nó cũng xóa luôn msg, nên p1 thực hiện hàm read sau sẽ chỉ đọc được một chuỗi rỗng, ngược lại nếu thực hiện read của p1 trước p2, thì giá trị in ra cũng là [Temp2] chứ không phải [Temp1] như mong đợi.

Để giải quyết vấn đề này, chúng ta sẽ chỉ cho phép một instance của device file (fd) được mở tại cùng 1 thời điểm. Mình sẽ khai báo một mutex và lock nó ở hàm open và unlock ở hàm release. Đầu tiên phải thêm header chứa mutex vào và định nghĩa 1 mutex để sử dụng:

#include <linux/mutex.h>
........
static DEFINE_MUTEX(oni_mutex);

Bây giờ cần sửa hàm oni_open, hiện tại hàm này đang không làm gì cả. Hàm này sẽ kiểm tra xem mutex có đang vô chủ không, nếu có thì không cần làm gì cả, ngược lại, nó sẽ return lỗi device file đang bận và không cho phép user-app mở device file.

static int oni_open(struct inode* node, struct file *filp)
{
	if(!mutex_trylock(&oni_mutex))
	{
		printk(KERN_ALERT "Oni chardev: Device in use by another process");
		return -EBUSY;
	}
	return 0;
}

Đến đây, nếu một process “P1” dành được mutex, nó sẽ mở được device file, nhưng các process khác sẽ không bao giờ động đến device file được, kể cả khi P1 đã đóng device file, vì hiện tại, mình chưa tạo đoạn code giải phóng mutex. Để làm điều này, mình sửa hàm oni_release như sau:

static int oni_open(struct inode* node, struct file *filp)
{
	mutex_unlock(&oni_mutex);
	return 0;
}

Compile lại device driver và insert nó vào kernel. Mở 2 tab terminal. Ở tab đầu tiên chạy 1 process test:
sudo ./test Kết quả hiện ra như sau:

Starting device test code example...
Type in a short string to send to the kernel module:

Mở tiếp 1 process khác ở tab thứ 2: sudo ./test. Kết quả hiện ra như sau:

Starting device test code example...
Failed to open the device ...: Device or resource busy.

Như vậy, với việc thêm Mutex vào hàm open và release, bây giờ chỉ có 1 fd có thể được mở tại cùng một thời điểm.

Tiếp theo, thay vì dùng Mutex, hãy thử dùng spinlock. Thay header linux/mutex.h bằng linux/spinlock.h>. Cũng giống như Mutex, để dùng được spinlock, ta cần định nghĩa nó trước thay dòng DEFINE_MUTEX(oni_mutex> bằng DEFINE_SPINLOCK(my_lock); Sửa nội dung hàm open và release thành như sau:

static int oni_open(struct inode* node, struct file *filp)
{
	spin_lock(&my_lock);
	return 0;
}

static int oni_open(struct inode* node, struct file *filp)
{
	spin_lock(&my_lock);
	return 0;
}

Với code này, khi mở một process test thứ 2, nó sẽ phải đợi (spin) đến khi process đầu tiên đóng device file thì nó mới được mở device file để thực hiện các tác vụ.

Mutex Complitions Spinlock was originally published by Nguyễn Đình Phi at Oni Ranger on January 15, 2018.

Character Device

2017-12-18T00:00:00+08:00

Character Device Driver.

Character Device (chardev) là các device được truy cập như một luồng nhị phân (byte stream - tương tự như các file trong máy tính), và character device driver có nhiệm vụ thực hiện những thao tác đọc ghi này. Đối với một character device driver, ít nhất 4 system call: open, close read và write cần được implement để chardev có thể hoạt động một cách bình thường.

Một số ví dụ về character device là: Serial console và console.

Do Linux về cơ bản là file, file và file nên các character device cũng không phải là ngoại lệ, chúng được truy cập bằng các file system node (trong /dev directory). Tuy nhiên, không giống như các file thông thường khác (có thể truy cập tiến, lùi tùy ý), các file dev này chỉ được truy cập theo một cách tuần tự.

Khi dùng command ls -l /dev, các device file được liệt kê, các file có chữ c ở đầu là các device file của chardev.

crw-r--r--    1 root     root        5,   1 Dec 27 03:45 console
crw-rw-rw-    1 root     root        1,   7 Jan  1  1970 full
crw-r--r--    1 root     root       10, 229 Dec 27 03:06 fuse
crw-r--r--    1 root     root        1,  11 Jan  1  1970 kmsg
crw-r--r--    1 root     root        1,   1 Jan  1  1970 mem
brw-r--r--    1 root     root       31,   0 Jan  1  1970 mtdblock0
brw-r--r--    1 root     root       31,   1 Jan  1  1970 mtdblock1
brw-r--r--    1 root     root       31,   2 Jan  1  1970 mtdblock2
brw-r--r--    1 root     root       31,   3 Jan  1  1970 mtdblock3
brw-r--r--    1 root     root       31,   4 Jan  1  1970 mtdblock4
brw-r--r--    1 root     root       31,   5 Jan  1  1970 mtdblock5
brw-r--r--    1 root     root       31,   6 Jan  1  1970 mtdblock6
brw-r--r--    1 root     root       31,   7 Jan  1  1970 mtdblock7
crw-rw-rw-    1 root     root        1,   3 Jan  1  1970 null
crw-r--r--    1 root     root        1,   4 Jan  1  1970 port
crw-------    1 root     root      108,   0 Dec 27 03:06 ppp
crw-rw-rw-    1 root     root        5,   2 Dec 27 04:32 ptmx
drwxr-xr-x    2 root     root             0 Jan  1  1970 pts
crw-r--r--    1 root     root        1,   8 Jan  1  1970 random
drwxr-xr-x    2 root     root            40 Jan  1  1970 shm
crw-r--r--    1 root     root       10, 254 Dec 27 03:06 switch_ssdk
crw-rw-rw-    1 root     root        5,   0 Jan  1  1970 tty
crw-------    1 root     root        4,  64 Dec 27 03:45 ttyS0
crw-r--r--    1 root     root        1,   9 Jan  1  1970 urandom
crw-r--r--    1 root     root       10, 130 Dec 27 03:06 watchdog
crw-rw-rw-    1 root     root        1,   5 Jan  1  1970 zero

1. Major number và Minor number - Định danh của device.

Như có thể thấy ở trên, hầu hết các device trong Linux là chardev. Ngoài ra, có thể để ý thấy, mỗi device file thường có 2 số được phân tách bởi dấu phẩy đi kèm nhau, ví dụ: với device ttyS0 hai số này là 4 và 64. Hai số này được gọi là Major và Minor, chúng được dùng để định danh device trong một rừng cái device của hệ thống. Major number (số trước dấu phẩy): Dùng để xác định driver nào sẽ liên kết với thiết bị, ví dụ ttyS0 sẽ được điều khiển bời driver 4, trong khi các mtd device được điều khiển bởi driver 31. Minor number (số sau dấu phẩy): Cũng ở ví dụ trên, ta có thể thấy 8 mtd device có chung một major number, nhưng minor number khác nhau, tức là Minor number được sử dụng để phân biệt các device sử dụng chung một driver.

Trong kernel, có sử dụng một kiểu biến là dev_t (linux/types.h), kiểu này đượuc dùng để lưu dữ các device numbers(major và minor), nói cách khác, các device trong kernel được phân biệt bằng các biến có kiểu này. dev_t có kích thước là 32-bit, với 12 bit dùng cho Major number và 20 bit còn lại cho minor number, lưu ý là thứ tự của 2 phần này không được chỉ rõ, nên tốt nhất chúng ta không nên tự xác định major và minor bằng tay từ device number, thay vào đó, kernel source cung cấp cho chúng ta 2 macro để làm việc này là: MAJOR(dev_t dev) và MINOR(dev_t dev). Cả hai Macro này đều được định nghĩa trong (linux/kdev_t.h). Tương tự, nếu như chúng ta đã biết major và minor của một device, chúng ta có thể tìm ra device number của nó bằng Macro: MKDEV(int major, int minor)

2. Các cấu trúc dữ liệu quan trọng.

Hầu hết các tác vụ cơ bản của driver gọi đến 3 kernel data structure quan trọng, đó là: file_operations, file và inode.

2.1. File Operations - fops

(linux/fs.h) file_operations file operation structure giúp kết nối các tác vụ của driver với các device number. Mỗi file đang mở (biểu diễn bởi file structure) được liên kết với một tập các function (f_op). Các function này sẽ thực hiện các tác vụ của driver. Nói theo ngôn ngữ OOP thì các file là các Object còn các funtion thực hiện trên file là các method của nó. Mỗi trường trong file operation structure phải trỏ đến một function được định nghĩa bởi driver, function này thực hiện một tác vụ cụ thể. Nếu một trường nào đó là NULL thì có nghĩa là tác vụ đấy không được hỗ trợ. Mỗi tác vụ này sẽ có các hàm system call tương ứng để có thể gọi đến từ user space. struct file_operations có rất nhiều trường khác nhau nhưng về cơ bản chỉ cần quan tâm đến một số hàm và thuộc tính thường dùng bao sau:

struct module *owner; /* Đây là trường đầu tiên của fops struct, nó không phải là một tác vụ mà là một con trỏ trỏ đến module sử hữu structure này. Tác dụng: Ngăn chặn việc unload module khi các tác vụ của nó chưa hoàn thành. Thông thường nó được khởi tọa bằng giá trị THIS_MODULE (linux/modules.h) */

int (*open) (struct file*, struct file *); /* - Đây là tác vụ được thực hiện đầu tiên của device file. - Có thể có hoặc không. - Nếu không có thì return value luôn là true. */

int (*release) (struct inode *, struct file *); /* Có open thì phải có release thôi. */

loff_t (*llseek) (struct file *, loff_t, int); /* Được sử dụng để thay đổi vị trí đọc/ghi hiện tại ở trong file. (seek/fseek function in C) Return value: vị trí vừa mới chuyển tới, hoạc giá trị âm nếu thao tác lỗi. Nếu function pointer là NULL, thì seek call sẽ sửa vị trí hiện tại trong file struct theo cách không xác định được. */

ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); /* Được sử dụng để lấy dữ liệu từ device. Return value: số lượng bytes đã đọc thành công. NULL pointer: read system call sẽ trả về -EINVAL error. */

ssize_t (*write) (struct file*, const char __user *, size_t, loff_t *); /* Ngược lại với hàm read. */

unsigned int (*ioctl) (struct inode *, struct file *, unsigned int, usigned long); /* ioctl system call cung cấp một phương thức để tạo ra các câu lệnh cho các device cụ thể. Nếu ioctl không được implement thì sẽ báo lỗi "No such ioctl for device". */

2.2. File Struct - filp

Where is it? => linux/fs.h File struct đại diện cho một open file (file đang mở). (mọi open file trong hệ thống đều có một struct file tương ứng trong kernel space). Thời gian tồn tại của nó là từ lúc open() call đến lúc close() call, trong suốt thời gian đó, nó được truyển cho mọi function có thao tác trên file. Sau đây là những trường quan trọng nhất của cấu trúc này.

mode_t f_mode; /* FMODE_READ|FMODE_WRITE - readable|writeable. */

loff_t fpos; /* - VỊ trí đọc/ghi hiện tại. - Driver có thể kiểm tra giá trị của fpos, nhưng không nên thay đổi nó một cách thông thường, thay vào đó, nó được thay đổi bởi read() và write() */

unsiged int f_flags; /* File flags: O_RDONLY, O_NONBLOCK, O_SYNC. Các flag này được định nghĩa trong linux/fcntl.h */

struct file_operation *f_op; /* - Các tác vụ gắn với file. - Do kernel không lưu lại f_op cho các lần tham chiếu sau đấy, nên chúng ta có thể thay đổi file_operation gắn với file bất cứ lúc nào và điều này sẽ gây ảnh hưởng ngay lập tức. */

void *private_data; /* - Trước khi gọi system call open(), đây là một con trỏ NULL. - Có thể dùng hoặc không dùng đều được. - Dùng để lưu giữ các thông tin cố định thông suốt quá trình sử dụng của device. - Cần giải phóng ở hàm release() / struct dentry *f_dentry; / - Directory entry gắn với file. */

2.2. inode struct

Master file table entries
Các đối tượng inode biểu diễn tất các thông tin mà Kernel cần để thực hiện việc thay đổi một file hay thư mục.
Đối với các File system có lưu các Inode on-disk thì kernel sẽ đơn giản là đọc các thông tin này từ các đối tượng Inode được lưu trong ổ đĩa. Tuy nhiên đối với các File system không lưu các inode trên đĩa thì kernel sẽ phải trích xuất các thông tin này từ file.
Inode object được khởi tạo trong bộ nhớ chính mỗi khi file được truy cập.
Struct file là đại diện cho descriptor của các file đang mở (fd), do đó với mỗi file trong hệ thống, có thể có nhiều fd nhưng chỉ có duy nhát một inode.
Inode chứa một số thông tin hữu ích đối với một character device, tiêu biểu là:

dev_t i_rdev; /* Chứa device number; */

struct cdev *i_cdev; /* cdev là cấu trúc biểu diễn char devices; */

3. Thử lập trình một Character device driver (Incomplete)

Bây giờ mình sẽ thử tạo một character device driver đơn giản tên là oni_chardev, driver này không có giao tiếp gì với phần cứng cả, chỉ là một ví dụ để hiểu hơn về cách viết character device driver thôi. Trong device này sẽ lưu lại một string được nhập vào bởi user-app, và in ra nếu user-app yêu cầu.

3.1 Khai báo các cấu trúc dữ liệu cần thiết.

Đầu tiên chúng ta khai báo các hằng số cần thiết cho việc đăng ký device number:

#define MINOR_FIRST 0
#define MINOR_COUNT 1
#define DEV_NAME "oni_chrdev"
#define BUFFER_SIZE 256

Device của chúng ta sẽ alloc minor bắt đầu tư 0, với tối đa là 1 minor.
Tiếp theo là các cấu trúc mà mọi cdd đều có, về cơ bản chúng ta sẽ khai báo như sau.:

static struct cdev oni_cdev;
static struct class *oni_class;
static struct class *oni_device;
static size_t size_of_msg=0;

Một biến kiểu dev_t để lưu giữ device number mà device được cấp phát.

static dev_t oni_device_number;

Tiếp theo là cho khai báo các signature của các function được sử dụng bởi file_operations:

	static int oni_open(struct inode *, struct file *);
	static int oni_release(struct inode *, struct file *);
	static ssize_t oni_write(struct file *, const char __user *, size_t count, loff_t *pos);
	static ssize_t oni_read(struct file *, char __user *, size_t count, loff_t *pos);

Sau khi đã khai báo các signature thì chúng ta sẽ định nghĩa file operation được sử dụng bởi device.

struct file_operations oni_fops
{
	.owner = THIS_MODULE,
	.open = oni_open,
	.release = oni_release,
	.write = oni_write,
	.read = oni_read
};

Cuối cùng là biến để lưu giữ chuỗi ký tự:

char msg[BUFFER_SIZE];

3.2 Đăng ký device driver với kernel.

Việc đầu tiên khi một device driver được insert vào kernel là kernel sẽ gọi đến hàm init của nó. Hàm init sẽ thực hiện việc đăng ký device number, khởi tạo và đăng ký cấu trúc cdev với kernel, ngoài ra nó cũng có thể đăng ký class và device file cho device. Nếu một device không có device file thì user-app không giao tiếp đọc ghi với nó được(đoán thế), tuy nhiên, linux không yêu cầu chúng ta tạo device file khi init module, thay vào đó, chúng ta có thể tạo ra device file sau bằng command mknod. Trong ví dụ này, mình sẽ tạo luôn device file trong hàm init.
Đầu tiên chúng ta cần có một device number cho device của chúng ta. Ở đây, có thể dùng macro MKDEV() nếu như chúng ta đã xác định sẵn một major number cho device, sao cho nó không trùng với major number của các device khác trong hệ thống, mặc nhiên là cách này chỉ dùng được khi device driver của chúng ta chỉ dùng cho một hệ thống cá nhân của riêng mình. Trong các hệ thống public, có nhiều người sử dụng thì chúng ta không thể biết được liệu người dùng có thêm vào hệ thống một device nào khác có major number giống của chúng ta hay không. Do đó chúng ta sẽ sử dụng phương pháp cấp phát động cho device number, phương pháp này, kernel sẽ cung cấp một major number chưa có ai sử dụng cho device của chúng ta. (thật ra là của tui, nhưng mà viết chúng ta cho nó có vần thôi).

int ret; 
ret = alloc_chrdev_region(&oni_device_number, MINOR_FIRST, MINOR_COUNT,DEV_NAME);
if( ret != 0 )
{
	printk(KERN_WARNING "Cannot allocate a device number");
	return ret;
}

Trên đây, chúng ta đã đăng ký một device number có major động và minor number từ 0 đến 0. Biến ret sẽ dùng để lưu giá trị trả về của hàm alloc, nếu ret âm thì tức là có lỗi, lúc này chúng ta sẽ return ngay tắp lự.

Khi đã có được device number, chúng ta sẽ khởi tạo cấu trúc cdev với hàm cdev_init cdev_init(&oni_dev, &oni_fops); Với dòng code này, chúng ta đã khởi tạo cấu trúc oni_dev và ghi nhớ oni_fops, sẵn sàng cho việc sử dụng sau này.
Tiếp theo là thông báo với kernel về sự hiện diện của chúng ta.

ret = cdev_add(&oni_dev, oni_device_number, MINOR_COUNT);
if( ret != 0 )
{
	unregister_chrdev_region(oni_device_number, MINOR_COUNT);
	printk(KERN_WARNING "Cannot add device to kernel");
	return ret;
}

Dòng này dùng để thêm device được biểu diễn bởi biến oni_dev (chính là device này đây) vào kernel, cũng gần như ngay lập tức, make device live. Nếu như lời gọi hàm thực hiện không thành công thì chúng ta kết thúc quá trình khởi tạo device, đồng thời giải phóng device number đang nắm giữ.
Thật ra, chỉ cần như này là device driver đã có thể được insert vào hệ thống với insmod rồi, tuy nhiên chúng ta sẽ tạo class và device file cho nó trong hàm init này luôn.

oni_class = class_create(THIS_MODULE, DEV_NAME);
if (IS_ERR(oni_class))
{
	cdev_del(&oni_cdev);
	unregister_chrdev_region(oni_device_number, MINOR_COUNT);
	printk(KERN_WARNING "Cannot create class");
	return PTR_ERR(oni_class);
}

Hàm class_create trả về một con trỏ struct class. Vậy class là gì? Cái này không phải class (lớp) trong java hay C++. Cái này tạm gọi là class device.
Các device trong kernel được chia thành nhiều class. Các device trong cùng 1 class thường có chung một chức năng chính. Bạn có thể xem các class hiện có ở dir: /sys/class

Đối với char device, chúng ta có thể tạo device file bằng cách sau:

oni_device = device_create(oni_class, NULL, oni_device_number, NULL, DEV_NAME);
if (IS_ERR(oni_device))
{
	class_destroy(oni_class);
	cdev_del(&oni_cdev);
	unregister_chrdev_region(oni_device_number, MINOR_COUNT);
	printk(KERN_WARNING "Cannot create device file");
	return PTR_ERR(oni_device);
}

Bằng đoạn code này, kernel sẽ tạo ra file /dev/oni_chrdev, và các user-app có thể giao tiếp với device thông qua file này. Đến đây chúng ta hoàn thành hàm init rồi hí hí.

	pr_info( "Initialized device driver");
	return 0;

Vì hàm exit hiện tại không có nhiều việc để làm nên sẽ nói luôn ở đây:

void __exit oni_exit(void)
{
	device_destroy(oni_class, oni_device_number);
	class_destroy(oni_class);
	cdev_del(&oni_cdev);
	unregister_chrdev_region(oni_device_number, MINOR_COUNT);
}

3.3 Các hàm của cấu trúc file_operations

a. open and release

open(): thực hiện các khởi tạo cơ bản để giúp các tác vụ khác có thể hoạt động sau đó. Thông thường, hàm open() sẽ thực hiện các nhiệm vụ sau:

Kiểm tra xem device đã sẵn sàng chưa? Hardware có vấn đề gì không?….
Khởi tạo device nếu nó được mở lần đầu.
Cập nhật f_op nếu cần tiếp.
Cấp phát và gán các thông tin cần thiết vào filp->private_data.

Tuy nhiên, Mục tiêu hàng đầu là xác định xem device nào sẽ được mở (tức là cái file device nào ấy).
Hiện tại chúng ta chưa cần đến hàm này, nên chỉ cần định nghĩa 1 hàm thân rỗng là được.

release(): Hàm này dùng để phá hoại hết những gì đã làm trong hàm open. Đầu tiên là phải thu deallocate filp->private_data. Poweroff device trong lần dùng cuối. trong scull hàm này không làm gì cả vì không có gì để giải phóng hay power off hết. Trong kernel, có một counter dùng để đếm xem một file structure có bao nhiêu đối tượng đang sử dụng nó. Khi counter bằng này có giá trị bằng 0 thì đó được xem là lần sử dụng cuối của device và nó sẽ bị poweroff. Ngoài ra counter cũng đảm bảo là mỗi lời gọi đến open() sẽ chỉ có một lời gọi đến release() đi kèm (tránh release 1 file 2 lần).
Hiện tại chúng ta chưa cần đến hàm này, nên chỉ cần định nghĩa 1 hàm thân rỗng là được.

b. read and write

ssize_t read(struct file *filp, char __user *buff, ssize_t count, loff_t *offp); ssize_t write(struct file *filp, const char __user *buff, ssize_t count, loff_t *offp); Hàm này sẽ gửi một buffer có kích thước count bytes tới user space bắt đầu tự vị trí offp của file. Do buff là user-space pointer nên nó không thể được truy vấn một cách trực tiếp từ kernel code, sau đây là một số hạn chế:

Phụ thuộc vào kiến trúc của hệ thống và các cài đặt cấu hình của kernel, user-space pointer có thể là không hợp lệ đối với kernel mode. (Do kernel memory là direct mapping, trong khi ở user-space không phải là direct mapping nên cùng một địa chỉ nhưng vị trí sẽ khác nhau).
User-mem được paged (paging) nên nó không tồn tại lâu dài trong RAM. Việc tham chiếu đến vùng nhớ user-space một cách trực tiếp sẽ gây ra page fault (không phải lúc nào cũng xảy ra nhưng xác suất cao) kể cả nếu pointer trong kernel-space và user-space có cách mapping giống nhau.
Về vấn đề bảo mật, việc tham chiếu trực tiếp đến pointer của user-space cũng không tốt vì nó tạo ra nguy cơ bảo mật cao.

Mặc dù có những hạn chế ở trên, nhưng rõ ràng là chúng ta vẫn cần truy cập đến user-space buffer để người dùng có thể tương tác với device. Kernel cung cấp các hàm để thực hiện điều này một cách an toàn. Những hàm này được định nghĩa trong header linux/uaccess.h. Những hàm này đã sử dụng ma thuật hắc ám của kẻ mà ai cũng biệt là ai để truyền dữ liệu giữa kernel và user space một cách an toàn và im lặng. Trong phần read(), write() chúng ta cần đến phép thuật sau: usigned long copy_to_user(void __user *to, const void *from, usinged long count); usigned long copy_from_user(void __user *to, const void __user *from, usinged long count); Lưu ý là do user-space sử dụng cơ chế paging/swapping nên tại thời điểm bất kỳ, có thể page cần dùng để copy/send data không nằm trong bộ nhớ, do đó cần có thời gian để transfer các page này vào mem, điều này đồng nghĩa với việc các hàm read/write phải sleepable, nên các hàm này sẽ thực hiện một cách đồng thời với các hàm khác của driver.
Hai hàm này không phải là atomic, tức là có thể chỉ một phần khối lượng công việc được hoàn thành. Cụ thể hơn, việc copy sẽ không được thực hiện nếu như user-space pointer không hợp lệ, trường hợp ngược lại, việc copy sẽ được thực hiện, nhưng giả dụ trong lúc đang copy nó phát hiện ra một địa chỉ không hợp lệ, quá trình copy sẽ bị break và phần data chưa copy sẽ không được xử lý, phần đã copy thì vẫn giữ nguyên. Giá trị trả về của các hàm này đều là lượng data đã copy (bytes). [Atomic nghĩ là chỉ có 2 trường hợp: chạy hết thành công, trường hợp 2 là chạy thất bại ở một bước nào đấy thì toàn bộ sẽ bị roll back, giống trong SQL].

Cần update *offp sau khi thực hiện read/write để đảm bảo rằng vị trí hiện tại là đúng.
Nếu thao tác đọc/ghi không thành công thì giá trị trả về là 1 số ÂM. b1. read() Với mỗi giá trị trả về của hàm read(), có một tác động tương ứng lên chương trình (app space) có lời gọi hàm đến nó.
Nếu giá trị trả về bằng với count thì toàn bộ dữ liệu yêu cầu đã được truyền thành công. Đây là trường hợp tối ưu.
Nếu giá trị là dương, nhưng nhỏ hơn count, chỉ một phần của dữ liệu đã được truyền thành công. Điều này có thể xảy ra do một số thế lực hắc ám phụ thuộc vào pháp sư sử dụng nó (device). Trường hợp này thường xảy ra khi user-space program gọi đến read().
Nếu giá trị là 0 thì không có data để truyền đi nữa (chakra cạn kiệt).
Nếu giá trị trả về là 0, thì tức là nó đã bị phong ấn ở đâu đấy.
Trường hợp cá biệt, chakra vẫn còn nhưng bị bakugan phong tỏa huyệt đạo, shinobi sẽ rơi vào trang thái block. Mặc dù ở trên có đề cập việc thay đổi file offset, tuy nhiên ví dụ của chúng ta mong muốn là đọc ghi từ đầu file, nên không cần phải update nó làm gì cả, (cả read và write).

static ssize_t oni_read(struct file *filp, char __user *buffer, size_t count, loff_t *offset)
{
	int err_count = 0;
	err_count = copy_to_user(buffer, msg, size_of_msg);
	if( err_count == 0 )
	{
		pr_info( "Oni Chrdev: Sent %lu chars to the user\n", size_of_msg);
		size_of_msg = 0;
		return 0;
	}else
	{
		pr_info( "Oni Chrdev: Failed to send %d chars to the user\n", err_count);
		return -EFAULT;
	}
}

b2. write() giống read, write có thể truyền ít hơn dữ liệu được yêu cầu, sau đây là các giá trị trả về ở user-space calling tương ứng.

Nếu giá trị trả về bằng count thì toàn bộ các bytes được yêu cầu đã truyền thành công.
Nếu giá trị trả về là giá trị dương lớn hơn count, thì chỉ một phần chakra được truyền từ cửu vĩ sang naruto. Chương trình (user-space) gần như ngay lập tức cố gắng write phần data còn lại.
Nếu giá trị trả về là 0 thì tức là không có ghì để write.
Nếu giá trị trả về là âm thì đã có lỗi.

static ssize_t oni_write(struct file *filp, const char __user *buffer, size_t count, loff_t *offset)
{
	if(copy_from_user(msg, buffer, count))
	{
		return -EACCES;
	}

	size_of_msg = strlen(msg);
	pr_info( "Oni Chrdev: receive %zu charaters for the user: %s\n",count,msg);
	return count;
}

Kernel cung cấp các hàm có cách dùng đơn giản hơn cho việc đọc/ghi dữ liệu từ/tới buffer đó là simple_read_from_buffer() và simple_write_to_buffer(), trong trường hợp chỉ cần đọc/ghi dữ liệu đơn thuần mà không thực hiện các thao tác xử lý phức tạp gì (như ví dụ trong bài này), thì ưu tiên dùng hai hàm này.

File source hoàn chỉnh sẽ như sau:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/version.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/uaccess.h>

#define MINOR_FIRST 0
#define MINOR_COUNT 1
#define DEV_NAME "oni_chrdev"
#define BUFFER_SIZE 256

static struct cdev oni_cdev;
static struct class *oni_class;
static struct device *oni_device;
static size_t size_of_msg=0;
char msg[BUFFER_SIZE]={0};

static dev_t oni_device_number;

static int oni_open(struct inode *, struct file *);
static int oni_release(struct inode *, struct file *);
static ssize_t oni_write(struct file *, const char __user *, size_t count, loff_t *pos);
static ssize_t oni_read(struct file *, char __user *, size_t count, loff_t *pos);

struct file_operations oni_fops=
{
	.owner = THIS_MODULE,
	.open = oni_open,
	.release = oni_release,
	.write = oni_write,
	.read = oni_read
};

static ssize_t oni_read(struct file *filp, char __user *buffer, size_t count, loff_t *offset)
{
	if ((*offset + count) > BUFFER_SIZE)	
		count = BUFFER_SIZE - *offset;

	if (copy_to_user(buffer, msg, count))
	{
		pr_info("Oni Chrdev: Failed to send %d chars to the user\n", err_count);
		return -EFAULT;
	}

	*offset += count;
	pr_info("Oni Chrdev: Number of bytes successfully read = %zu\n", count);
	return count;
}

static ssize_t oni_write(struct file *filp, const char __user *buffer, size_t count, loff_t *offset)
{
	if ((*offset + count) > BUFFER_SIZE)
		count = BUFFER_SIZE - *offset;

	if (!count)
		return -ENOMEM;
	if(copy_from_user(msg, buffer, count))
	{
		return -EFAULT;
	}

	*offset ++ count;
	pr_info( "Oni Chrdev: receive %zu charaters for the user %s\n",count,msg);
	return count;
}

static int oni_open(struct inode *node, struct file *filp)
{
	return 0;
}

static int oni_release(struct inode *node, struct file *filp)
{
	return 0;
}

void __exit oni_exit(void)
{
	device_destroy(oni_class, oni_device_number);
	class_destroy(oni_class);
	cdev_del(&oni_cdev);
	unregister_chrdev_region(oni_device_number, MINOR_COUNT);
}

int __init oni_init(void)
{
	int ret; 
	ret = alloc_chrdev_region(&oni_device_number, MINOR_FIRST, MINOR_COUNT,DEV_NAME);
	if( ret != 0 )
	{
		printk(KERN_WARNING "Cannot allocate a device number");
		return ret;
	}
	cdev_init(&oni_cdev, &oni_fops);	
	ret = cdev_add(&oni_cdev, oni_device_number, MINOR_COUNT);
	if( ret != 0 )
	{
		unregister_chrdev_region(oni_device_number, MINOR_COUNT);
		printk(KERN_WARNING "Cannot add device to kernel");
		return ret;
	}
	
	oni_class = class_create(THIS_MODULE, DEV_NAME);
	if (IS_ERR(oni_class))
	{
		cdev_del(&oni_cdev);
		unregister_chrdev_region(oni_device_number, MINOR_COUNT);
		printk(KERN_WARNING "Cannot create class");
		return PTR_ERR(oni_class);
	}
	
	oni_device = device_create(oni_class, NULL, oni_device_number, NULL, DEV_NAME);
	if (IS_ERR(oni_device))
	{
		class_destroy(oni_class);
		cdev_del(&oni_cdev);
		unregister_chrdev_region(oni_device_number, MINOR_COUNT);
		printk(KERN_WARNING "Cannot create device file");
		return PTR_ERR(oni_device);
	}
	return 0;
}

MODULE_LICENSE("GPL");            ///< The license type -- this affects available functionality
MODULE_AUTHOR("Oni Ranger");    ///< The author -- visible when you use modinfo
MODULE_DESCRIPTION("A simple Linux char driver for explain sleeping");  ///< The description -- see modinfo
MODULE_VERSION("0.1");            ///< A version number to inform users
module_init(oni_init);
module_exit(oni_exit);

Chúng ta cần một file Makefile để compile module vừa viết, make file tương đối đơn giản:

obj-m+=oni_chrdev.o
all:
	make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
clean:
	make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean

3.4 Vọc vạch cái device driver vừa viết.

Bây giờ insert module vào kernel: sudo insmod oni_chardev.ko
Tiếp theo chúng ta ghi một đoạn ký tự vào device: sudo echo "testing">/dev/oni_chardev
Kiểm tra dmesg xem có gì xảy ra
Đọc dữ liệu từ device: cat /dev/oni_chardev

Character Device was originally published by Nguyễn Đình Phi at Oni Ranger on December 18, 2017.

Oni Ranger

Virtual Machine Monitor Kvm

Virtual Machine Monitor với KVM và Rust (update: 2026-09-26)

I. Vài khái niệm cơ bản

Virtualization - ảo hóa

Virtual machine monitor (VMM) và hypervisor

Hypervisor Type 1 và Type 2

Type 1: Bare-metal Hypervisor

Type 2:

KVM

Intel Vtx

KVM API

II. Tự viết VMM bằng Rust.

Bước 1: Lấy file descriptor của KVM handle và khởi tạo VM

Bước 2: Memory cho VM

Bước 3: VCPU cho VM

Bước 4: Bước vào thế giới 64bit.

4.1 Thiết lập Page Table (Identity Mapping)

Cấu trúc Page Table Entry - PTE

Kết quả

4.2 Segment descriptor và GDT

Bước 5: Runnnnn the Guest

III. Boot vmlinux

Linux boot protocol cho x86

Load vmlinux.bin

Xử lý Serial console I/O

Thiết lập các interrupt cần thiết

KVM_SET_TSS_ADDR – Vì sao cần TSS dù đang ở long mode?

KVM_SET_IDENTITY_MAP_ADDR – Cái này để làm gì?

KVM_CREATE_IRQCHIP – Tạo APIC trong kernel

KVM_CREATE_PIT2 –

Thiết lập registers và bắt đầu chạy máy ảo

Testtt

IV. Boot rootfs (busybox) (Đoạn này phần lớn được viết bởi thầy Claude code)

Chuẩn bị rootfs

Load initrd vào memory

Lần chạy đầu tiên: kernel unpack được initramfs, nhưng im lặng khó hiểu

Đi tìm lý do: printk hoạt động, nhưng userspace write() thì không

uart:unknown - driver còn chưa nhận ra có UART

Lần chạy thứ hai: nhận đúng chip, nhưng driver lại kêu “too much work”

Kết quả

References

Sparse Memory Model

Quản lý bộ nhớ vật lý trong Linux kernel (physical memory management)

Sparse memory model - cách kernel lưu physical frame trong hệ thống.

memory section

Truy cập pages trong SPARSEMEMORY model

Quá trình khởi tạo sparse model trên x86_64

Truy cập thông tin từ Sparse model

Node và zone

Mối liên hệ giữa các data struct sử dụng trong quản lý bộ nhớ vật lý.

Virtual File System

Linux Virtual File System

1. Các cấu trúc dữ liệu VFS liên kết với process.

2. Struct file - Đối tượng biểu diễn một opened file, và phương thức process tương tác với file đó.

3. Dentry và path lookup

4. Inode và Super block

Subsection: File system context (kernel 5.4)

Hardware io

1 Memory barriers.

2. Đăng ký I/O ports.

3. Đọc và Ghi Dữ liệu với các I/O register.

Các hàm Đọc I/O Register

Các hàm Ghi I/O Register

4. Cấp phát, Mapping, và sử dụng I/O Memory.

5. Ví dụ I/O memory.

Gpio Subsystem

A. GPIO Subsystem

I. Legacy GPIO interface trong Linux.

1. Giành quyền sử dụng GPIO và cấu hình GPIO.

2. Sử dụng legacy gpio để đọc ghi tín hiệu.

2.1 Trong atomic context.

2.2 Trong non-atomic context.

3. Ví dụ: sử dụng nút Reset đê bật tắt đèn LED trên Router wifi: Compex WPJ563.

II. GPIO interface dựa trên descriptor.

1. Cấp phát và sử dụng descriptor-base GPIO

B. GPIO Controller Driver.

Platform Device

I. Platform Devices và drivers.

1. Platform drivers

`uart:unknown` - driver còn chưa nhận ra có UART