From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLS2y-0003Jv-3k for qemu-devel@nongnu.org; Mon, 16 Sep 2013 02:12:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLS2o-0007pv-BK for qemu-devel@nongnu.org; Mon, 16 Sep 2013 02:12:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLS2o-0007ph-3J for qemu-devel@nongnu.org; Mon, 16 Sep 2013 02:12:22 -0400 Date: Mon, 16 Sep 2013 09:14:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20130916061427.GA10790@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> <20130915210724.GA7975@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 10:41:26PM +0100, Peter Maydell wrote: > On 15 September 2013 22:07, Michael S. Tsirkin wrote: > > On Sun, Sep 15, 2013 at 09:40:37PM +0100, Peter Maydell wrote: > >> "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 > > If you mark a device as specifically DEVICE_LITTLE_ENDIAN > or DEVICE_BIG_ENDIAN this is *also* very system specific. No, this just means the device is always wired in the same way on all systems. It's the pragmatic choice for any bus that supports device plug-in. > So you're a bit stuck either way. As I say, for basic "this just > provides a bunch of registers" devices _NATIVE_ is the > pragmatic answer, since it effectively models the way that the > same bit of hardware is wired up to the bus differently if it's > expected to be in a big or little endian system. > (Any device where you can make byte accesses into the "middle" > of a 32 bit register probably needs to think more carefully, but those > are pretty rare.) > > >anything outside hw/ > > is at least in theory not a system specific device > > This is wrong, by the way. hw/$arch contains: > * board models > * things we haven't properly separated out into self contained devices > * random "not actually a device" things like boot code > > Anything that's really a device goes in its appropriate subdirectory > (char, video, etc etc), whether it happens to be used only on one > system or one architecture or not. (For instance all the interrupt > controllers live in hw/intc though obviously they're hopelessly > system specific.) > > -- PMM Thanks for the clarification.