From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJZgw-0000vQ-2d for qemu-devel@nongnu.org; Tue, 28 Nov 2017 01:48:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJZgr-0007zZ-5Y for qemu-devel@nongnu.org; Tue, 28 Nov 2017 01:48:26 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53538) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJZgq-0007zK-Sj for qemu-devel@nongnu.org; Tue, 28 Nov 2017 01:48:21 -0500 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAS6lcBv052939 for ; Tue, 28 Nov 2017 01:48:19 -0500 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx0a-001b2d01.pphosted.com with ESMTP id 2eh2q0gbpb-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 28 Nov 2017 01:48:19 -0500 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Nov 2017 23:48:18 -0700 References: <1511388334-16347-1-git-send-email-pmorel@linux.vnet.ibm.com> <1511388334-16347-2-git-send-email-pmorel@linux.vnet.ibm.com> <3acc6fdb-5638-97b2-2dc7-bce34d22cd1f@redhat.com> <20171123104903.24424b40.cohuck@redhat.com> <20171123110844.4649f3b1.cohuck@redhat.com> <58a08c1d-3935-42e7-cdc0-7bc45c08d2d3@redhat.com> <20171123113326.3b2c5281.cohuck@redhat.com> <6ab0d29e-1af0-888a-c932-a0a294ea225d@linux.vnet.ibm.com> <4000596f-d2a0-c32e-7683-7e074e8132e2@linux.vnet.ibm.com> <37aa6eb3-cbdf-39af-2068-7d0e5949e601@linux.vnet.ibm.com> <2ab76ab0-b20a-9eaf-cafb-195e1621edd6@redhat.com> <20171127120255.2d36c8f3.cohuck@redhat.com> <20171127153436.200a01c7.cohuck@redhat.com> <20171127163055.6c9989cf.cohuck@redhat.com> <20171127170242.170d01f6.cohuck@redhat.com> From: Yi Min Zhao Date: Tue, 28 Nov 2017 14:48:11 +0800 MIME-Version: 1.0 In-Reply-To: <20171127170242.170d01f6.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/7] s390x/pci: factor out endianess conversion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck , Pierre Morel Cc: Thomas Huth , pasic@linux.vnet.ibm.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, Qemu-s390x list =E5=9C=A8 2017/11/28 =E4=B8=8A=E5=8D=8812:02, Cornelia Huck =E5=86=99=E9=81= =93: > On Mon, 27 Nov 2017 16:53:04 +0100 > Pierre Morel wrote: > >> On 27/11/2017 16:30, Cornelia Huck wrote: >>> On Mon, 27 Nov 2017 16:24:08 +0100 >>> Pierre Morel wrote: >>> =20 >>>> On 27/11/2017 15:34, Cornelia Huck wrote: >>>>> On Mon, 27 Nov 2017 12:02:55 +0100 >>>>> Cornelia Huck wrote: >>>>> =20 >>>>>> On Mon, 27 Nov 2017 07:59:36 +0100 >>>>>> Thomas Huth wrote: >>>>>> =20 >>>>>>> On 25.11.2017 14:49, Pierre Morel wrote: >>>>>>>> On 24/11/2017 07:19, Yi Min Zhao wrote: >>>>>>>>> >>>>>>>>> =E5=9C=A8 2017/11/23 =E4=B8=8B=E5=8D=888:18, Thomas Huth =E5=86= =99=E9=81=93: >>>>>>>>>> On 23.11.2017 13:07, Yi Min Zhao wrote: >>>>>> =20 >>>>>>>>>>> Another question, does 'cpu' in cpu_to_le**() or le**_to_cpu(= ) mean the >>>>>>>>>>> host endianess? >>>>>>>>>> Yes, the "cpu" in cpu_to_le or le_to_cpu means the host, indee= d. It's >>>>>>>>>> confusing :-/ >>>>>>>>>> =20 >>>>>>>>>>> If the answers to upper two questions are yes, we actually ne= ed handle >>>>>>>>>>> two cases. >>>>>>>>>>> 1) For pcilg, we need to translate the data to little-endian,= thus >>>>>>>>>>> cpu_to_le**(). >>>>>>>>>>> 2) For pcistg, we need to translate the data to host endianes= s, thus >>>>>>>>>>> le**_to_cpu(). >>>>>>>>>> I think we've got to byte-swap if the host is big endian (s390= x), but >>>>>>>>>> not if the host is little endian (x86 with TCG). >>>>>>>> Here is my comprehension of this funny swapping: >>>>>>>> >>>>>>>> - TCG for a BE guest and a le host swap bytes because if we do (= register >>>>>>>> & 0x01) in the zPCI interception code it must work what ever the >>>>>>>> endianess is. >>>>>>> Uhhh, I might have missed that the value has already been byte-sw= apped >>>>>>> once by TCG for env->regs[r1] ... >>>>>>> Now I'm pretty much completely confused ... sorry for the noise i= f I was >>>>>>> wrong... I think it's best you ignore my comment for now (i.e. go= with >>>>>>> bswapXX() instead of le_to_cpuXX()), and if we later wire up zPCI= with >>>>>>> TCG, we still can fix this if necessary. >>>>>> I'll try my current pci/tcg patches on LPAR with this (or a v4) on= top. >>>>>> If it works there (it doesn't yet on my laptop), we do have a >>>>>> endianness issue... (unfortunately, the reverse isn't true.) >>>>> It does not look too bad: I can get a nice enP1p0s0 device from a >>>>> virtio-net-pci with my tcg patches on my laptop (with these patches= as >>>>> well, of course). So, endianness is likely mostly fine. >>>> On the Lpar and on the Laptop or only on the Lpar ? >>> Both :) >> That's great! :) > Btw, lspci says > > 0001:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device > Subsystem: Red Hat, Inc. Device 0001 > Physical Slot: 00000000 > Flags: bus master, fast devsel, latency 0 > I/O ports at [disabled] > [virtual] Memory at 8001000000000000 (32-bit, non-prefetchable= ) [size=3D4K] > Memory at 8002000000000000 (64-bit, prefetchable) [size=3D16K] > Expansion ROM at [disabled] [size=3D256K] > Capabilities: [98] MSI-X: Enable+ Count=3D3 Masked- > Capabilities: [84] Vendor Specific Information: VirtIO: > Capabilities: [70] Vendor Specific Information: VirtIO: Notify > Capabilities: [60] Vendor Specific Information: VirtIO: Device= Cfg > Capabilities: [50] Vendor Specific Information: VirtIO: ISR > Capabilities: [40] Vendor Specific Information: VirtIO: Common= Cfg > Kernel driver in use: virtio-pci > > Does that look reasonable to you? > > Great! That means the data in env->register has been swapped. Thanks!