From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 44FBE31D726 for ; Thu, 19 Feb 2026 13:51:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771509091; cv=none; b=Dn4L6Obq36Sn4PNRXI/MFzjmp92dUiccErumRNCPkv5w5JlnlssM/ALoXTp9cKVuSc/I7+530XQAzNSz9JPwAPb/WrX8JnYEQGz/df68+WjzmATDLdi7k7D9RjI/bWO5gQUQ6obdu6FHLBAGOiX3gIxKEoSF9jbLpgTy5nQ5rLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771509091; c=relaxed/simple; bh=Q1N5oRG6zUyA/BKhCvdB42zsDGhd8TvkV9AZnswBR6c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZcS9XGq5gNPPoxA7AzwEd1pyB2GYWb9sK+Ui0KAOdHxH8kOKBbe+dY0FiG8zSjerR0aQaqqg/2FNDpl98OMy24kx4NEAfIGfVFq3DTe1wWmjqGgDQFbWanWpLPRQPpfQ67p0mTL1MvyKDjVJtMXVSirkDwm0UuUq69JY+gOYGjU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=ldLVCcDh; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ldLVCcDh" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4836f4cbe0bso7861855e9.3 for ; Thu, 19 Feb 2026 05:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1771509088; x=1772113888; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VMeYVXWn4rNsdtLa5RrkjJUCcdAtFa2v3GVS4ivXFT0=; b=ldLVCcDhismGfWFrKgHlqsz/BhcdQAp+9SWTWFUZgbDWh2Y0xXXJzl5dnms6VPf0lx eBZNwDPbhWjb4v/UL5rLqgl8rlPVJShH6XMNcxYPgrDwWdQ5T7B8UGHlY1reUD6ME2xs ato2aRP4rxO7QDpZ0fYJ1ikvD+NqMVCtdWJWZGfpb10ft+w1Ol6llIHktdKdAqK/BmBc D028bPS4v9x6BxKHSGmUzfhG/2I90A/P2KwsYpy03aPjq+E7PcjSC+Bnz81A9EqUOWA3 nKTy48OlYjv6PDyvN6LReYXmdtHIhZ37CWKxGSArWXxVxZXwmK2+LfUFfV0rZVeXLsp3 I8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771509088; x=1772113888; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VMeYVXWn4rNsdtLa5RrkjJUCcdAtFa2v3GVS4ivXFT0=; b=RR38uHv1taNRV4nZmtOuAvtPr6fMq7i0GYh+5BpRJDI6C3VKhYEo5950n2RkWRPnoT QwgNzBdrGV87UqQyeAM1TlRHBJS9yNFAwqJ3xPgaMxL6sDjJ/N2hEo7epNdSj5L1mRF5 E/5MUNY+x+frLd819tJEIgw5cMOVzaDeonSzNHp4aDurfuxKl6fhuTIiLB4CG/bgmO9n 3DiIYImFquUL0SHtJ3q/CDHg/TZuSVeM+yd9UkgHmzXHhp/kWfXqNlMMoeHZPTCFUr0k f9YCN3LW5ZLy5JAcxMVNoU0PdlIpbt2UV0e7fKo1Wllgd6REQ6Zt4zTgoj/L1D2aAoOs 7zYw== X-Forwarded-Encrypted: i=1; AJvYcCVHZUrCI+YmueCW+ddXczGNESlq3/OBCfBCe65KFpd7GJ/lYfjkOQw77yVEE5FBsQtWsp8cQcDgL90h0YM=@vger.kernel.org X-Gm-Message-State: AOJu0YysQQQf1y088KY8TZGmgfJRp3oUVQhiGldbgN/nodvs9mxGq1Xi TjDLBOr2Nw/I1VQYCc7ak1Godh2KK3QPN74iH5bO4Xnnk88C8FJUkLafVpG1PEW15u8= X-Gm-Gg: AZuq6aLiqTgaT0DdXorsoUPeRL9H11gP6N+0Oc88708wY6VT7NAry8ekOEwiGTpKAas OaBUduRI7h4byDBALrVommZtgdM25J22wwOZHEhrDnjIyN/HVfnJXzUFfGu8wRSm6qVuYl2WRBw DA3fxqcITgcBn5LDhWphZyEpqfKrYnq6nhsWJeraYl2LO0gaiPnd7wKt+uuCmJnc5cSgdfUXWjE R3IbUhe/tl8jtetuNNaZ5Cyl3UqmXQUDdkadmpGWFUrVtXX8i8VR/y4zWGd2Nyrq4oFWJisX9Su a1ux9UjfXifdJeUhx/sajv1QXFbkXhdxD8vBKp9cchQ/fLs8PVNDG0pGFIKqm3rt7Clu3hzKvbb JanOU43vIwxcqkuToAPLTgqXc41UnPYyS2Eh516s7CFQUTlI1t/rvF4MnWNGx/ED3V79vf8iIB9 m0vlgJPzkAe8Q6vi4RmWKoxQfZpDtt X-Received: by 2002:a05:600c:35cd:b0:479:3a86:dc1c with SMTP id 5b1f17b1804b1-48398aefd55mr85918085e9.36.1771509088528; Thu, 19 Feb 2026 05:51:28 -0800 (PST) Received: from [192.168.1.3] ([185.48.77.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31d82a8sm5742475e9.15.2026.02.19.05.51.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Feb 2026 05:51:27 -0800 (PST) Message-ID: <7b692e5c-d376-4023-80e0-76c9d9c0604f@linaro.org> Date: Thu, 19 Feb 2026 13:51:26 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf: arm_spe: Add barrier before enabling profiling buffer To: Will Deacon Cc: Michael Williams , Alexandru Elisei , Mark Rutland , Catalin Marinas , Anshuman Khandual , Rob Herring , Suzuki Poulose , Robin Murphy , Leo Yan , linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260123-james-spe-relaxation-v1-1-4ccb88fa7bc5@linaro.org> <705acb39-2eef-4e61-aec1-b9503e788299@linaro.org> Content-Language: en-US From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/02/2026 12:57 pm, Will Deacon wrote: > On Thu, Feb 19, 2026 at 12:08:27PM +0000, James Clark wrote: >> I'm back to drag this up again. So I think all of the above discussion >> relies on the ordering given by the indirect read needed for the "might >> ignore a direct write..." part. But it's _might_ ignore a direct write, it's >> possible for an implementation to not do that, so there are two possible >> implementations: >> >> #1 Where there is an indirect read to give the write ignore outcome >> #2 Where there is no write ignore outcome so it doesn't require an >> indirect read >> >> For #2 there's nothing to force the ordering. We're writing to two different >> registers (PMBPTR_EL1 and PMBLIMITR_EL1) and we have to have the >> PMBLIMITR_EL1 write come second for the buffer to be considered configured >> correctly. For example if the old value of PMBPTR_EL1 is higher than the new >> PMBLIMITR_EL1 and the write to PMBLIMITR_EL1 happens first then it's >> misconfigured. That's why we think we need the isb() here. > > I thought profiling was disabled in these cases, so why is it > misconfigured? > > If it is misconfigured, what can go wrong given that we're either stopped > or pmscr is clear? > > Will It is stopped in the interrupt handler because PMBSR_EL1.S = 1. But in arm_spe_pmu_start(), PMBSR_EL1.S = 0 so it's not stopped. And with PMBPTR_EL1 still being set to the value from the last session it could be higher than PMBLIMITR_EL1. PMSCR_EL1 doesn't affect SPEProfilingStopped(), it's only: boolean stopped = (PMBSR_EL1.S == '1'); The conditions for when the buffer needs to be configured correctly from R24557 are: ProfilingBufferEnabled() && !SPEProfilingStopped() && PMBLIMITR_EL1.FM != DISCARD I think even if PMSCR_EL1 is clear you can still get a buffer management error, even if no samples were going to be written into the buffer. It just says: While the Profiling Buffer is enabled, profiling is not stopped, and Discard mode is not enabled, all of the following must be true: * The current write pointer must be at least one sample record below the write limit pointer.