From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDrBH-00044R-Oj for qemu-devel@nongnu.org; Mon, 08 Jun 2009 22:35:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDrBD-00043o-8j for qemu-devel@nongnu.org; Mon, 08 Jun 2009 22:35:19 -0400 Received: from [199.232.76.173] (port=49135 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDrBD-00043l-6h for qemu-devel@nongnu.org; Mon, 08 Jun 2009 22:35:15 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]:57959) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDrBC-0008Up-Sh for qemu-devel@nongnu.org; Mon, 08 Jun 2009 22:35:15 -0400 Received: by qyk29 with SMTP id 29so4544376qyk.4 for ; Mon, 08 Jun 2009 19:35:14 -0700 (PDT) Message-ID: <4A2DC3EA.1020308@codemonkey.ws> Date: Mon, 08 Jun 2009 21:07:38 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware References: <200906081848.39468.wpaul@windriver.com> In-Reply-To: <200906081848.39468.wpaul@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bill Paul Cc: qemu-devel@nongnu.org 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 > >