[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Modern Network Interface Card emulation

From: Frantisek Rysanek
Subject: Re: [Qemu-discuss] Modern Network Interface Card emulation
Date: Fri, 18 Dec 2015 11:17:26 +0100

Just a couple notes...

The e1000 is a whole family of Intel Gb Ethernet chips with a pretty 
long tradition, especially if you include the preceding 100Mb line by 
Intel. The 1Gb family enjoys a great deal of software compatibility 
across the family - yet there has been some development over the 
years that brought about significant new feature additions to the 
hardware. As a result, there are nowadays three or four "Intel 
gigabit driver strains" in Linux: 
e1000 = the original i8254x series for the PCI/PCI-X (parallel PCI)
e1000e = the basic PCI-e generation (forked from e1000 after some 
time when the early PCI-e hardware was supported by e1000)
igb = PCI-e hardware with support for VT-d (host side)
igbvf = PCI-e hardware's virtual function (guest side, it would 
In some operating systems, I guess they still share a single driver 
binary... not in Windows I guess - there's a single installer, 
containing multiple flavours of the driver binary.

Note that already the early PCI-based e1000 supported Message 
Signaled Interrupts. They were one of the first hardware with MSI
shining boldly at you in Linux /proc/interrupts, deep back in the XP 
era, before PCI-e, before Microsoft started to support MSI in Vista.

As for the emulation bit in Qemu: the emulated e1000 NIC hardware 
should be just about good enough for use in a virty guest 
environment, for basic undemanding use.
Not sure how long it will be supported in OS'es considered for the
guest environment, but I guess the driver is still present in Windows 
10, and will likely be present in Linux for a *long* time to come.
(I am more concerned about the old LSI SCSI controller, included in 
QEMU for disk IO. Beautiful, surprisingly efficient, but what about 
compatibility with future Windows releases. Also, the hardware was 
likely limited to LBA32.)

What do you need for a proper NIC emulation? You need to emulate some 
registers, DMA (that's especially simple) and IRQ delivery. The 
hardware even supports MSI, so it doesn't have to take part in some 
"shared virtual wire emulated on virtual APIC" kind of thing :-)
Not sure exactly how it's done, but the host probably triggers an IRQ 
in the guest's CPU core's HW LAPIC, if the guest has a whole CPU core 
dedicated to it...

Yes it does get simpler and more efficient in the virtualization 
environment (host vs. guest): the way forward is called "virtio". Or 
so I hope. Couldn't get it to work in guest XP under Qemu on a first 
attempt. At the moment I don't bother to try again / read on / press 

Actually the straight-most path to the hardware is VT-d, where the 
guest OS talks straight to its "virtual partition" of the NIC HW 
(needs a HW-specific driver in the guest OS = the guest OS must be 
reasonably modern).

To a decent guest OS, it shouldn't matter much exactly what chipset 
is emulated. You need a LAPIC and an open IO/APIC or (better yet) MSI 
for a smooth operation of IRQ's. Why care about SATA controllers, 
SM-BUS or other functions related to houskeeping in physical 
hardware, if all you really want for your guest OS is a suitable CPU 
core (or several) with independent IRQ's, RAM allocation, block IO 
access and network connectivity, and possibly an accelerated graphics 
display... most of this doesn't need much emulation of physical 
hardware, certainly not some precise past chipset (south bridge). 
What helps is a "virty-accelerated" passthrough to the host system.
If you're after efficiency and performace, focus on solutions 
bringing your legacy guest OS close to para-virtualization.

Frank Rysanek

On 17 Dec 2015 at 0:54, Wink Saville wrote:
> I'm wondering if there is a modern NIC emulated with qemu. By modern,
> I mean a NIC that it exists on a motherboard and that I could by today
> on Amazon or Newegg. 
> This could be for an X86_64 or maybe ARM.
> Thanks,
> Wink

reply via email to

[Prev in Thread] Current Thread [Next in Thread]