From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTcpN-0000QD-SK for qemu-devel@nongnu.org; Wed, 31 Oct 2012 14:15:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTcpM-0006EK-4y for qemu-devel@nongnu.org; Wed, 31 Oct 2012 14:15:45 -0400 Date: Wed, 31 Oct 2012 14:15:39 -0400 From: "Gabriel L. Somlo" Message-ID: <20121031181538.GC29280@hedwig.ini.cmu.edu> References: <20121030172039.GN29280@hedwig.ini.cmu.edu> <20121031080351.GC1116@stefanha-thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121031080351.GC1116@stefanha-thinkpad> Subject: [Qemu-devel] [PATCH v2] e1000: pre-initialize RAH/RAL registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-trivial@nongnu.org, rene@exactcode.com, somlo@cmu.edu, qemu-devel@nongnu.org, agraf@suse.de 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(-) diff --git a/hw/e1000.c b/hw/e1000.c index e4f1ffe..a29b844 100644 --- a/hw/e1000.c +++ b/hw/e1000.c @@ -266,6 +266,8 @@ rxbufsize(uint32_t v) static void e1000_reset(void *opaque) { E1000State *d = opaque; + uint8_t *macaddr = d->conf.macaddr.a; + int i; qemu_del_timer(d->autoneg_timer); memset(d->phy_reg, 0, sizeof d->phy_reg); @@ -278,6 +280,14 @@ static void e1000_reset(void *opaque) if (d->nic->nc.link_down) { e1000_link_down(d); } + + /* Some guests expect pre-initialized RAH/RAL (AddrValid flag + MACaddr) */ + d->mac_reg[RA] = 0; + d->mac_reg[RA+1] = E1000_RAH_AV; + for (i = 0; i < 4; i++) { + d->mac_reg[RA] |= macaddr[i]<<(8*i); + d->mac_reg[RA+1] |= (i < 2) ? macaddr[i+4]<<(8*i) : 0; + } } static void -- 1.7.7.6