From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v2] KVM: Specify byte order for KVM_EXIT_MMIO
Date: Sat, 25 Jan 2014 10:31:42 -0800
Message-ID: <20140125183142.GA2950@lvm>
References: <1390606782-14724-1-git-send-email-christoffer.dall@linaro.org>
 <1390607492.24905.682.camel@snotra.buserror.net>
 <CAFEAcA_YLwfcgcomXd7cmx5auyH48aZEFdD1UPHgXgVBGhX23g@mail.gmail.com>
 <1390615114.24905.743.camel@snotra.buserror.net>
 <86A0FDA4-97AB-43EA-8306-17A1D0A94D14@suse.de>
 <CAFEAcA8pumMGe2jx0WtWtOwri6Le3_rA0RDvgjyP6szXC_in1A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Alexander Graf <agraf@suse.de>,
	Scott Wood <scottwood@freescale.com>,
	kvm-devel <kvm@vger.kernel.org>,
	kvm-ppc <kvm-ppc@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Patch Tracking <patches@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-ppc-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <CAFEAcA8pumMGe2jx0WtWtOwri6Le3_rA0RDvgjyP6szXC_in1A@mail.gmail.com>
Sender: kvm-ppc-owner@vger.kernel.org
List-Id: kvm.vger.kernel.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