[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly e
Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware
Mon, 08 Jun 2009 21:07:38 -0500
Thunderbird 188.8.131.52 (X11/20090320)
Bill Paul wrote:
Hi, I hope this is the right forum for this. Apologies if it's not.
I downloaded QEMU 0.10.5 and tested it against VxWorks 6.7 using the e1000
emulated network interface, and ran into a couple of problems. The VxWorks
Intel PRO/1000 driver has been tested against a real Intel 82540EM adapter,
and it works fine, however it does not work with the emulated 82540 in QEMU,
because it doesn't quite duplicate the behavior of real hardware.
There are two issues:
1) The ICS register is not emulated correctly. It's not easy to discern from
the Intel documentation, but the ICS register can be used in place of the ICR
register in order to read the currently pending interrupt sources without
automatically clearing them. The VxWorks driver needs to check interrupt
events twice: once in its ISR, and again in task context. The auto-clear
behavior of ICR makes it undesirable to use in the interrupt service routine,
since it will clear the interrupt events, preventing the task level code from
seeing them too (unless you preserve the values in software, which is tricky
to do correcly). Consequently, VxWorks reads the ICS register in its
interrupt service routine instead. This doesn't work in QEMU because:
- There is no entry in the readops table for reading the ICS register, so
reading it always returns 0.
- The ICS register contents are not updated to reflect pending events in the
2) The EERD register is not emulated correctly, which breaks VxWorks' EEPROM
access code. The commonly available Intel drivers for Linux and *BSD don't
use this register, and neither does the e1000 PXE ROM that comes with QEMU,
so it probably hasn't been tested extensively. In real hardware, the register
should only be updated when both an EEPROM offset and the START bit are
written -- setting the START bit is what triggers an actual EEPROM read
transaction. When the transaction is complete, the START bit is cleared, and
the DONE bit is set. In QEMU, writing just the EEPROM offset is enough to
cause the read transaction to occur: the simulated EEPROM contents appear and
the DONE bit is set whether the START bit was set or not.
I was able to fix both of these issues in my local copy of e1000.c, and now
the VxWorks PRO/1000 driver works correctly. I put the original code, patched
version, and a context diff at the following URL:
Thanks for the thorough explanation! Can you send the patch to the
mailing list as a diff -u and include a Signed-off-by?
Is this only an issue with VxWorks or is it also reproducible in
FreeBSD? If the former, is there anything like an evaluation copy of
VxWorks that I could use as a test harness?