From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bon3B-00026z-69 for qemu-devel@nongnu.org; Tue, 27 Sep 2016 03:43:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bon36-00048F-4Z for qemu-devel@nongnu.org; Tue, 27 Sep 2016 03:43:37 -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: Date: Tue, 27 Sep 2016 09:43:27 +0200 MIME-Version: 1.0 In-Reply-To: <20160927035313.GC30322@umbus.fritz.box> 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 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()"? Thanks, Laurent