Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer

[Anthony Liguori]

On Sun, Jul 14, 2013 at 9:58 AM, Peter Maydell <address@hidden> wrote:
> On 14 July 2013 14:05, Anthony Liguori <address@hidden> wrote:
>>> Also, what devices exactly would have a non-native byte order?!?  I'm
>>> confused...
>>
>> MMIO/PIO requests don't have a byte order.  It's literally 64 or 32 data
>> pins that are numbered D0..D31 whereas D0 is the LSB.  It doesn't matter
>> how the pins are arranged.
>
> Devices themselves do have a byte order, though, right? Specifically,
> if you do a 32 bit read of address 0 on a device and an 8 bit read,

It depends on the bus and device.  Busses don't necessary pass the I/O
size down to the device like that.  If it does, the device may do any
number of things (including ignoring the request entirely.

What's most common AFAIK is that the access is treated as a word
access and then truncated.  IOW, the device sees the 32-bit word read
but somewhere along the way, the top 24 bits are discarded.

The real interesting question is what happens when you do a byte
access at address 1.  I think most devices simply don't allow that.

> then you can distinguish a BE device from an LE one.
> (Most notably, RAM in QEMU is always host-endian...)
> Devices which only allow 32 bit reads and abort any others wouldn't
> have an endianness though.

My guess is that if you do this with a PCI device we have marked as
LE, you'll get a truncated 32-bit read which will make it appear LE.
But that doesn't mean it's LE.

> (I need to sit down and think about this all and draw diagrams
> and look at what we currently do, though. BE guests on LE hosts
> with and without KVM look particularly thorny.)

I took a first pass at cleaning this up and broke PPC so I'm
investigating it further.  There may be another layer of silliness
hidden somewhere too.

Regards,

Anthony Liguori

> -- PMM