From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoURL-0006BU-6d for qemu-devel@nongnu.org; Wed, 12 Nov 2014 04:42:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoUR8-0007Xb-St for qemu-devel@nongnu.org; Wed, 12 Nov 2014 04:42:15 -0500 Received: from mail-wg0-x231.google.com ([2a00:1450:400c:c00::231]:48254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoUR8-0007X9-LY for qemu-devel@nongnu.org; Wed, 12 Nov 2014 04:42:02 -0500 Received: by mail-wg0-f49.google.com with SMTP id x13so13762442wgg.8 for ; Wed, 12 Nov 2014 01:42:01 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54632A03.6050403@redhat.com> Date: Wed, 12 Nov 2014 10:36:03 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1415629216-59652-3-git-send-email-blaschka@linux.vnet.ibm.com> <5460E025.60004@suse.de> <20141111121015.GA35338@tuxmaker.boeblingen.de.ibm.com> <5461FE04.2050400@suse.de> <20141111123911.GA16205@tuxmaker.boeblingen.de.ibm.com> <877C2703-5899-460C-BFF8-8856B6382F4C@suse.de> <20141111140829.GC16205@tuxmaker.boeblingen.de.ibm.com> <54622A28.6020507@suse.de> <20141112084944.GA16686@tuxmaker.boeblingen.de.ibm.com> <54632383.7080103@suse.de> <20141112091930.GA45236@tuxmaker.boeblingen.de.ibm.com> <546326E8.1000909@suse.de> In-Reply-To: <546326E8.1000909@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/3] s390: implement pci instructions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Frank Blaschka Cc: "peter.maydell@linaro.org" , Frank Blaschka , "james.hogan@imgtec.com" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "borntraeger@de.ibm.com" , "cornelia.huck@de.ibm.com" , "rth@twiddle.net" On 12/11/2014 10:22, Alexander Graf wrote: >>>> Absolutely lets make an example for qemu running on BE and LE >>>> >>>> byte order config space backing pci_default_read_config pcilg (with cpu_to_le) >>>> BE 0x78563412 0x12345678 0x78563412 >>>> LE 0x78563412 0x78563412 0x78563412 >>> >>> No, pci_default_read_config() always returns 0x12345678 because it >>> returns a register, not memory. >>> >> >> You mean implementation of pci_default_read_config is broken? >> If it should return a register it should not do "return le32_to_cpu(val);" > > It has to, to convert from memory (after memcpy) to an actual register > value. Look at the value list in Paolo's email - I really have no idea > how to explain it any better. pci_default_read_config is reading from a *device* register, and has absolutely zero knowledge of the host CPU endianness. Another way to explain that the result of pci_default_read_config is independent of the host endianness, is that the function is basically doing this: switch (len) { case 1: return d->config[address]; case 2: return ldw_le_p(&d->config[address)]); case 4: return ldl_le_p(&d->config[address)]); default: abort(); } So if you want to make the outcome big endian, you have to swap unconditionally. Paolo