On Sat, Jan 25, 2014 at 04:23:00PM +0000, Peter Maydell wrote:
> 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.
>
Agreed as well.
How do we settle on one versus the other?
And if we agree on the current proposal (from Alex/Peter/Me) is the
current suggested wording ok, or can someone suggest a better wording?
We could for example include the the matrices as above for all known
architectures, but that does seem overly verbose.
-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
