Add E1000 network driver and TCP/IP stack foundation #55
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Log all PCI devices discovered during bus enumeration with vendor/device IDs, class codes, and interrupt assignments - Add VirtIO network device ID constants (legacy 0x1000, modern 0x1041) - Add is_virtio_net() and is_network() helper methods to PCI Device - Add find_network_devices() and find_virtio_net_devices() lookup functions - Add vendor_name() helper for common PCI vendors (Intel, AMD, NVIDIA, etc.) - Highlight network controllers in PCI output for easy identification - Update boot-stages marker to match new PCI log format The QEMU environment provides an Intel 82540EM (e1000) NIC at 00:03.0 which is now properly detected and reported during boot. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add a complete driver for the Intel 82540EM Gigabit Ethernet controller, which is the default NIC emulated by QEMU. Driver features: - Device detection via PCI bus enumeration (vendor 8086, device 100e) - MMIO register access with proper page table mappings - MAC address reading from EEPROM - RX/TX descriptor ring initialization (32 descriptors each) - Receive and transmit packet APIs - Link status detection (reports 1000 Mbps on QEMU) - Interrupt handling infrastructure (not yet wired to IRQ) Memory subsystem additions: - map_mmio() function to map device MMIO regions into kernel space - PhysAddrWrapper for virtual-to-physical address translation - MMIO region allocation starting at 0xffffe00000000000 Boot output shows successful initialization: E1000: Found device at 00:03.0 IRQ=11 E1000: MMIO at 0x81040000 size 0x20000 E1000: MAC address 52:54:00:12:34:56 E1000: Link up at 1000 Mbps References: - Intel PCI/PCI-X Family of Gigabit Ethernet Controllers SDM - OSDev Wiki: https://wiki.osdev.org/Intel_8254x 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Implements a minimal network stack for Breenix with full host-visible networking via socket_vmnet on macOS: Network Stack: - Ethernet frame parsing and construction - ARP for IPv4 address resolution with cache - IPv4 packet handling with checksum - ICMP echo request/reply (ping) E1000 Driver Improvements: - Fix TX timeout caused by incorrect virt-to-phys translation for heap - Add proper MMIO register access helpers - Improve RX/TX descriptor ring handling QEMU Networking Modes: - slirp: Default user-mode NAT (10.0.2.x, no host visibility) - socket_vmnet: Host-visible via daemon (192.168.105.x on bridge102) - vmnet: Direct vmnet-shared (requires sudo) - Configurable via BREENIX_NET_MODE environment variable Boot Stage Tests: - E1000 network device found - E1000 driver initialized - Network stack initialized - ARP request sent successfully 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- E1000 TX: Add core::mem::forget() on success path to prevent deallocation while hardware still holds DMA address - IPv4: Change PACKET_ID from static mut to AtomicU16 to fix data race - syscall_diagnostic_test: Declare rcx/r11 clobbers on int 0x80 wrappers - fixes counter corruption showing "7/5 tests passed" 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
TX Buffer Management: - Pre-allocate TX_RING_SIZE (32) buffers at driver init - Reuse buffers cyclically instead of Box::new() + forget() per packet - Memory bounded at 32 × 1518 = ~48KB (was unbounded leak) True End-to-End Network Tests: - Add boot stage for ARP reply received (not just sent) - Add boot stage for ICMP echo reply received (not just sent) - Tests require actual bidirectional network communication - Markers only print when real packets received from gateway - Impossible to pass without working network stack 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
BREENIX_NET_MODEenv var (slirp, vmnet, socket_vmnet, none) - socket_vmnet enables host-visible networking on macOS without sudoBug Fixes (from code review)
core::mem::forget()on success path to prevent deallocation while hardware holds DMA addressstatic mut PACKET_IDtoAtomicU16rcx/r11clobbers onint 0x80wrappers in test - fixed counter corruptionTest plan
🤖 Generated with Claude Code