Re: [Qemu-ppc] KVM and variable-endianness guest CPUs

[Victor Kamensky]

On 23 January 2014 07:33, Peter Maydell <address@hidden> wrote:
> On 23 January 2014 15:06, Victor Kamensky <address@hidden> wrote:
>> In [1] I wrote
>>
>> "I don't see why you so attached to desire to describe
>> data part of memory transaction as just one of int
>> types. If we are talking about bunch of hypothetical
>> cases imagine such bus that allow transaction with
>> size of 6 bytes. How do you describe such data in
>> your ints speak? What endianity you can assign to
>> sequence of 6 bytes? While note that description of
>> such transaction as set of 6 byte values at address
>> $whatever makes perfect sense."
>>
>> But notice that in your next reply [2] you just dropped it
>
> Yes. This is because it was one of the places where
> I would have just had to repeat "no, I'm afraid you're wrong
> about how hardware works". I think in general it's going
> to be better if I don't try to reply point by point to this
> email; I think you should go back and reread the emails I've
> sent. Key points:
>  (1) hardware is not doing anything involving arrays
>      of bytes

Array of bytes or integers is just a way to describe data lines
on the bus. Did you look at this document?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0290g/ch06s05s01.html

A0, A1, ,,, A7 byte values are the same for both LE and BE-8
case (first two columns in the table) and they unambiguously
describe data bus signals

>  (2) the API between kernel and userspace needs to define
>      the semantics of mmio.data, ie how to map between
>      "x byte wide transaction with value v" and the array,
>      and that is primarily what this conversation is about
>  (3) the only choice which is both (a) sensible and (b)
>      not breaking existing usage is to say "the array is
>      in host-kernel-byte-order"
>  (4) PPC CPUs in BE mode and ARM CPUs in BE mode are not
>      the same, because in the ARM case it is doing an
>      internal-to-CPU byteswap, and in the PPC case it is not

That is one of the key disconnects. I'll go find real examples
in ARM LE, ARM BE, and PPC BE Linux kernel. Just for
everybody sake's here is summary of the disconnect:

If we have the same h/w connected to memory bus in ARM
and PPC systems and we have the following three pieces
of code that work with r0 having same device same
register address:

1. ARM LE word write of  0x04030201:
setend le
mov r1, #0x04030201
str r1, [r0]

2. ARM BE word write of 0x01020304:
setend be
mov r1, #0x01020304
str r1, [r0]

3. PPC BE word write of 0x01020304:
lis     r1,0x102
ori     r1,r1,0x304
stw    r1,0(r0)

I claim that h/w will see the same data on bus lines in all
three cases, and h/w would acts the same in all three
cases. Peter says that ARM BE and PPC BE case h/w
would act differently.

If anyone else can offer opinion on that while I am looking
for real examples that would be great.

Thanks,
Victor

> thanks
> -- PMM