项目要求全内核级，如何与Xilinx PCIe设备内核级交互？

Alright, let's tackle how to get full kernel-level interaction with your Xilinx PCIe device since you can't use the user态 API for your project. I've worked with similar Xilinx PCIe setups before, so here's a practical, step-by-step approach:

First, dive deep into the open-source kernel driver code you have. Even though it only exposes user态 APIs, the driver must already handle all the low-level PCIe heavy lifting under the hood—things like BAR space mapping, interrupt handling, and the core request/response transaction flow with your FPGA logic.

• Look for functions that directly talk to the hardware: For example, functions that write request data to PCIe registers, read response flags, or handle interrupts when a response is ready. These are your building blocks; you won't need to reinvent the wheel here.
• Pay attention to how the driver initializes the PCIe device (pci_dev structure setup, BAR mapping via pci_iomap(), interrupt registration with request_irq()). You'll need this context for your kernel-level operations.

Since your project requires all operations to stay in kernel space, you have two main paths to extend the existing driver:

Option A: Export Core Functions for Other Kernel Modules #

If your kernel-level logic lives in a separate kernel module (e.g., a custom driver or subsystem), expose the hardware interaction functions from the Xilinx driver using kernel symbol exports:

• Use EXPORT_SYMBOL_GPL() (preferred for GPL-compatible code) or EXPORT_SYMBOL() to make functions like xilinx_pcie_send_request() available to other modules.
• Example snippet from the Xilinx driver:

  int xilinx_pcie_send_request(struct pci_dev *dev, void *req_buf, size_t req_len, void *resp_buf, size_t resp_len) {
      // Existing logic to send request and wait for response
  }
  EXPORT_SYMBOL_GPL(xilinx_pcie_send_request);
  

  Your custom kernel module can then include the driver's header and call this function directly.

Option B: Integrate Kernel-Level Logic Directly into the Driver #

If your workflow can be embedded within the existing driver, add kernel-internal handling:

• Set up a kernel thread or workqueue to handle the request/response cycle automatically (e.g., triggered by timers, interrupts from other devices, or kernel-state changes).
• Use completion variables (struct completion) to safely wait for FPGA responses without blocking interrupt context. For example:

  static struct completion resp_completion;
  
  // Interrupt handler signals when response is ready
  irqreturn_t xilinx_pcie_irq_handler(int irq, void *dev_id) {
      // Check response status
      complete(&resp_completion);
      return IRQ_HANDLED;
  }
  
  // Kernel thread that sends requests
  static int pcie_kernel_worker(void *data) {
      struct pci_dev *dev = data;
      while (!kthread_should_stop()) {
          init_completion(&resp_completion);
          // Send request to FPGA
          xilinx_pcie_write_request(dev, req_data);
          // Wait for response (timeout after 5s)
          wait_for_completion_timeout(&resp_completion, msecs_to_jiffies(5000));
          // Process response
          xilinx_pcie_read_response(dev, resp_data);
          // Sleep before next request if needed
          set_current_state(TASK_INTERRUPTIBLE);
          schedule_timeout(msecs_to_jiffies(1000));
      }
      return 0;
  }
  

Kernel-space code has strict rules—don't skip these:

• Synchronization: Use spinlocks for interrupt context operations and mutexes for process context to avoid race conditions when accessing shared hardware registers or data structures.
• DMA Safety: If your device uses DMA for large request/response buffers, use kernel DMA APIs like dma_alloc_coherent() or dma_map_single() to ensure safe data transfer between kernel memory and the FPGA. Never access user-space memory directly from kernel context.
• Error Handling: Always check return values from PCIe and kernel APIs (e.g., pci_iomap(), request_irq()). Gracefully handle failures to avoid kernel panics or device hangs.

• Use printk() for kernel debugging: Log key steps (request sent, response received, error codes) and check the output with dmesg or journalctl.
• Add sysfs entries (optional): Even though your logic is kernel-level, sysfs can be a handy way to trigger test requests or read response status from user space for validation. For example, a writeable sysfs attribute that triggers a request when written to.

• Don't block in interrupt context: If you need to wait for a response, use completion variables or workqueues instead of busy-waiting.
• Respect power management: Ensure your kernel logic doesn't interfere with the device's power states. Use pci_enable_device() and pci_disable_device() correctly, and handle suspend/resume events if your system uses them.

内容的提问来源于stack exchange，提问作者Talgat