[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH] target-arm: crypto: fix BE host support |
Date: |
Fri, 02 Jan 2015 20:18:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 01/02/15 18:36, Peter Maydell wrote:
> On 2 January 2015 at 15:17, Laszlo Ersek <address@hidden> wrote:
>> On 01/02/15 15:18, Ard Biesheuvel wrote:
>>> (ie if you store 0x112233445566778899aabbccddeeff00 as a 64 bit write
>>> to VFP register D0 then regs[0] will be
>>> 0x112233445566778899aabbccddeeff00 regardless of host endianness. That
>>> is, the least significant 8 bits of D0 will be (regs[0] & 0xff). (This
>>> isn't the same number as if you do the union-type-punning thing with
>>> union { uint64_t l; uint8_t b[8]; } and look at b[0].)
>
> This example is confusing because I carefully said "64 bit write"
> and then used a 128 bit constant. What I meant was:
>
> ie if you store 0x1122334455667788 as a 64 bit write
> to VFP register D0 then regs[0] will be
> 0x1122334455667788 regardless of host endianness.
>
> For 128 bit vectors, if you store
> 0x112233445566778899aabbccddeeff00 to Q0 then you get
> regs[0] == 0x99aabbccddeeff00
> regs[1] == 0x1122334455667788
>
> (as is required architecturally in order for a subsequent guest
> read from D0 to do the right thing).
Thank you for the correction -- but I think that's exactly what I worked
with in the rest of my email, don't you find?
Thanks
Laszlo