On 25 January 2014 02:15, Alexander Graf <agraf@xxxxxxx> wrote:
> Ok, let's go through the combinations for a 32-bit write of 0x01020304 on PPC and what data[] looks like
>
> your proposal:
>
> BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
> BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
>
> -> ldw_p() will give us the correct value to work with
>
> current proposal:
>
> BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
> LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
> BE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
> LE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
>
> -> *(uint32_t*)data will give us the correct value to work with
For completeness, ditto, ARM:
Scott's proposal (you end up with the same values in
the data array as for PPC, so userspace has to know the
"default" endianness so it can do a byteswap if the
process endianness doesn't match it; on QEMU
ldl_p() handles this for us, as you say):
BE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
LE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
LE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
current proposal:
BE guest, BE host: { 0x04, 0x03, 0x02, 0x01 }
LE guest, BE host: { 0x01, 0x02, 0x03, 0x04 }
BE guest, LE host: { 0x01, 0x02, 0x03, 0x04 }
LE guest, LE host: { 0x04, 0x03, 0x02, 0x01 }
The values in the data array are different than on
PPC, reflecting the fact that the "default" endianness
is different; userspace does
-> *(uint32_t*)data will give us the correct value to work with
regardless of what the guest CPU arch is.
> There are pros and cons for both approaches.
>
> Pro approach 1 is that it fits the way data[] is read today,
> so no QEMU changes are required. However, it means
> that user space needs to have awareness of the
> "default endianness".
> With approach 2 you don't care about endianness at all
> anymore - you just get a payload that the host process
> can read in.
>
> Obviously both approaches would work as long as they're
> properly defined :).
Agreed with all of that.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
