From nobody Sun Nov 24 00:28:14 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1727836698; cv=none; d=zohomail.com; s=zohoarc; b=IkMZx46nEsdEL85cEdESWMJ6ZJosGG+fwDSKFgv/d9qBtAeZW0H19VD9pkjRo0/bMuTH0fOtxfuIxaMKcESl8dDqQw2GERHfiCNpLxbKs+gg/7AkEaNUVbS9PlQuvVcZ0m69RAthD+V312qI4ETqIjAimIcuO9a3vFFon4B6JYA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727836698; h=Content-Type:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=i07UmOxcAlZ6yeMjfynUD+t77WSCprtUPqKqBBpManc=; b=JwsoDIihSNG1cyZARCM1h6HFlKrF5J/bw1fVmT7hMjysDaXUsMo1Hvwch6lg2InIIgRlN2WxSyUKM0NNyT82V4AG43xA/CZhi/i9DPisC5rFqJS62gp72b8SoEEqZybgRTXdse1WQVJYM15lv245UGfvEz1bVEQ4bZ9SKIkbnmo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1727836698610358.4303794578701; Tue, 1 Oct 2024 19:38:18 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svpF0-0007s0-Qr; Tue, 01 Oct 2024 22:37:26 -0400 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 1svpEz-0007rj-5I for qemu-devel@nongnu.org; Tue, 01 Oct 2024 22:37:25 -0400 Received: from nyc.source.kernel.org ([147.75.193.91]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svpEx-0002w9-6u for qemu-devel@nongnu.org; Tue, 01 Oct 2024 22:37:24 -0400 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D6D26A40BCF; Wed, 2 Oct 2024 02:37:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B58FBC4CEC6; Wed, 2 Oct 2024 02:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727836633; bh=y4WQQgNX9iQxJSHq7SBJ345D+/87gDCmZbgc8BcvMjk=; h=Date:From:To:Cc:Subject:From; b=DzyWsLTu1ALWQFWdl/qscQvGtzk8TW0QZ+7zZBfC01n7HxnjANw7lYaVJNoTf53WW p3foB+D10bI6ljQPes+U+FKKRebn182FnJIlSMETaEyPnc350gVyBQ1Z6254VoovGD BWknX7aYycmD6gWpxgsSQxa6oMoFJhPqAtfhOo7lHnNe5qS6tG/l10ypdGz3gueISM VE6GfdFnzAIdaqDSJqFCWp/6PEf+X6ivHR34+Kg8Bw2LC6omCw6r8rD+74s0d6J5z7 JhGkJs4e9+ZG+vct4ZTjJUZ85re6xxHOeQXH7ue1C0wGNG4D95OfUOCJ3Z7E+n73Tl MWxvKLiMhG8bA== Date: Wed, 2 Oct 2024 04:37:10 +0200 From: Helge Deller To: Richard Henderson , qemu-devel@nongnu.org Cc: linux-parisc@vger.kernel.org Subject: {PATCH] accel/tcg: Fix CPU specific unaligned behaviour Message-ID: MIME-Version: 1.0 Content-Disposition: inline Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=147.75.193.91; envelope-from=deller@kernel.org; helo=nyc.source.kernel.org X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.144, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1727836700402116600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When the emulated CPU reads or writes to a memory location a) for which no read/write permissions exists, *and* b) the access happens unaligned (non-natural alignment), then the CPU should either - trigger a permission fault, or - trigger an unalign access fault. In the current code the alignment check happens before the memory permission checks, so only unalignment faults will be triggered. This behaviour breaks the emulation of the PARISC architecture, where the C= PU does a memory verification first. The behaviour can be tested with the test= case from the bugzilla report. Add the necessary code to allow PARISC and possibly other architectures to trigger a memory fault instead. Signed-off-by: Helge Deller Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=3D219339 diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c index 117b516739..dd1da358fb 100644 --- a/accel/tcg/cputlb.c +++ b/accel/tcg/cputlb.c @@ -1684,6 +1684,26 @@ static void mmu_watch_or_dirty(CPUState *cpu, MMULoo= kupPageData *data, data->flags =3D flags; } =20 +/* when accessing unreadable memory unaligned, will the CPU issue + * a alignment trap or a memory access trap ? */ +#ifdef TARGET_HPPA +# define CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK 1 +#else +# define CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK 0 +#endif + +static void mmu_check_alignment(CPUState *cpu, vaddr addr, + uintptr_t ra, MMUAccessType type, MMULookupLocals *= l) +{ + unsigned a_bits; + + /* Handle CPU specific unaligned behaviour */ + a_bits =3D get_alignment_bits(l->memop); + if (addr & ((1 << a_bits) - 1)) { + cpu_unaligned_access(cpu, addr, type, l->mmu_idx, ra); + } +} + /** * mmu_lookup: translate page(s) * @cpu: generic cpu state @@ -1699,7 +1719,6 @@ static void mmu_watch_or_dirty(CPUState *cpu, MMULook= upPageData *data, static bool mmu_lookup(CPUState *cpu, vaddr addr, MemOpIdx oi, uintptr_t ra, MMUAccessType type, MMULookupLocals *= l) { - unsigned a_bits; bool crosspage; int flags; =20 @@ -1708,10 +1727,8 @@ static bool mmu_lookup(CPUState *cpu, vaddr addr, Me= mOpIdx oi, =20 tcg_debug_assert(l->mmu_idx < NB_MMU_MODES); =20 - /* Handle CPU specific unaligned behaviour */ - a_bits =3D get_alignment_bits(l->memop); - if (addr & ((1 << a_bits) - 1)) { - cpu_unaligned_access(cpu, addr, type, l->mmu_idx, ra); + if (!CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK) { + mmu_check_alignment(cpu, addr, ra, type, l); } =20 l->page[0].addr =3D addr; @@ -1760,6 +1777,10 @@ static bool mmu_lookup(CPUState *cpu, vaddr addr, Me= mOpIdx oi, tcg_debug_assert((flags & TLB_BSWAP) =3D=3D 0); } =20 + if (CPU_ALIGNMENT_CHECK_AFTER_MEMCHECK) { + mmu_check_alignment(cpu, addr, ra, type, l); + } + /* * This alignment check differs from the one above, in that this is * based on the atomicity of the operation. The intended use case is