Re: [PATCH v2] KVM: Specify byte order for KVM_EXIT_MMIO

[Christoffer Dall <christoffer.dall@linaro.org>]

On Sat, Jan 25, 2014 at 04:23:00PM +0000, Peter Maydell wrote:
> On 25 January 2014 02:15, Alexander Graf <agraf@suse.de> 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