From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLJVX-0003Am-6L for qemu-devel@nongnu.org; Sun, 15 Sep 2013 17:05:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLJVQ-0000X3-HQ for qemu-devel@nongnu.org; Sun, 15 Sep 2013 17:05:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLJVQ-0000Wz-9N for qemu-devel@nongnu.org; Sun, 15 Sep 2013 17:05:20 -0400 Date: Mon, 16 Sep 2013 00:07:24 +0300 From: "Michael S. Tsirkin" Message-ID: <20130915210724.GA7975@redhat.com> References: <1379261801-16969-1-git-send-email-marcel.a@redhat.com> <1379261801-16969-4-git-send-email-marcel.a@redhat.com> <20130915173012.GB2838@redhat.com> <20130915202551.GB7526@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Anthony Liguori , Marcel Apfelbaum , Jan Kiszka , QEMU Developers , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Sun, Sep 15, 2013 at 09:40:37PM +0100, Peter Maydell wrote: > On 15 September 2013 21:25, Michael S. Tsirkin wrote: > > On Sun, Sep 15, 2013 at 06:32:13PM +0100, Peter Maydell wrote: > >> On 15 September 2013 18:30, Michael S. Tsirkin wrote: > >> > On Sun, Sep 15, 2013 at 07:16:41PM +0300, Marcel Apfelbaum wrote: > >> >> +static const MemoryRegionOps master_abort_mem_ops = { > >> >> + .read = master_abort_mem_read, > >> >> + .write = master_abort_mem_write, > >> >> + .endianness = DEVICE_NATIVE_ENDIAN, > >> >> +}; > >> >> + > >> > > >> > Please make it little endian. > >> > DEVICE_NATIVE_ENDIAN is almost always a bug. > >> > >> ...when dealing with PCI devices. For a random device on the system bus > >> it's often correct. > > > native is really qemu host endian-ness ... what are some > > examples when it's actually correct? > > "native" means "if the device's MMIO callback does 'return 0x12345678;' > for a 32 bit read then the guest CPU should see 0x12345678". That's > almost always what you want for simple devices (which may in fact > only support 32 bit accesses to registers), because it means you don't > have to fill your device with explicit endianness swaps. But this means that you device behaves differently depending on the endian-ness of the guest system. So it only makes sense if the device is very system specific: anything outside hw/ is at least in theory not a system specific device so it should not do this. > It's also useful > if that kind of simple device might be built into either a little endian > or a bigendian system: as far as the device is concerned its 32 bit > registers still have (say) the TXRDY bit at the low end of the status > register even if the CPU is bigendian. > > That said, our current setup of marking the mmio ops with an endianness > is really conflating what in real hardware is a number of distinct properties > of the CPU, the bus, any bus controllers (like PCI!) in the path between > CPU and device and finally the device itself. So it's inherently both > confusing and confused. > > -- PMM