[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Date: Tue, 16 Jul 2013 09:18:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2013-07-14 17:18, Anthony Liguori wrote:
> 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.

Sorry for sending out invitations and then being late to this party -
vacation. What is the status now? Do we have a short-term plan to avoid
the regression or is this better solved by cleaning up the whole
endianess thing? Is anyone actively on it, or should I take a drink, sit
down and join the discussion?


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]