From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cedric Le Goater <clg@fr.ibm.com>
Subject: Re: [PATCH v5 3/6]  KVM: PPC: Book3S: MMIO emulation support for
 little endian guests
Date: Wed, 08 Jan 2014 18:40:33 +0100
Message-ID: <52CD8D91.7010201@fr.ibm.com>
References: <1383672128-26795-1-git-send-email-clg@fr.ibm.com> <1383672128-26795-4-git-send-email-clg@fr.ibm.com> <08276663-4EB5-4912-9F90-803E88DE4D1A@suse.de> <52CD899C.20305@fr.ibm.com> <52CD8C11.9020000@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Paul Mackerras <paulus@samba.org>, kvm-ppc@vger.kernel.org,
	"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>
To: Alexander Graf <agraf@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:39792 "EHLO
	e06smtp10.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750821AbaAHRkm (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 8 Jan 2014 12:40:42 -0500
Received: from /spool/local
	by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <clg@fr.ibm.com>;
	Wed, 8 Jan 2014 17:40:40 -0000
In-Reply-To: <52CD8C11.9020000@suse.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 01/08/2014 06:34 PM, Alexander Graf wrote:
>>> if (kvmppc_is_bigendian(vcpu)) {
>>>      /* Default endianness is "big endian". */
>>>      is_bigendian = is_default_endian;
>>> } else {
>>>      /* Default endianness is "little endian". */
>>>      is_bigendian = !is_default_endian;
>>> }
>>>
>>> and suddenly things become reasonably clear for everyone I'd hope.
>> I think something like :
>>
>> +    if (kvmppc_need_byteswap(vcpu))
>> +        is_bigendian = !is_bigendian;
>> +
>>
>> has a small footprint and is clear enough ?
>>
>> Thanks for the inputs, a (single) patch follows
> 
> Not really. The argument means "use the normal endianness you would usually use for memory access". It doesn't mean little or big endian yet, as that's what we determine later.
> 
> Keep in mind that gcc is really good at optimizing code like this, so please don't try to be smart with variable reusage or any of the likes. In assembly this will all look identical, but the C representation should be as self-documenting as possible.

Arg. I should have waited a few minutes. No problem. I will resend 
with your "is_default_endian" proposal. 

Cheers,

C.