From nobody Sat Nov 23 23:49:57 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=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1728858044; cv=none; d=zohomail.com; s=zohoarc; b=W9BQ0C36P1nt/Duw42D+KD8jm7C+5KQFZF4c46W/lTCfChmustc8Lq3LawQA13W54BgoRHtJ5DnJ1iOGm2v6EXSTF9sTFzHUfbiDDinDgroe6g2i2Vjv49mCsUX/UUFpQrQNXZ0IKQtxL67kk6tkiPgL5XTFexzpCIcOFS2Ob20= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1728858044; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=G2SEeBS4yBn5Ue1nQmA6MrWE5kNjL002NNNwwbKYNls=; b=Qmly6pnz7v7nBa8SESFJld/s7zKcklWdQ39RxfxM0+4LPno3G1wYK72HSLNawItwcu7eCPKO4FiWST56cWoTn9GaR7vAxR9hVJamqTUe2kKS6LIXU77Kc90gnz0fDPIIZuYRHxEr1Z/WwfzA08qbWVvET09EfuUnIDIgTM6Fa6o= 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=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1728858044351604.7790727351345; Sun, 13 Oct 2024 15:20:44 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t06q4-0007JD-PB; Sun, 13 Oct 2024 18:13:24 -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 1t06pl-0007Da-21 for qemu-devel@nongnu.org; Sun, 13 Oct 2024 18:13:06 -0400 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t06pj-0000xv-4M for qemu-devel@nongnu.org; Sun, 13 Oct 2024 18:13:04 -0400 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2e2e2d09decso2023061a91.1 for ; Sun, 13 Oct 2024 15:13:02 -0700 (PDT) Received: from stoup.. (174-21-81-121.tukw.qwest.net. [174.21.81.121]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e2d5df1eebsm7271958a91.17.2024.10.13.15.13.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Oct 2024 15:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1728857582; x=1729462382; darn=nongnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=G2SEeBS4yBn5Ue1nQmA6MrWE5kNjL002NNNwwbKYNls=; b=r/EMBe5sOSc6hzF57LU7ISDDP5djrRFTqJiikhAFegYM+4TDDx9LHTkUNv9Jth07Sg Ff9ZqERL4RrjK2VKKtbk1htWhC/zLGbWLbUkZFFHJwMk4RnACYH+hzjLuX6ZjagAlQ9R Pd/LmwfnjriG7e+2GxH1VcYD5fmcitOySDshVK3f8KMIJ6BfsRk7b3v5rbX5MwonLNPp dDaDHbot8wxzARtPbW4VWX5ZTKlsiZAd9NnO4QDzmRhcZuRR8/+/AZndCF9FRlegUOaO 2spasXPNbg2X9Ky4+4COuuFKrQWu0MMJnglhDvFxC8J4HXJE1GPjCrBQrgT2EuA/kh35 samw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728857582; x=1729462382; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G2SEeBS4yBn5Ue1nQmA6MrWE5kNjL002NNNwwbKYNls=; b=vLr9XYnzMFtWVtIE+okFrbYvOUX6KYL/G4+zkCjcxa1Kj25w1fhMPnaMqT0twlV4xF 4pwma1psVtN8DGLIBzW6u/DG/a2lUuWDvxNj85UA5E9V+S4oxJDq2VHbi4pnEi7c9KjA FN4NFrS9Qa0tzRSgx51LYrRjYBwwz3/87scLKsNaBlwC45m6LL2E1j62JwP2tTk0pHfl kLcs8p9OPKkIFHsYSj7TWqJs4E63l2nGDENjBsuqY7L2Mm/wRSG3rQXWA+p2AOWnht9W bGLuXH+MBHP3l8krip4mmeUiciRNVubaKPZypmUN5a0H48GRrY6/KS+D/p49xWWEnfhf BX/A== X-Gm-Message-State: AOJu0YxZmOi/2cWkzbZkm7U1OuqQil+BEMGRT09gDMtBvXBOqb6kExZ2 vzyXOvmikruzeZ0sdjpWdmensQyr70F8+2YtXNTBEKwLZHwAKzY0nTLQb4zVXopmXwnED4OrVi8 6 X-Google-Smtp-Source: AGHT+IHDC4ts9ocHqy6SAH35JDroJhuKCs3Id7MttegPHlnoQZYJRRstopLO4gX+bU1U9JKIMGhs0Q== X-Received: by 2002:a17:90a:c2c6:b0:2e2:a5fd:7e4c with SMTP id 98e67ed59e1d1-2e2f0aa8b36mr14247839a91.8.1728857581678; Sun, 13 Oct 2024 15:13:01 -0700 (PDT) From: Richard Henderson To: qemu-devel@nongnu.org Cc: Peter Maydell Subject: [PULL 27/27] target/arm: Fix alignment fault priority in get_phys_addr_lpae Date: Sun, 13 Oct 2024 15:12:35 -0700 Message-ID: <20241013221235.1585193-28-richard.henderson@linaro.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241013221235.1585193-1-richard.henderson@linaro.org> References: <20241013221235.1585193-1-richard.henderson@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=2607:f8b0:4864:20::102f; envelope-from=richard.henderson@linaro.org; helo=mail-pj1-x102f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @linaro.org) X-ZM-MESSAGEID: 1728858045541116600 Content-Type: text/plain; charset="utf-8" Now that we have the MemOp for the access, we can order the alignment fault caused by memory type before the permission fault for the page. For subsequent page hits, permission and stage 2 checks are known to pass, and so the TLB_CHECK_ALIGNED fault raised in generic code is not mis-ordered. Reviewed-by: Peter Maydell Signed-off-by: Richard Henderson --- target/arm/ptw.c | 51 ++++++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 21 deletions(-) diff --git a/target/arm/ptw.c b/target/arm/ptw.c index 0a1a820362..dd40268397 100644 --- a/target/arm/ptw.c +++ b/target/arm/ptw.c @@ -2129,6 +2129,36 @@ static bool get_phys_addr_lpae(CPUARMState *env, S1T= ranslate *ptw, device =3D S1_attrs_are_device(result->cacheattrs.attrs); } =20 + /* + * Enable alignment checks on Device memory. + * + * Per R_XCHFJ, the correct ordering for alignment, permission, + * and stage 2 faults is: + * - Alignment fault caused by the memory type + * - Permission fault + * - A stage 2 fault on the memory access + * Perform the alignment check now, so that we recognize it in + * the correct order. Set TLB_CHECK_ALIGNED so that any subsequent + * softmmu tlb hit will also check the alignment; clear along the + * non-device path so that tlb_fill_flags is consistent in the + * event of restart_atomic_update. + * + * In v7, for a CPU without the Virtualization Extensions this + * access is UNPREDICTABLE; we choose to make it take the alignment + * fault as is required for a v7VE CPU. (QEMU doesn't emulate any + * CPUs with ARM_FEATURE_LPAE but not ARM_FEATURE_V7VE anyway.) + */ + if (device) { + unsigned a_bits =3D memop_atomicity_bits(memop); + if (address & ((1 << a_bits) - 1)) { + fi->type =3D ARMFault_Alignment; + goto do_fault; + } + result->f.tlb_fill_flags =3D TLB_CHECK_ALIGNED; + } else { + result->f.tlb_fill_flags =3D 0; + } + if (!(result->f.prot & (1 << access_type))) { fi->type =3D ARMFault_Permission; goto do_fault; @@ -2156,27 +2186,6 @@ static bool get_phys_addr_lpae(CPUARMState *env, S1T= ranslate *ptw, result->f.attrs.space =3D out_space; result->f.attrs.secure =3D arm_space_is_secure(out_space); =20 - /* - * Enable alignment checks on Device memory. - * - * Per R_XCHFJ, this check is mis-ordered. The correct ordering - * for alignment, permission, and stage 2 faults should be: - * - Alignment fault caused by the memory type - * - Permission fault - * - A stage 2 fault on the memory access - * but due to the way the TCG softmmu TLB operates, we will have - * implicitly done the permission check and the stage2 lookup in - * finding the TLB entry, so the alignment check cannot be done sooner. - * - * In v7, for a CPU without the Virtualization Extensions this - * access is UNPREDICTABLE; we choose to make it take the alignment - * fault as is required for a v7VE CPU. (QEMU doesn't emulate any - * CPUs with ARM_FEATURE_LPAE but not ARM_FEATURE_V7VE anyway.) - */ - if (device) { - result->f.tlb_fill_flags |=3D TLB_CHECK_ALIGNED; - } - /* * For FEAT_LPA2 and effective DS, the SH field in the attributes * was re-purposed for output address bits. The SH attribute in --=20 2.43.0