From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8471236C0CD for ; Thu, 2 Apr 2026 18:07:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.109.113.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775153274; cv=none; b=Ny9FATcSLB24KsZgegygQLAD62hkfCaM/ywvNRcC9a1DCJxFfiCqxy2iH5PTz8e85u7Nq0FpLds0nNPSQVcEkMnS9411beH71QyrBGJcMCDLfWoGsZnhUfa5z0nW9TkVJlSfaIav4SbijHNY6AXUGCsFRQEjKBiCeQCN65rPBG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775153274; c=relaxed/simple; bh=MZ9zx8VlWrGpe22U20En9zDN/Y9wChcMUPLnm2MwImk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sXwgCUr6MVGUbu7grjkc7zUyypW89WGh73lITA68hZOkm2rAv1NtunjLMQ7vCC2pO0nCB2ezkzoYdYAmn/y2EgY90zVU+TZh8mNhFmBcGvVosOxKUS7aRRrXp6WboRl8wyInNNq6ggKL3UTQ2lYwLxp0G+oodzAu2/6gjWk1Nxg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de; spf=pass smtp.mailfrom=alien8.de; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=en5hIdZr; arc=none smtp.client-ip=65.109.113.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alien8.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="en5hIdZr" Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 520A840E0163; Thu, 2 Apr 2026 18:07:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g-EcvsQxP46w; Thu, 2 Apr 2026 18:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1775153260; bh=2PIQC++n09t4SCeGqtEJlLCOWIfgKq6s1/Q56ULqvZo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=en5hIdZrPwf8TFAX8bq9lyEAEH1+Wf0C5HlDQVKnNB2A+gPi/p42MM50nrpR9WoaH TfFzzRzrPBTDipBsjIuwaO2MAxuT/yEAqc++larpth9SiJmEPtjR0Kftd7xEhi9OaF LvpTyhb07au7fbZQDL4zu/RvQVHtxZh8uTGk/GN0xsnAxqnMO65S29qmB9vrAojvtV Y+PgQlrVi/7OZ3saiCVE5GwdTWPUzD5wsQFLhB9mK7Vyjs+hFfpr2VO3OYxl6D9S7V COwcm5OpVyqNKWRESGYxgHVL7O4uUQZX2Y+ckb+1EkHBBjCY8Z8/It4tzjS8cpD0Y1 Hibh/dXEarSDS4rKqlpHq9dBGwDDXV1FNtW5EsihIoRfSTWBD821xRF36DsrN5QO/k g40ofMdbuUMo61sWUr1Nz/VwNeGwRCSuwphzfFmIraHQpg5rl5CzwtYbQ68WMwm/w4 xuQfEYCSwv7DJKYFf9g7cO0zmW5Gl1hu7bVbcrgGtRw/ZbC1VzGfI7dj976+3KtFj9 jTgxCcJze4UiEjKXVHlehBTnWm6dwUxashifs0oBJEER96gyYwFb/RLz27B4ByFUtz Hbujilr0f8v2arZi5pPXGdc4fPLTacIzxE7UljIwaJ+q2F9Pg7iJBjMXXqEATuvrBu BMUHOrqGCALBL2RPq6ZMAFoE= Received: from zn.tnic (p5de8e020.dip0.t-ipconnect.de [93.232.224.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with UTF8SMTPSA id 0125340E00DE; Thu, 2 Apr 2026 18:07:32 +0000 (UTC) Date: Thu, 2 Apr 2026 20:07:26 +0200 From: Borislav Petkov To: Roman Storozhenko Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/msr: Remove misleading "unrecognized" wording in write warning Message-ID: <20260402180726.GCac6wXm2PBfL5hPmN@fat_crate.local> References: <20260325-dev_roman_msr_msg-v1-1-cd51e2579018@gmail.com> <20260330141641.GCacqFyVoaOSpIea9O@fat_crate.local> <20260401192703.GKac1xh3_4aYunqJDB@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Apr 02, 2026 at 07:37:14PM +0200, Roman Storozhenko wrote: > Both allocation and monitoring use 'msr_write' and 'msr_read' > functions that rely on '/dev/cpu//msr: > https://github.com/intel/intel-cmt-cat/blob/master/lib/allocation.c > https://github.com/intel/intel-cmt-cat/blob/master/lib/common_monitoring.c > https://github.com/intel/intel-cmt-cat/blob/master/lib/machine.c This is exactly the problem: Those MSRs belong to the kernel. So if some userspace tool goes and pokes at them under the kernel's feet, then you get to keep both pieces. This is exactly why MSR accesses are filtered. You can read this commit message carefully: a7e1f67ed29f ("x86/msr: Filter MSR writes") Your tool should work *with* the kernel which should arbitrate accesses and even better - there should be proper interfaces to the hw facilities you need - but no tool should poke at MSRs without synchronization and arbitration with the kernel. So you should remove *all* msr_*() function calls in your tool and propose proper interfaces. That's the only viable way forward. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette