[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0084e9a9-8247-456f-b1a5-c5cd7bb62710@zytor.com>
Date: Mon, 31 Mar 2025 22:29:21 -0700
From: Xin Li <xin@...or.com>
To: "H. Peter Anvin" <hpa@...or.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-hyperv@...r.kernel.org, virtualization@...ts.linux.dev,
linux-edac@...r.kernel.org, kvm@...r.kernel.org,
xen-devel@...ts.xenproject.org, linux-ide@...r.kernel.org,
linux-pm@...r.kernel.org, bpf@...r.kernel.org, llvm@...ts.linux.dev
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, jgross@...e.com,
peterz@...radead.org, acme@...nel.org, namhyung@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, wei.liu@...nel.org, ajay.kaher@...adcom.com,
alexey.amakhalov@...adcom.com, bcm-kernel-feedback-list@...adcom.com,
tony.luck@...el.com, pbonzini@...hat.com, vkuznets@...hat.com,
seanjc@...gle.com, luto@...nel.org, boris.ostrovsky@...cle.com,
kys@...rosoft.com, haiyangz@...rosoft.com, decui@...rosoft.com
Subject: Re: [RFC PATCH v1 01/15] x86/msr: Replace __wrmsr() with
native_wrmsrl()
On 3/31/2025 10:13 PM, H. Peter Anvin wrote:
> On March 31, 2025 2:45:43 PM PDT, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
>> On 31/03/2025 9:22 am, Xin Li (Intel) wrote:
>>> __wrmsr() is the lowest level primitive MSR write API, and its direct
>>> use is NOT preferred. Use its wrapper function native_wrmsrl() instead.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Xin Li (Intel) <xin@...or.com>
>>
>> The critical piece of information you're missing from the commit message
>> is that the MSR_IMM instructions take a single u64.
>>
>> Therefore to use them, you've got to arrange for all callers to provide
>> a single u64, rather than a split u32 pair.
>>
>> ~Andrew
>
> That being said, there is nothing wrong with having a two-word convenience wrapper.
>
Yes, I ended up keeping the two-word convenience wrapper in this patch
set, and the wrapper calls a lower level API that takes a u64 argument.
And yes, as Ingo said, some of the conversion is NOT an improvement.
Powered by blists - more mailing lists