From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 6C2A3396D0A for ; Tue, 3 Feb 2026 09:30:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770111002; cv=none; b=daLsqbYcV33RqbS0Ql425eWZxrcyVKYUkdVkhDiw3MaEIl4iML7A2KN7KThpMQVUYO7ZFcuJU0DJwyjBNxaomKJrdqVtpjM1LPPecxPCJWTlhrP7U5tNBiEN+Jd4J9cAMo/Cz6DOi3jSJ0FltuGqzeYDO64OzcSr3C8yExhZC30= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770111002; c=relaxed/simple; bh=AYfe5XgZSYlMN19Mp5Tjr5Yswc60ikkFR12wsYefJrQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RwrLGxdDAgOCi4nHaCNb2pW/3UQk/EEaA/Dynl+8z8plkUISZoDSJIg7c3p6x3K12fBJXmozxESAPpKSmc1XpO1k/KkSXhGauFCxp5bqYDMnN04GZTeCIRLUmv8A36GnN57NNWUSYSSsqX7xojGNZ5OOe4D75UkgQA8Lo2167hI= 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=AUpwOwlH; arc=none smtp.client-ip=209.85.128.52 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="AUpwOwlH" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-47ee2715254so28941175e9.3 for ; Tue, 03 Feb 2026 01:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1770110999; x=1770715799; 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=Jivzn1TaUgvG4Fo6r5Dps174hoUliqTt6Of7Vkws0qw=; b=AUpwOwlHUq6/UZy9Uv2ks9jzDD5m/wSSPKh7hXQyD+qLnX9aBVD5QQ4EqO0Z51vPvc 719l1v/0W8gKDjKirHd6Ys86g1PSEf0l1QKVJCyv9zCDKbTD9XoL2n6NztODmHV+g4Sq fttcNMspyrcvE7BJnrCKk8t6GhKwc991FjMuZJisVFzilo7sNipdWgRR40uaFJrT/A0D Og61poyg+ba7E7l3yEodo3RKtr6Guyf9UH9TastlezfoB7NGttzIzewfhCf7ZzITrxLP 0UnUn2Yk06pVQgHLQnhv8ickQ4X6LDug54WB2VV1/o2EuohBLXyvFs3zW5986yHoY6ty UmSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770110999; x=1770715799; 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=Jivzn1TaUgvG4Fo6r5Dps174hoUliqTt6Of7Vkws0qw=; b=Bq6rRGRGWindWtOqSHackBNbeQHuKtNYUvkJY1/sDdzPwfWa2n4pkWSyjpV0rmdzQI vhi7hehciW55SwxZ2ce4rupLUqXuvrlYdcvz8TW+MhdXBjPp7Ltg3Po6KoER2H6n7s5J Z7rbXauQyn2nNhTpk16WxyQKPMuyVPHXXxSzHvJtuwZp0Ep2ZzOg1F/qW4NmdHxhJYQb ebzotWTBi/THFWN/AfMUgqKrrO/4qkyAIcgp4Zv6KLA25DU3nPqZrHeHNjYV855aOFaw 8MZ2qRCdCbyR2bvT2jEld8N9tLcgix+xwNhCCHZhT1m7NgREGLnb16GbmkYIs84PhOaw 7o8Q== X-Forwarded-Encrypted: i=1; AJvYcCXmAJs9eZsPA0ESAWgW+bViiZKv8LmeC4hW+0hyIIw5tiPt/VmaIk0B0MidFqey8XlOHuJlbBYb7zAKIsg=@vger.kernel.org X-Gm-Message-State: AOJu0Yz961LuwDYS4j90fl4lvPZIU+b95LTEsCxb1BBY+oGSN1Cjr2fC Mp+mA41ET7SvYuzyt00ha4fy/TDqcL6BA7B67iCN+vIel9vc+mLrLek5EzsarnepvtSYozfBzeB tuW+g X-Gm-Gg: AZuq6aL2Er5/esoytO2/7ts16SCWIMPcwIeXpVbQnN5qGaxjXILDTvfhYfqNx8/lgUo mH2vNAkL09fDJBnodtu37MvGmCOEIL80hwLWaTZR/GuSH5ywdNyv6xdpQT7cCabkPtBqcyo4pLX zosPnCks7QlTAvJN4NRUPhZ2KXU8TA2FXwX6YlMC2LzR4r6aiFIpUQkWLeFzaHmykVQkt9f9eWs Elw1bix7KDJ/uQZqxDWRS2mISRN5Jj5HpIoh9wFSp0EveFK8Aj8xX2IPKqEgv9tjpFBKYhhExDa x6esGjmTDv9BxwJpV3YgWPX+CtJxNipBZumMJlR6Or7WG+HD+KCLGGmRzXCMH5SfscP9BiY+LrH xpsbFaEY7lpVU2eCRKZnJczOUAgepGIMPdT5PJfYvSf8XARN3KIuCWGdob3OXE2XKnLUGMqW3mT m8T7N5yiWI5qW9n9VEADsDiUZUnJY= X-Received: by 2002:a05:600c:6092:b0:477:8985:4036 with SMTP id 5b1f17b1804b1-482db4592cdmr187515455e9.1.1770110998696; Tue, 03 Feb 2026 01:29:58 -0800 (PST) Received: from [192.168.1.3] ([185.48.77.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4830511cc93sm58758885e9.2.2026.02.03.01.29.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Feb 2026 01:29:58 -0800 (PST) Message-ID: <95e205af-3dec-48c7-8a0d-293629f1551b@linaro.org> Date: Tue, 3 Feb 2026 09:29:56 +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: Leo Yan , Will Deacon Cc: Mark Rutland , Catalin Marinas , Alexandru Elisei , Anshuman Khandual , Rob Herring , Suzuki Poulose , Robin Murphy , 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> <20260130202437.GB3481290@e132581.arm.com> <20260202184234.GC3481290@e132581.arm.com> <20260202191402.GD3481290@e132581.arm.com> Content-Language: en-US From: James Clark In-Reply-To: <20260202191402.GD3481290@e132581.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02/02/2026 7:14 pm, Leo Yan wrote: > On Mon, Feb 02, 2026 at 06:57:11PM +0000, Will Deacon wrote: > > [...] > > >>>> I'm not sure I follow your logic as to why both ISBs are required, but >>>> I'd have thought that if perf_aux_output_begin() fails when called from >>>> arm_spe_perf_aux_output_begin() in the irqhandler, we need the ISB >>>> because we're going to clear pmblimitr_el1 to 0 and that surely has >>>> to be ordered before clearing pmbsr? >>> >>> I think the ISB after arm_spe_perf_aux_output_begin() in the irq >>> handler is required for both the failure and success cases. >>> >>> For a normal maintenance interrupt, an ISB is inserted between writing >>> PMBLIMITR_EL1 and PMBSR_EL1 to ensure that a valid limit write is >>> visible before tracing restarts. This ensures that the following >>> conditions are safely met: >>> >>> "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. >>> >>> PMBPTR_EL1.PTR[63:56] must equal PMBLIMITR_EL1.LIMIT[63:56], >>> regardless of the value of the applicable TBI bit." >> >> Hmm, so let's say we've executed the first ISB. At that point, the >> Profiling Buffer is disabled (PMBLIMITR_EL1.E = 0) and profiling is >> stopped (PMBSR_EL1.S = 1). > > This is not true. PMBLIMITR_EL1.E is always 1 during interrupt > handling. > >> If we *don't* have the second ISB then either >> PMBLIMITR_EL1 is written first or PMBSR_EL1 is written first. But the >> text you quoted will only come into effect once they've both happened, >> right? In which case, why does the order matter for the success case? > > Yes, both PMBLIMITR_EL1.E == 1 and PMBSR_EL1.S == 0 must be true to > enable tracing. > > However, the tricky part is that PMBLIMITR_EL1.E remains 1 throughout > the sequence. Writing PMBLIMITR_EL1 effectively only sets the limit, > while clearing PMBSR_EL1 is the distinct step that enables tracing. > > Thanks, > Leo I think Leo is correct that the old isb() is still needed. I removed it under the assumption that PMBLIMITR_EL1.E was unset in the interrupt handler. Possibly because the previous version re-arranged the handler to do that. If PMBLIMITR_EL1.E is set, we have to make sure clearing PMBSR_EL1 comes last as it's the thing that defines the point where both pointers must be correct by.