From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej2-f32.google.com (mail-ej2-f32.google.com [74.125.228.160]) (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 516564E9C02 for ; Thu, 1 Oct 2026 10:34:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.160 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790850860; cv=none; b=kEmP+4iS9qKDUcSOV0M6rPEa7CsUbEEKW6YhNaIq818Nbbgj1w5T1Q8+E/37deMnFIfpo23AEWVSlIj6ulyfT8nq3GEcIeGIRjnVCdwog1oIweO1IHQRM2xmKuRJN1qKHPU2AYgxdgKkOsurSJqhrNK6GsRyVOS9g4B8vK4wfM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790850860; c=relaxed/simple; bh=VEfnYd8hTZyWgfCATX2hNdW7HMso3ZFyFWxEXtxRroY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RL/torUxW7gS7+cpptfOSRg3Y6MuDhKbgjhA4NkV3wC7OX3rzezI3iRTkJtOuL92iwhGbEESbEqLuwRqtFZpwEliYYrVHDNUtLFAr3GsbEXYg/n6mtKwe/v3QIj41TSx6poV6cINbEey6ihSmnBR0INgP5wuE+CHf7/d5M89xTA= 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=BIPnsqBz; arc=none smtp.client-ip=74.125.228.160 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="BIPnsqBz" Received: by mail-ej2-f32.google.com with SMTP id a640c23a62f3a-c2e27d11f43so94991066b.0 for ; Thu, 01 Oct 2026 03:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1790850853; x=1791455653; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fsEC2ObM81Hk4wNSJw0hwoJxDbidZYEWvF/d0koOBjc=; b=BIPnsqBza8eF3mRVs8mkgCTmAHmV4c9sy2pH25NOe5CILjR4HlEHvmmVqy1QYyQn2q +yRU1PXf/7yYdLJASXH4kqgCsnVosD73K9kg7LOMpJDN1JIDHQVUvPjp8TL4FFfcIPY+ cm+qvJ8UUNCWVZFDBbMgkjQatlpjk921SkJ8OIS/QvNI43eye4YW7H+1kvUqnGLzemF7 RQVkPYdJuRpXieIUXnsSzX9DE7VB5cHO5SQvLMoI0ASEZbePDgGFaiHfvioRntJdxBx7 GJWDccOzd8ejgl4wFiL8ljqR8dAYEsHw79EaiZtum0uhVBCxxSXJ5y9gYWIKWMJjgG7n Cfyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790850853; x=1791455653; h=content-transfer-encoding:content-type: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:content-type; bh=fsEC2ObM81Hk4wNSJw0hwoJxDbidZYEWvF/d0koOBjc=; b=PHV0vCUyvPIpGpnbtDbeG9AaQ4WbgOkeMNVzzdXa3vvsryuZzNDkBJnL6UtGw1jHLg n1iKTwpxn0PiRWZ4lTEHbaqwzJTien340vcMw8bjCAUqRBqHeeY446g1BC182AdvHyyf +VREVh8mlJPbfz0VhQZAYc0BLueHq3nReNXgHjUFQ5ZksOqq53Wxl+MBfmFNq3t+c1Tt 5VKGUsFtfJdNtsFWPZV4vPTi9pRziiuqSzn5YPayUbQ7/s8RoUjJrQWP+/VNn/tAJq3K Bvusa/SMuCpxDWwOJSJbNtTIY3jFwb/aITJlSOMS3ElNDqzNjFHeQcZ3aidJjVpqso6Y JZZQ== X-Forwarded-Encrypted: i=1; AKwUvBySGyJKObbmWo1WfU122UzdQ2h/xIdBCVlI27Qbo5NEAB8onYBqy1fdlWxaTr2kwptFr+Gs7EZhOvw2fHU=@vger.kernel.org X-Gm-Message-State: AFuF++neYzSA+QD7BifMBb+LdEz4IBRdCXtuu8uDAJhBhdHV5g0U6cBI XozzVLCMPcZ7CRhYfD8r2dlKbcxrJpbbRAuynyUJbbmMXc1JK0aRkSYItdmoPF+XUxY= X-Gm-Gg: AYBFou0f7stwMxUzZjxyIw063JNjdU/SeDafwtv+ep2GR58i4n1gHUCkRUjK5kn8dDq ehh1xIBGqYA/xFpJKA3NwljXinbi9XhFsD51kBpEMrtAXQp2Iu6n6UnnxDIU3R9scPrA5JJ4dHf Cf46bqTRhAIis518A7v/Sf+5ymiCGbHr8+3Zpro3KW9ZbOJ45x2L4IXdsCXp5CR+NRnnWQUEgxu F3YGxEXsCSqhUFrHyEVhTcZ458GgvjhQw3L3AxjVyQOClfmdZQS7V3EB+Qbo2V06ufDwxLWNkOZ WqExtvQlL300AJ6XRFLSLejmhpP84VnWbMhhOIaa3LpL3w3xaVTNp5/jnw1gQMxITLoU+86D3lA Mss9aBE+cU5GYU8uSksU742IZfzrBM/1PX+s3dgCIdXtUTGnBKyxgIBhxzxIyZd/2P6eoDwopID tpgMbf1Q+DkS8pxqaMrZnEhpCuv9o+0mnLMVKbYpwrd/pitqMlyXRljGoyKVtx0Ewx+M0iAyRDQ d4= X-Received: by 2002:a17:907:7287:b0:c2d:d4dd:8b5 with SMTP id a640c23a62f3a-c2e33e610bdmr207503066b.19.1790850853125; Thu, 01 Oct 2026 03:34:13 -0700 (PDT) Received: from [192.168.1.3] ([37.18.141.193]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2e31a3eb32sm135974866b.3.2026.10.01.03.34.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2026 03:34:12 -0700 (PDT) Message-ID: Date: Thu, 1 Oct 2026 11:34:11 +0100 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 1/6] perf: cs-etm: Don't add global v0 HW_IDs to unformatted queues To: Leo Yan Cc: John Garry , Will Deacon , Mike Leach , Leo Yan , Suzuki K Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Suyash Mahar , Amir Ayupov , Arnaldo Carvalho de Melo , linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260821-james-cs-hw_id-output-failure-v1-0-9d532ddabcc3@linaro.org> <20260821-james-cs-hw_id-output-failure-v1-1-9d532ddabcc3@linaro.org> <20260904164309.GZ8904@e132581.arm.com> Content-Language: en-US From: James Clark In-Reply-To: <20260904164309.GZ8904@e132581.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/09/2026 17:43, Leo Yan wrote: > On Fri, Aug 21, 2026 at 10:50:29AM +0100, James Clark wrote: >> In the case of mixed formatted and unformatted trace with v0 HW_IDs, or >> no HW_IDs at all resulting in the cs_etm__map_trace_ids_metadata() >> fallback, formatted queues will write their HW_IDs to unformatted >> queues. > > I understand a session can support multiple sinks, but I don't expect > to mix up formatted and unformatted trace (see sinks_compatible()). > But sinks_compatible() is only called multiple times for per-thread sessions. For per-CPU, userspace opens separate events per-CPU. If the user doesn't specify a sink then the default one is chosen which can be a different type for each CPU/path. > For the mentioned fallback, I am also struggling to establish a case. > Even AUX_OUTPUT_HW_ID records are absent randomly, I don't think this > impacts the queue's format initalization, no? The fallback uses the metadata only, without sink information, which is equivalent to v0 records. So it's just another way to trigger the same problem. If you're using global v0 mappings, then we assume that all trace IDs are possible in all queues, which results in multiple decoders being created and triggers an error in OpenCSD once it sees that being combined with unformatted.