From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750832AbdA0Xl4 (ORCPT ); Fri, 27 Jan 2017 18:41:56 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50009 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbdA0Xlv (ORCPT ); Fri, 27 Jan 2017 18:41:51 -0500 Subject: Re: ibmvtpm byteswapping inconsistency To: Benjamin Herrenschmidt , =?UTF-8?Q?Michal_Such=c3=a1nek?= , Ashley Lai , Paul Mackerras , Michael Ellerman , Peter Huewe , Marcel Selhorst , Jarkko Sakkinen , Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20170126212248.3f3e9103@kitsune.suse.cz> <1485481819.2980.82.camel@kernel.crashing.org> <1485547137.2980.94.camel@kernel.crashing.org> From: Tyrel Datwyler Date: Fri, 27 Jan 2017 12:32:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1485547137.2980.94.camel@kernel.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17012720-0040-0000-0000-0000027A495D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006508; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000201; SDB=6.00813594; UDB=6.00396912; IPR=6.00591009; BA=6.00005093; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014078; XFM=3.00000011; UTC=2017-01-27 20:32:49 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17012720-0041-0000-0000-0000066D4BEC Message-Id: <48dc15a0-eaba-29e4-f39e-500177f98638@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-27_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701270199 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27/2017 11:58 AM, Benjamin Herrenschmidt wrote: > On Fri, 2017-01-27 at 10:02 -0800, Tyrel Datwyler wrote: >>> The problem is that we are packing an in-memory structure into 2 >>> registers and it's expected that this structure is laid out in the >>> registers as if it had been loaded by a BE CPU. >> >> This is only the case if the cpu is BE. If the cpu is LE, regardless of >> the fact that our in memory structure is laid out BE, when we break it >> into 2 words each of those words needs to be loaded LE. > > That doesn't make sense and doesn't match the code... The structure > needs to always have the same in-register layout regardless of the > endianness of the CPU, especially since the underlying hypervisor > will most likely be BE :-) > > Thta's why the code does a be64_to_cpu() when loading it, this in > effect performs a "BE" load, which on a BE CPU is just a normal load > and on LE is a swap to compensate for the CPU loading it the "wrong way > around". Its possible being the end of the week I'm just a little dense, but wouldn't be64_to_cpu() imply that we are byte-swapping something that is already, or supposedly already, in BE format to cpu endianness? Which on a BE cpu I would expect a no-op, and on a LE cpu the 64bit word to have been swapped from BE --> LE? In my eyes the code does seem to support what I've argued. The same thing is done in the scsi VIO drivers. The CRQ structure is laid out and annotated BE. We use cpu_to_be() calls to load any non 8bit field. Finally, each word is swapped to cpu endian when we hand it off for the hcall. from ibmvfc_send_event(): __be64 *crq_as_u64 = (__be64 *) &evt->crq; <..snip..> if ((rc = ibmvfc_send_crq(vhost, be64_to_cpu(crq_as_u64[0]), be64_to_cpu(crq_as_u64[1])))) { Again, maybe I'm missing something. -Tyrel > > Cheers, > Ben. >