From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6F101C433F5 for ; Wed, 15 Dec 2021 17:16:53 +0000 (UTC) Received: from localhost ([::1]:50398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxXtc-0001uY-El for qemu-devel@archiver.kernel.org; Wed, 15 Dec 2021 12:16:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxXcR-0005NO-9J for qemu-devel@nongnu.org; Wed, 15 Dec 2021 11:59:07 -0500 Received: from 9.mo552.mail-out.ovh.net ([87.98.180.222]:43159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxXcK-0003Vb-9L for qemu-devel@nongnu.org; Wed, 15 Dec 2021 11:59:06 -0500 Received: from mxplan5.mail.ovh.net (unknown [10.108.16.235]) by mo552.mail-out.ovh.net (Postfix) with ESMTPS id 8FA622125E; Wed, 15 Dec 2021 16:58:58 +0000 (UTC) Received: from kaod.org (37.59.142.95) by DAG4EX1.mxp5.local (172.16.2.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Wed, 15 Dec 2021 17:58:57 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-95G001ce787d3a-862d-40fd-b802-e797daceda9f, DB2000250E14A505ED1736C7348301D5E40ED0AA) smtp.auth=clg@kaod.org X-OVh-ClientIp: 90.76.172.47 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= To: , Subject: [PULL 009/102] ivshmem.c: change endianness to LITTLE_ENDIAN Date: Wed, 15 Dec 2021 17:57:14 +0100 Message-ID: <20211215165847.321042-10-clg@kaod.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211215165847.321042-1-clg@kaod.org> References: <20211215165847.321042-1-clg@kaod.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [37.59.142.95] X-ClientProxiedBy: DAG8EX2.mxp5.local (172.16.2.72) To DAG4EX1.mxp5.local (172.16.2.31) X-Ovh-Tracer-GUID: 8d5567d5-a0b5-4169-99fd-1fb979b650f9 X-Ovh-Tracer-Id: 2220837570394491753 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvuddrledvgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkofgjfhggtgfgihesthekredtredtjeenucfhrhhomhepveorughrihgtucfnvgcuifhorghtvghruceotghlgheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeduudfgheetffeguefftefffeeuudeikedtueeihffhjedvueetfefgkedvteehffenucffohhmrghinhepghhithhlrggsrdgtohhmnecukfhppedtrddtrddtrddtpdefjedrheelrddugedvrdelheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhhvghlohepmhigphhlrghnhedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtlhhgsehkrghougdrohhrghdprhgtphhtthhopegtlhhgsehkrghougdrohhrgh Received-SPF: pass client-ip=87.98.180.222; envelope-from=clg@kaod.org; helo=9.mo552.mail-out.ovh.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Daniel Henrique Barboza , Richard Henderson , =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" From: Daniel Henrique Barboza The ivshmem device, as with most PCI devices, uses little endian byte order. However, the endianness of its mmio_ops is marked as DEVICE_NATIVE_ENDIAN. This presents not only the usual problems with big endian hosts but also with PowerPC little endian hosts as well, since the Power architecture in QEMU uses big endian hardware (XIVE controller, PCI Host Bridges, etc) even if the host is in little endian byte order. As it is today, the IVPosition of the device will be byte swapped when running in Power BE and LE. This can be seen by changing the existing qtest 'ivshmem-test' to run in ppc64 hosts and printing the IVPOSITION regs in test_ivshmem_server() right after the VM ids assert. For x86_64 the VM id values read are '0' and '1', for ppc64 (tested in a Power8 RHEL 7.9 BE server) and ppc64le (tested in a Power9 RHEL 8.6 LE server) the ids will be '0' and '0x1000000'. Change this device to LITTLE_ENDIAN fixes the issue for Power hosts of both endianness, and every other big-endian architecture that might use this device, without impacting x86 users. Fixes: cb06608e17f8 ("ivshmem: convert to memory API") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/168 Signed-off-by: Daniel Henrique Barboza Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20211124092948.335389-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater --- hw/misc/ivshmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c index 1ba4a98377c6..299837e5c13f 100644 --- a/hw/misc/ivshmem.c +++ b/hw/misc/ivshmem.c @@ -243,7 +243,7 @@ static uint64_t ivshmem_io_read(void *opaque, hwaddr addr, static const MemoryRegionOps ivshmem_mmio_ops = { .read = ivshmem_io_read, .write = ivshmem_io_write, - .endianness = DEVICE_NATIVE_ENDIAN, + .endianness = DEVICE_LITTLE_ENDIAN, .impl = { .min_access_size = 4, .max_access_size = 4, -- 2.31.1