From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTtsT-0007mR-Cf for qemu-devel@nongnu.org; Thu, 01 Nov 2012 08:28:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTtsR-0004uy-QY for qemu-devel@nongnu.org; Thu, 01 Nov 2012 08:28:05 -0400 Date: Thu, 1 Nov 2012 13:28:00 +0100 From: Stefan Hajnoczi Message-ID: <20121101122800.GB20508@stefanha-thinkpad.redhat.com> References: <20121030172039.GN29280@hedwig.ini.cmu.edu> <20121031080351.GC1116@stefanha-thinkpad> <20121031181538.GC29280@hedwig.ini.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121031181538.GC29280@hedwig.ini.cmu.edu> Subject: Re: [Qemu-devel] [PATCH v2] e1000: pre-initialize RAH/RAL registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: qemu-trivial@nongnu.org, rene@exactcode.com, somlo@cmu.edu, qemu-devel@nongnu.org, agraf@suse.de On Wed, Oct 31, 2012 at 02:15:39PM -0400, Gabriel L. Somlo wrote: > Some guest operating systems' drivers (Mac OS X in particular) fail to > properly initialize the Receive Address registers (probably expecting > them to be pre-initialized by an earlier component, such as a specific > proprietary BIOS). This patch pre-initializes the RA registers, allowing > OS X networking to function properly. Other guest operating systems are > not affected, and free to (re)initialize these registers during boot. > > Signed-off-by: Gabriel Somlo > --- > > On Wed, Oct 31, 2012 at 09:03:51AM +0100, Stefan Hajnoczi wrote: > > Please use 4 space indentation (QEMU coding style). > > My bad, fixed in this version. > > > > + memmove(&d->mac_reg[RA], &d->conf.macaddr, sizeof(struct MACAddr)); > > > > When the host is big-endian the filter code will byteswap and the MAC address > > will not match: > > > > for (rp = s->mac_reg + RA; rp < s->mac_reg + RA + 32; rp += 2) { > > if (!(rp[1] & E1000_RAH_AV)) > > continue; > > ra[0] = cpu_to_le32(rp[0]); > > ra[1] = cpu_to_le32(rp[1]); > > if (!memcmp(buf, (uint8_t *)ra, 6)) { > > OK, I guess I could just memmove from d->eeprom_data instead of > d->conf.macaddr.a, on the assumption that pci_e1000_init() already > did the endian-proofing for me. But probably the safest/most paranoid > method is best, see below... > > Thanks, > Gabriel > > hw/e1000.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) Although real hardware doesn't behave like this we can probably get away with it. I will test Linux and Windows guests with e1000 for the QEMU 1.3 release - if we run into problems this patch may be reverted. Thanks, applied to the net tree: https://github.com/stefanha/qemu/commits/net Stefan