From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 DB6C3357CFA for ; Thu, 2 Jul 2026 09:15:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782983749; cv=none; b=RK3cHX8Gjj6JDIIE31aNteT4QZ/6UalWRwaCyLDZvPItbgu7uygVzx4Qw13qDHAjnwk8MsPY5KIuA88Z0uooA5B/inf1WKcIAZzUWmoP/HFuuAbqLUXebujSS9jiW+tdb5V0+Vh8YDAFu2D2lK7WDhFJZIcZGbJaHzs3qmiaVD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782983749; c=relaxed/simple; bh=F5P9FYrU9kWhocXwK0RUJDb+0jClSmjEz4Q3e3z4q7A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X9SiGb2yOIK0bb1p/tqpgj7H9ZxEE3PHJ27UtV4zOILXbQfZvOjeikY+S2mM3fYtnEkDoR2xXOhI5GygQbnzVSqLI33QsWl1HKI02Mb9LN1Jny5mWiN5BBTJtr1xlqN6ZMTRoMZnKeRfm7wNYO8gYl20qW/62b1HB1zL6BASHf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RGEZSY5j; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RGEZSY5j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2D351F000E9; Thu, 2 Jul 2026 09:15:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782983748; bh=ZJXzBVh2hohWBjl/eakdLk+aDOU+ixyuhKnQ80s7zGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RGEZSY5j2fqveNzL2LdbtCefdReqM1NmW2+qsqIIZxvTRJo4eDin5beKencXunjSd u/+HU97aKKxnAmD5KgGBuJhcZ4t9NZKPTuGRwcfLJN0lozYSWUNthCP43bzhYL4mnl ZPDIi//F58zHaH1t1tnEXhYhx636vl7BOkeizZWWFuiM2RTZ81trJVSeHiiejzTaFV lTfrpEDWFM9+z3+DhPcMRpUbYQznfKS+vp/XZ6o+N9b5bSj7fF1qmWaV43WqaU64tg JFc2NT6oT2b2tDG7jKnyMsYEQfnhjidN0j99HH8ubnchA2gLCU7tsx3WWywGnwe7So g2c2Zv65Hq1fw== Date: Thu, 2 Jul 2026 11:15:43 +0200 From: Ingo Molnar To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: Re: [PATCH 05/32] x86/mtrr: Stop using 32-bit MSR interfaces Message-ID: References: <20260629060526.3638272-1-jgross@suse.com> <20260629060526.3638272-6-jgross@suse.com> <3e762bea-1680-4029-a682-7fd33a76c3a2@suse.com> <83b55b6e-1828-40a3-b296-105897fed3ad@suse.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83b55b6e-1828-40a3-b296-105897fed3ad@suse.com> * Jürgen Groß wrote: > > > alternative I could use struct msr by doing: > > > > > > rdmsrq(MSR_K6_UWCCR, msr.q); > > > regs[0] = msr.l; > > > regs[1] = msr.h; > > > > > > ... > > > > > > msr.l = regs[0]; > > > msr.h = regs[1]; > > > wrmsrq(MSR_K6_UWCCR, msr.q); > > I think it would be easier to just use that initially. I can change the > patch accordingly. > > > Or just move regs[] over to a struct msr variable use? > > That would be nasty, as the index used for addressing the correct regs[] > member is _calculated_, so for each access there would need to be an "if". Ok, fair enough. Thanks, Ingo