Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware

[Anthony Liguori <anthony@codemonkey.ws>]

Hi Bill,

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 
> set_interrupt_cause() routine.
>
> 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:
>
> http://www.freebsd.org/~wpaul/qemu
>   

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?

Regards,

Anthony Liguori

> -Bill
>
>