qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bill Paul <wpaul@windriver.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware
Date: Mon, 8 Jun 2009 18:48:39 -0700	[thread overview]
Message-ID: <200906081848.39468.wpaul@windriver.com> (raw)

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

-Bill

-- 
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul@windriver.com | Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================

             reply	other threads:[~2009-06-09  1:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09  1:48 Bill Paul [this message]
2009-06-09  2:07 ` [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware Anthony Liguori
2009-06-09  3:39   ` Bill Paul
2009-06-09 14:59     ` Richard W.M. Jones
2009-06-09 19:42       ` Bill Paul
2009-07-28 21:17         ` Bill Paul
2009-07-28 21:59           ` Anthony Liguori
2009-07-28 22:21             ` Bill Paul
2009-07-28 22:54               ` Anthony Liguori
2009-07-29 18:09                 ` Bill Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906081848.39468.wpaul@windriver.com \
    --to=wpaul@windriver.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).