Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Sep 15, 2013 at 10:41:26PM +0100, Peter Maydell wrote:
> On 15 September 2013 22:07, Michael S. Tsirkin <mst@redhat.com> 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/<specific architecture>
> > 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.