From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a7-smtp.messagingengine.com (flow-a7-smtp.messagingengine.com [103.168.172.142]) (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 79E493A7F46; Mon, 29 Jun 2026 06:52:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.142 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782715965; cv=none; b=WNukvshhnJkMqJBrSROazgTBp/aNL0z0aSUiHeCC6lGNic7EZyj+kn4BZPp511yrNGQzSO9mLPx8eMBB6Y4JKaUeEDc7JIOSEWa3XQxLTNB+xV1Hx3kj8WQpMUV8OHsibPk5XTDpdUs8xtMr3DUSlSDsUqaQxKARfHh4Gkw6WFQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782715965; c=relaxed/simple; bh=H2lwxsHZZ7EtTub4WwMeUp/eTT8kysSLHLDVR3xxm8k=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=KKsoXH/8hwsJhExR7X/khsHMbB7QJFaGcun7LAMsYVzgiT2v9Nj0k5bb5CUtCwnI3/Xdih9pJMKgmIsPi4P2Vch0y1pk7Zz2UPHXeDNvN8qCHD4TS6pDMoQ8xIiDYdNsOv5N2LPdSo8l/an2SMNPKT1n/2SmZ3b7zLshmlsZyco= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=moVeurPh; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=hB46Z3Kr; arc=none smtp.client-ip=103.168.172.142 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="moVeurPh"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="hB46Z3Kr" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.phl.internal (Postfix) with ESMTP id 8ADB1138013F; Mon, 29 Jun 2026 02:52:41 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Mon, 29 Jun 2026 02:52:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1782715961; x=1782723161; bh=tOv4MTUTsrDaiEgHTG/NX+h1I0Ci3tUDRjXnSX8B8ZY=; b= moVeurPh2zmNrJzP8rbqUPqQIFGV1KR17RcUSPE3wJu/2S/XINfbBToo5f9RQh1/ clf/45HkV8kiwjLDnKA0ZGB+xXs/LxQ97UYdGp3mAyhY1rMWfb2ut8ebDlQumP3M VdcxoT0cWYJThMe3tHYwBYuJA8gYjCl4dkRIsx+Q/6emrBa3QY8Idt3PtT6T4gzt pjXS/9QEWhZ2jfyda0VyMgxTDzLco04X3qt/vrJYJWvdC+PMyVwHCjEhVeOyJIAS gEH+rz/z5nLfxJeyVUnha0jbbsfFFgbhjlE2+BlgPqMCXL8vkYcgC6UiT7hGGY74 xGTwwQphEUZ53wLPdY/lOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1782715961; x= 1782723161; bh=tOv4MTUTsrDaiEgHTG/NX+h1I0Ci3tUDRjXnSX8B8ZY=; b=h B46Z3KrfXyr5c4NuJHJwRpFO3VNQg2XJYEDC6YUGKJUsEhIcM3CblEFDPTT7wsQg LH0S5A3tvITWrXHqFdF1EkeHZjTnuQT+pgHJLOdtZCOrRZh456xh3Sx0k+T+zXCp kNYUxD9xFRSmKJKTjyfm848VuBVywgSQdS0Y1730vc3RugkRsZPqt6GHmPUgFsPs 4nONFFGrtMfsX7i/XMkZbKMKnAy+BEdiCfia6dBPn42W2/ZviCTsT6LG5Oj/ruof ficdFWVRuGB5I8j63MB1URziScDM3F1SM330Kw/lKTbew/mmDBQO8+P/9fMGp4QQ AUBT5DiFaGcisBboaL0uQ== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGwOHixY05HMZ27iS84Skvde8o1DDsiwY6D60DzXWO2ZVrwdRrpSa8R1278jed1uY wlWCiz3tDrtZHQkvMp/MBP5v/ghF2ufPQuFtrtJ4F0wh9DtG/XVpt0pROqEThSmUEDgCf0 eTVEoMiS68VQPXRPt6VCUkkecnFqx+ZBjUZbbdMDP3RsDcc++iQYtFCDsx7qN3zPyVD3xY 9i6Bzl+AIdZTqf3H9PE4La2YJtJbmBtGNvfDerKjWxD0tIQdIxc4ff6CyIl+oAxSN3L67g IQoXuyz4qEo4Q1DYv/YVlijZQSf0JOEgla6HGT0QZP1hJCRQsFe920XNZ7JCBQqZpPrjbH Tnk4/qORnBMbT1wfL00kYIifWwvRfHEzwO8X4XjYvXGKPupOF+Aih7SyjMueufJZIiNJhm gk+r3F4ioudpLQgLl8s2Bai/sQm/lpFYJPWmS816rZo8N1I3fGaKF8vaCjnsPMfwksRvl0 6Af/2BtixmkFEnOpg4axh9H+xCdn89MnkDhmnuoJzY/popvh/LfTLliWEeyDWOhpCgCE4O h18zdmDtHrrW/u8WZmRXrY3iQ3r0wTSENEm+dusuNb8xtIAhju1BiHn0naN+53TgzSbvzd yzmZYCi7ifaUifdFk2wMrmhMIjP1c9DeNzX5Xx4Sctv2yWtIBtVWa0+zIeZw X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 54A63182007E; Mon, 29 Jun 2026 02:52:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: ApSqBjiSqQZ- Date: Mon, 29 Jun 2026 08:52:18 +0200 From: "Arnd Bergmann" To: "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" , "H. Peter Anvin" , "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 Message-Id: In-Reply-To: <20260629060526.3638272-1-jgross@suse.com> References: <20260629060526.3638272-1-jgross@suse.com> Subject: Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2026, at 08:04, Juergen Gross wrote: > For accessing the MSR registers on the local CPU, there are 2 types of > interfaces: the "modern" 64-bit ones (rdmsrq() etc.) and the 32-bit > ones (rdmsr() etc.) which are using the upper and lower 32-bit halves > of the 64-bit wide MSR register values. > > The 32-bit interfaces are not optimal for 3 reasons: > > - They are based on primitives using 64-bit sized values anyway. > > - Modern x86 CPUs have added support for MSR access instructions using > an immediate value instead of a register for addressing the MSR, > while the value is in a 64-bit register. > > - rdmsr() is a macro storing the upper and lower 32-bit halves in > variables specified as macro parameters. This is obscuring variable > assignment through a macro. Additionally rdmsrq() is mimicking this > pattern by being a macro, too, with the target variable specified as > a parameter as well. > > For those reasons drop the 32-bit interfaces for accessing the x86 MSR > registers completely and only use the 64-bit variants. Hi J=C3=BCrgen, I assume this is fine, but since you don't mention it explicitly here, please clarify what this means for 32-bit CPUs without the rdmsrq instruction. Those will continue using the same instructions as before and just change the calling conventions, right? > Note that most patches of this series are independent from each other. > Only the patches removing a specific interface (patches 7, 15, 26 and > 30) and the last two patches of the series depend on all previous > patches. It looks like you are touching most files twice or more here, to first convert from rdmsr to rdmsrq and then to change the two-argument rdmsrq() macro to a single-argument inline. If you introduce the inline version of rdmsrq() first, you should be able to skip the second step (patch 31) as they could be able to coexist. Arnd