From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1borQD-0003o6-Lb for qemu-devel@nongnu.org; Tue, 27 Sep 2016 08:23:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1borQ8-0000fg-9q for qemu-devel@nongnu.org; Tue, 27 Sep 2016 08:23:41 -0400 References: <1474899049-12506-1-git-send-email-lvivier@redhat.com> <1474899049-12506-5-git-send-email-lvivier@redhat.com> <20160927035313.GC30322@umbus.fritz.box> From: Laurent Vivier Message-ID: <148af96e-46ac-a471-d5e4-e47565ffdb9e@redhat.com> Date: Tue, 27 Sep 2016 14:23:31 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/4] tests: enable ohci/uhci/xhci tests on PPC64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: qemu-devel@nongnu.org, thuth@redhat.com, Greg Kurz , qemu-ppc@nongnu.org, Gerd Hoffmann , dgibson@redhat.com On 27/09/2016 09:43, Laurent Vivier wrote: > > > On 27/09/2016 05:53, David Gibson wrote: >> On Mon, Sep 26, 2016 at 04:10:49PM +0200, Laurent Vivier wrote: > >>> void qusb_pci_init_one(QPCIBus *pcibus, struct qhc *hc, uint32_t devfn, int bar) >>> { >>> hc->dev = qpci_device_find(pcibus, devfn); >>> @@ -31,6 +38,13 @@ void uhci_port_test(struct qhc *hc, int port, uint16_t expect) >>> uint16_t value = qpci_io_readw(hc->dev, addr); >>> uint16_t mask = ~(UHCI_PORT_WRITE_CLEAR | UHCI_PORT_RSVD1); >>> >>> + if (qtest_big_endian() && host_big_endian) { >>> + /* little endian device on big endian guest >>> + * must be swapped on big endian host >>> + */ >>> + value = bswap16(value); >>> + } >>> + >> >> Hm.. should the qpci_io_*() helpers handle the endian conversion? > > I'm really wondering how to manage correctly this case (I've the same > kind of issue with virtio). > > The protocol between guest and test program reads/writes data using the > guest CPU endianess, so it works in the overall case. But in this case, > hcd-uhci is a little-endian device (.endianness = DEVICE_LITTLE_ENDIAN) > on a big endian machine, so I think in the linux driver we should have a > "le16_to_cpu()". But in our case we can't use "le16_to_cpu()" because > endianess of the host cpu is not the same has the one of the guest CPU. > Perhaps I should add a "target_le16_to_cpu()"? I think the "&& host_big_endian" is a side effect of a wrong byte-swapping done in pci-spapr.c. As we read the value with the endianess of the target CPU, this should be not needed. I'm going to rework this part and define some target_leXX_to_cpu()/target_cpu_to_leXX() macros. Laurent