qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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