All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hollis Blanchard <hollisb@us.ibm.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	qemu-devel@nongnu.org
Subject: Re: [kvm-ppc-devel] [Qemu-devel] Re: [PATCH] e1000: fix endianness
Date: Thu, 13 Mar 2008 02:59:16 +0000	[thread overview]
Message-ID: <1205377156.9736.41.camel@basalt> (raw)
In-Reply-To: <20080312220755.GA12033@volta.aurel32.net>

On Wed, 2008-03-12 at 23:07 +0100, Aurelien Jarno wrote:
> 
> We finally found the problem with rtl8139 emulation. The byteswapping
> depending on the target was not done for all registers. The 8139too
> driver was able to cope with that, but not the 8139cp. In his patch
> Hollis addressed the issue by byteswapping accesses to all registers,
> but depending the host endianness (cpu_to_ and _to_cpu functions) 
> instead of the target endianness. This was working correctly in his 
> case, as he tested it on both big endian target and hosts.
> 
> Byte swapping does not depend on host endianness nor target endianness
> but on the path from the CPU to the device, which is currently and 
> *wrongly* implemented in Qemu as a byteswap on big endian targets.
> This
> has to be fixed by providing a layer modeling the endianness. It has
> to
> maintain a bus network/tree, so it can invert the endianness of all
> the
> devices behind a PCI host controller or a PCI bridge. It also has to
> be
> dynamic, as some chipsets (e.g. gt64xxx) have a configurable bit that 
> can be changed at runtime to control the endianness.
> 
> Before it is implemented correctly, please find attached two patches
> to
> fix the rtl8139 and e1000 emulations on big endian hosts and big
> endian
> targets, using the current and *wrong* Qemu implementation with regard
> to endianness. Hopefully that works as all the systems we support
> happen
> to do the same thing.

Thanks for pursuing this Aurelien.

Although patches that replace cpu_to_* with TARGET_WORDS_BIGENDIAN usage
make me cringe, these patches do indeed seem to fix BE/BE host/target
behavior right now.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

WARNING: multiple messages have this Message-ID (diff)
From: Hollis Blanchard <hollisb@us.ibm.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] e1000: fix endianness issues
Date: Wed, 12 Mar 2008 21:59:16 -0500	[thread overview]
Message-ID: <1205377156.9736.41.camel@basalt> (raw)
In-Reply-To: <20080312220755.GA12033@volta.aurel32.net>

On Wed, 2008-03-12 at 23:07 +0100, Aurelien Jarno wrote:
> 
> We finally found the problem with rtl8139 emulation. The byteswapping
> depending on the target was not done for all registers. The 8139too
> driver was able to cope with that, but not the 8139cp. In his patch
> Hollis addressed the issue by byteswapping accesses to all registers,
> but depending the host endianness (cpu_to_ and _to_cpu functions) 
> instead of the target endianness. This was working correctly in his 
> case, as he tested it on both big endian target and hosts.
> 
> Byte swapping does not depend on host endianness nor target endianness
> but on the path from the CPU to the device, which is currently and 
> *wrongly* implemented in Qemu as a byteswap on big endian targets.
> This
> has to be fixed by providing a layer modeling the endianness. It has
> to
> maintain a bus network/tree, so it can invert the endianness of all
> the
> devices behind a PCI host controller or a PCI bridge. It also has to
> be
> dynamic, as some chipsets (e.g. gt64xxx) have a configurable bit that 
> can be changed at runtime to control the endianness.
> 
> Before it is implemented correctly, please find attached two patches
> to
> fix the rtl8139 and e1000 emulations on big endian hosts and big
> endian
> targets, using the current and *wrong* Qemu implementation with regard
> to endianness. Hopefully that works as all the systems we support
> happen
> to do the same thing.

Thanks for pursuing this Aurelien.

Although patches that replace cpu_to_* with TARGET_WORDS_BIGENDIAN usage
make me cringe, these patches do indeed seem to fix BE/BE host/target
behavior right now.

-- 
Hollis Blanchard
IBM Linux Technology Center

  reply	other threads:[~2008-03-13  2:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-07 17:23 [kvm-ppc-devel] [PATCH] e1000: fix endianness issues Hollis Blanchard
2008-03-07 17:23 ` [Qemu-devel] " Hollis Blanchard
2008-03-08 13:59 ` [kvm-ppc-devel] " Aurelien Jarno
2008-03-08 13:59   ` [Qemu-devel] " Aurelien Jarno
2008-03-08 17:08   ` [kvm-ppc-devel] " Hollis Blanchard
2008-03-08 17:08     ` [Qemu-devel] " Hollis Blanchard
2008-03-11 22:49     ` [kvm-ppc-devel] [Qemu-devel] Re: [PATCH] e1000: fix endianness Aurelien Jarno
2008-03-11 22:49       ` [Qemu-devel] Re: [PATCH] e1000: fix endianness issues Aurelien Jarno
2008-03-12 13:52       ` [kvm-ppc-devel] [Qemu-devel] Re: [PATCH] e1000: fix endianness Hollis Blanchard
2008-03-12 13:52         ` [Qemu-devel] Re: [PATCH] e1000: fix endianness issues Hollis Blanchard
2008-03-12 14:38         ` [kvm-ppc-devel] [Qemu-devel] Re: [PATCH] e1000: fix endianness Aurelien Jarno
2008-03-12 14:38           ` [Qemu-devel] Re: [PATCH] e1000: fix endianness issues Aurelien Jarno
2008-03-12 22:07           ` [kvm-ppc-devel] [Qemu-devel] Re: [PATCH] e1000: fix endianness Aurelien Jarno
2008-03-12 22:07             ` [Qemu-devel] Re: [PATCH] e1000: fix endianness issues Aurelien Jarno
2008-03-13  2:59             ` Hollis Blanchard [this message]
2008-03-13  2:59               ` Hollis Blanchard

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=1205377156.9736.41.camel@basalt \
    --to=hollisb@us.ibm.com \
    --cc=aurelien@aurel32.net \
    --cc=kvm-ppc-devel@lists.sourceforge.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.