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 15531C54EBC for ; Wed, 4 Jan 2023 22:54:12 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDCbd-0000aG-KP; Wed, 04 Jan 2023 17:51:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDCbb-0000Yy-Ha for qemu-devel@nongnu.org; Wed, 04 Jan 2023 17:51:31 -0500 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pDCbZ-0008BH-Ou for qemu-devel@nongnu.org; Wed, 04 Jan 2023 17:51:31 -0500 Received: by mail-ej1-x633.google.com with SMTP id tz12so86198413ejc.9 for ; Wed, 04 Jan 2023 14:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mDiM/k4vuauW5Rg+aB6ryu2EoPf+F4/4/PIdB/AfDAk=; b=vjqEqV6g7nOXWoL8+mBJJfL/tGWy+BNkVg0d3XAdnzX2B676t1YfDSsWPTMHVbn/iy L1A1ojKZgNgtfYb0KEJB1gpYg8FgAxRB8TIZlOApyieyz8QcwLXbUiWaPbLKxu4UYhld Tq0H14huJx5kLR2CRMDlRcd1tWBk3Yg4bl6+KdbfwDqQuhW7I8GH53S109BJD2oXX3NC n5B8xXj9KnniNQukefeFApOS4Yhw218WPH4BraT40Ikr1do0d/syZPWGo6bitolr8KGA joQ+9i48ngj9qbivTA1uGAmkoU25xAu4hAJnz6vzZ7eeDpNSVNXAe5Dm2OZxIrENXNSe 5glA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mDiM/k4vuauW5Rg+aB6ryu2EoPf+F4/4/PIdB/AfDAk=; b=rwVjgkfFzRXqsh7h50neKoSU1Y5DWMwCIQEJNtQhB5gAgnqSoEuEoiGy87xz14d9ja 2QT+vZvpAxJgclTmhIwhpy/NGisQN3R+j1YhPEmJzE0kTbWdatJ2iEOC/EQluootoAGV 5lXzbTTQfiDjXdoZql+5Bm7vSJh31zQFMEa3XlCBbx4X+0+sDJ73C+DOWPb3/FeUJoAQ ol8xLovihe11uu5f0kvPTnAJpcoGBgRweNI94rdMEfYqtFbKpfdF/ZQ0rpt2XOMdmbmR 91VGY2fcioFlqeHgF4rhcGFhSxwbu4+0LrNQqtAdBehRu/LH8vBK+nq9OYfxD20rhO7K LrRA== X-Gm-Message-State: AFqh2kr0P/I1JtQiMqnbxi38ufFhAG1IRXJp3Z+n3RLnu0vHsqEpKIMJ tCqQkMMyo4qr0bGnYQU0QOx7SA== X-Google-Smtp-Source: AMrXdXuIBQvcQU16qcqQdQgyuTS7kzrMRgjyoz8lorJ4WcrG9RccLU1z81xFmfZNDbaSxSBMd/hTSQ== X-Received: by 2002:a17:906:85d9:b0:842:1627:77b4 with SMTP id i25-20020a17090685d900b00842162777b4mr43013712ejy.3.1672872687805; Wed, 04 Jan 2023 14:51:27 -0800 (PST) Received: from [192.168.1.115] ([185.126.107.38]) by smtp.gmail.com with ESMTPSA id gf3-20020a170906e20300b007bff9fb211fsm15782151ejb.57.2023.01.04.14.51.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 14:51:27 -0800 (PST) Message-ID: <702ee742-70c0-d92d-353d-1eb976d7d422@linaro.org> Date: Wed, 4 Jan 2023 23:51:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 0/6] hw/arm: Fix smpboot[] on big-endian hosts and remove tswap32() Content-Language: en-US To: Peter Maydell Cc: qemu-devel@nongnu.org, Andrew Jeffery , Igor Mitsyanko , Joel Stanley , Havard Skinnemoen , "Edgar E. Iglesias" , =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , Alistair Francis , qemu-arm@nongnu.org, Tyrone Ting References: <20221222215549.86872-1-philmd@linaro.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=philmd@linaro.org; helo=mail-ej1-x633.google.com X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.708, RCVD_IN_DNSWL_NONE=-0.0001, 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: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On 3/1/23 18:43, Peter Maydell wrote: > On Thu, 22 Dec 2022 at 21:55, Philippe Mathieu-Daudé wrote: >> >> ARM CPUs fetch instructions in little-endian. >> >> smpboot[] encoded instructions are written in little-endian. >> >> We call tswap32() on the array. tswap32 function swap a 32-bit >> value if the target endianness doesn't match the host one. >> Otherwise it is a NOP. >> >> * On a little-endian host, the array is stored as it. tswap32() >> is a NOP, and the vCPU fetches the instructions as it, in >> little-endian. >> >> * On a big-endian host, the array is stored as it. tswap32() >> swap the instructions to little-endian, and the vCPU fetches >> the instructions as it, in little-endian. >> >> Using tswap() on system emulation is a bit odd: while the target >> particularities might change the system emulation, the host ones >> (such its endianness) shouldn't interfere. >> >> We can simplify by using const_le32() to always store the >> instructions in the array in little-endian, removing the need >> for the dubious tswap(). > > The tswap() in boot.c is not dubious at all. We start > with a 32-bit value in host order (i.e. a C constant), > and we want a value in guest order so we can write it > into memory as a byte array. The correct function for that > task is tswap()... Maybe 'dubious' is a strong word inappropriate here. What I meant is tswap() forces extra reasoning "oh, on what endianness will I run this, what will happens then, is tswap() a NOP?". When using the const_le32() macro we knows the 32-bit values are already in little-endian order in the host memory, regardless of its endianness. This is convenient with ARM guests which load their instructions in this endianness, not need to tswap() at all. I'll try to reword the commit descriptions in some clearer way. Thanks, Phil.