[Kern Meetup Blr] [Talk Proposal] MCTP over MMBI (PCIe Shared-Memory Driver for Multi-Processor Systems)

[Er Krishna]

Hi Team BLR Kernel Meetup,

I've included my Regular Talk (25+5 min) proposal below.


Title:
MCTP over MMBI — Building a PCIe Management Transport using Linux Kernel & QEMU


Abstract:

Modern PCIe systems often pair a host CPU with an embedded processor inside the endpoint device. These two processors need a reliable management channel for tasks like configuration, telemetry, and firmware updates. DMTF defines standards for this — DSP0282 (MMBI) for the shared-memory transport and DSP0284 for MCTP binding over it — but production kernel implementations outside Aspeed and Nuvoton BMC drivers remain limited.

This talk presents a from-scratch Linux kernel driver implementing MCTP over MMBI. The driver registers as an AF_MCTP net_device integrated with net/mctp/, uses shared-memory circular buffers with DSP0282 Table-6 packet headers, and communicates via multi-pair hardware mailbox registers with interrupt status/enable/clear/set semantics. The entire stack was developed pre-silicon using QEMU ivshmem-doorbell across two VMs — a dual-mode codebase that selects the emulation or real-hardware path at probe time. The talk covers driver architecture, AF_MCTP integration details, PCIe memory barrier placement (wmb at the shared-memory-to-CSR boundary, rmb after W1C ACK), and practical lessons from spec compliance debugging.


Outline:

1. Problem & Background (5 min)
   * Why heterogeneous PCIe platforms need a standard management transport
   * The DMTF stack: DSP0236 (MCTP Base), DSP0282 (MMBI), DSP0284 (MCTP-over-MMBI)
   * Existing kernel implementations: Aspeed, Nuvoton — what's available and what gaps remain

2. Design & Implementation (12 min)
   * Host ↔ endpoint processor topology over PCIe
   * BAR mapping: Configuration registers vs shared memory windows
   * OWNER/DISCOVERER roles per DSP0282 — endpoint owns capability descriptor, host discovers
   * Shared memory layout: capability descriptor → head/tail pointer regions → H2A/A2H circular buffers
   * Multi-pair hardware mailbox with per-pair interrupt control registers
   * AF_MCTP net_device: ndo_start_xmit → circular buffer write → mailbox doorbell → IRQ delivery
   * DSP0282 Table-6 packet header encoding and single-writer pointer ownership
   * Memory barriers: wmb() before CSR doorbell writes, rmb() after W1C interrupt ACK

3. QEMU-Based Testing (8 min)
   * QEMU ivshmem-doorbell: shared PCIe device providing common memory + cross-VM interrupts
   * Two-VM setup: VM1 (host-side PCI driver) ↔ ivshmem-server ↔ VM2 (endpoint-side PCI driver)
   * Dual-mode probe: single codebase selects IVSHMEM or real HW at pci_probe() time
   * Validation coverage: protocol state machine, packet flow, error paths — vs gaps requiring real silicon (address translation, DMA coherency, platform interrupt routing)
   * Demo: module load, MCTP address/route configuration, bidirectional packet exchange

4. Q&A (5 min)


Speaker Bio:
Krishna Kumar is a Principal Engineer with ~20 years of experience in Linux kernel, firmware, and system software. His work focuses on PCIe, CXL, and device driver development for complex hardware platforms. He has been building MCTP/MMBI transport implementations and QEMU-based validation methodologies for hardware-independent driver development. He is based in Bengaluru.


This talk is about building and validating a real kernel driver from spec to working system — even before hardware is available.


Thank you,
Krishna Kumar

[CoderDomain Opt]

+1

--
You received this message because you are subscribed to the Google Groups "Kernel Meetup Bangalore" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kernel-meetup-ban...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CAMGjyMvmKCfGXsCR%2BfoeoVcFrXSrJW0UTkzTCT6yaT8JwZh7wQ%40mail.gmail.com.