linux-kernel - Re: [RFC PATCH v2 14/34] x86/msr: refactor pv_cpu_ops.write_msr{

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <054eec5c-1f36-454b-9220-b7f975d2717b@suse.com>
Date: Thu, 24 Apr 2025 12:16:21 +0200
From: Jürgen Groß <jgross@...e.com>
To: "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, linux-perf-users@...r.kernel.org,
 linux-hyperv@...r.kernel.org, virtualization@...ts.linux.dev,
 linux-pm@...r.kernel.org, linux-edac@...r.kernel.org,
 xen-devel@...ts.xenproject.org, linux-acpi@...r.kernel.org,
 linux-hwmon@...r.kernel.org, netdev@...r.kernel.org,
 platform-driver-x86@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, acme@...nel.org,
 andrew.cooper3@...rix.com, peterz@...radead.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,
 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 v2 14/34] x86/msr: refactor
 pv_cpu_ops.write_msr{_safe}()

On 22.04.25 10:21, Xin Li (Intel) wrote:
> An MSR value is represented as a 64-bit unsigned integer, with existing
> MSR instructions storing it in EDX:EAX as two 32-bit segments.
> 
> The new immediate form MSR instructions, however, utilize a 64-bit
> general-purpose register to store the MSR value.  To unify the usage of
> all MSR instructions, let the default MSR access APIs accept an MSR
> value as a single 64-bit argument instead of two 32-bit segments.
> 
> The dual 32-bit APIs are still available as convenient wrappers over the
> APIs that handle an MSR value as a single 64-bit argument.
> 
> The following illustrates the updated derivation of the MSR write APIs:
> 
>                   __wrmsrq(u32 msr, u64 val)
>                     /                  \
>                    /                    \
>             native_wrmsrq(msr, val)    native_wrmsr(msr, low, high)
>                   |
>                   |
>             native_write_msr(msr, val)
>                  /          \
>                 /            \
>         wrmsrq(msr, val)    wrmsr(msr, low, high)
> 
> When CONFIG_PARAVIRT is enabled, wrmsrq() and wrmsr() are defined on top
> of paravirt_write_msr():
> 
>              paravirt_write_msr(u32 msr, u64 val)
>                 /             \
>                /               \
>            wrmsrq(msr, val)    wrmsr(msr, low, high)
> 
> paravirt_write_msr() invokes cpu.write_msr(msr, val), an indirect layer
> of pv_ops MSR write call:
> 
>      If on native:
> 
>              cpu.write_msr = native_write_msr
> 
>      If on Xen:
> 
>              cpu.write_msr = xen_write_msr
> 
> Therefore, refactor pv_cpu_ops.write_msr{_safe}() to accept an MSR value
> in a single u64 argument, replacing the current dual u32 arguments.
> 
> No functional change intended.
> 
> Signed-off-by: Xin Li (Intel) <xin@...or.com>

Reviewed-by: Juergen Gross <jgross@...e.com>


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)