From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 5A6DD47887A; Tue, 30 Jun 2026 20:24:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782851084; cv=none; b=mK9HGYVl0eaAGcYURX+8clQ7rxB24mkSrmM1fgZ5JaUPomCZ6Tv1ONHO22Ldr+DKfBLyLl/FDuBJm7uMIAdNRpcD3ZL8FzpDPWt1xvnSi3LuiatPTGb6m8LZoR1EhixK4VPk51ZmYLq+K40m1qrSM685+jXXmyHlMFyWCOA8zco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782851084; c=relaxed/simple; bh=lvnSDXwnO2IamEnDSVp9Sr31rByjrt2f9gYfHAIvtUo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GlSAlkFRxFow8ZVhUjnE8VZbPacHYiyC5FmqRtpFlgEBQOF249CIyNGQMgMZm+mdFvICDK+gvSkzaN7i52a2O80KKilhLtxvFrTEjbUsXrza9JdjeO+hmSaa9OIhKUaDTLgVe9WMXRBB1IAKyMNuiLNPxEPYrRi15ji0NEbz+mU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=K5lFI3Zq; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="K5lFI3Zq" Received: from [IPV6:2601:646:8081:7da1:c71f:dfcf:59c7:993c] ([IPv6:2601:646:8081:7da1:c71f:dfcf:59c7:993c]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65UK6ofd3661806 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 30 Jun 2026 13:06:51 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65UK6ofd3661806 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026062701; t=1782850020; bh=i2G6UAafySOmb8rY0Of+scGPJBnbme4rl6a4zKkZXos=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=K5lFI3Zq4F/mIozRU6/PLoKoYWvuV/6E6cXfs0gd3x7InpQddwy7n7lCqU9zTol6p iERjS1DYHe87ViLOQDzm87qe53A2nTT739eUJgh3GED1sB/6THV4FmbnfKfjF+gZM6 V3hs8AlxsrgKHqVEonk0hhP6kKL9gYgNa+4EuHtRIhIHX/70mvzshRnY18tWCCdI5w Ll1EMcK2sxp8iMYsZYSnfeyWpSYeZ1t3FhRicQwouhz9KMqYRLpgCuNpQxbhJ9r8I9 ZsFBJMIoIbws3i0Y3H2zHi5XFwogldA2J2JWZnvAJa/cf38a+7JjgFWPQpcUApHU2I YRs6tPbYTSHfg== Message-ID: Date: Tue, 30 Jun 2026 13:06:44 -0700 Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces To: Arnd Bergmann , Juergen Gross , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "linux-edac@vger.kernel.org" , x86@kernel.org, linux-acpi@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-pci@vger.kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-crypto@vger.kernel.org, "open list:GPIO SUBSYSTEM" , linux-hyperv@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org Cc: "Rafael J . Wysocki" , Daniel Lezcano , Zhang Rui , "lukasz.luba@arm.com" , Jason Baron , Borislav Petkov , Tony Luck , Yazen Ghannam , Len Brown , Pavel Machek , Thomas Gleixner , Ingo Molnar , Dave Hansen , Sean Christopherson , Paolo Bonzini , "Kirill A. Shutemov" , Rick Edgecombe , Pu Wen , Bjorn Helgaas , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Viresh Kumar , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Damien Le Moal , Niklas Cassel , Dave Airlie , Helge Deller , linux-geode@lists.infradead.org, Olivia Mackall , Herbert Xu , Linus Walleij , Bartosz Golaszewski , Greg Kroah-Hartman , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Guenter Roeck , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Josh Poimboeuf , Pawan Gupta , Vitaly Kuznetsov , Andy Lutomirski , Boris Ostrovsky , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , "srinivas.pandruvada@linux.intel.com" , Artem Bityutskiy , Artem Bityutskiy , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Rajneesh Bhardwaj , David E Box , xen-devel@lists.xenproject.org References: <20260629060526.3638272-1-jgross@suse.com> <7332feff-2649-496c-8e49-b0a19eb54a32@app.fastmail.com> <9acced19-573d-4923-9329-8be408d2e555@suse.com> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-29 01:38, Arnd Bergmann wrote: >> >> There is no RDMSRQ instruction on any x86 CPU. Are you mixing this up with >> WRMSRNS/RDMSR using an immediate for addressing the MSR? > > Yes, I was just confused about the exact definition here and assumed > the single-register output version was actually called rdmsrq. > So just to be clear: There are three instructions(*): wrmsr - implicit form only wrmsrns - implicit or immediate rdmsr - implicit or immediate The implicit form are the same on 32 and 64 bits (and, in fact, 16 bits): they take a MSR register address in %ecx and the data as two 32-bit words in %edx:%eax. This interface predates x86-64 by about a decade, and the Linux MSR interfaces were designed when Linux was 32-bit only, so it made sense at the time to treat them as two halves, especially since MSRs often are various kinds of bitfields. It didn't help that gcc at the time was extremely inefficient in its handling of multiword arithmetic (it is much better now), so using a u64 would have made for much worse code. The immediate forms are 64-bit only and use a single arbitrary 64-bit register; the MSR address is kept in an immediate in the instruction, just like they are for most other register types. The only thing that is "special" there is that the possible register address space is very large (2^32) although in practice a very small fraction of that is (currently) used. The immediate forms are expected to be faster, and provide for further performance improvements in future microarchitectures. This is important, because it provides a fine-grain uniform architecture for supervisor-only state, instead of having to give a bulk ISA (XSAVES/XRSTORS) that is different from the fine-grained architecture, and still get good performance. This gives the kernel very fine level control over the context switch flows, for one thing. WRMSRNS is a non-serializing form of WRMSR, which is defined as an architecturally hard-serializing instruction, although some MSRs have been retconned as non-serializing (and the set is different between vendors.) We want to switch that over to the model where the kernel explicitly opts in to nonserialization, but that means using alternatives since not all CPUs have the WRMSRNS instruction. Furthermore, we want to use alternatives so we can make use of the immediate-format instructions when the MSR address is known at compile time, which it is in *nearly* all cases. If we are smart about it we can also use this to let the tracing framework be specific about what MSRs to trace, since some MSRs are frequently accessed, but many are set at startup and then rarely, if ever, touched. (*) There are actually two more instructions: RDMSRLIST WRMSRLIST ... which are bulk versions of RDMSR and WRMSRNS respectively. They can be useful to save and restore entire groups of MSRs in one shot, such as performance counter configurations. By architecturally allowing the memory operations and MSR operations to operate asynchronously, they give some of the pipeline benefits of the immediate MSR operations without requiring the MSR set to have been set at compile time or code to be dynamically generated. However, they expose an entirely different programming model, whereas the immediate- and -NS instruction choices can be entirely hidden at the C level.