Skip to content

Conversation

@PvsNarasimha
Copy link

@PvsNarasimha PvsNarasimha commented Nov 20, 2025

  • hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models
  • crypto: ccp - Add support for PCI device 0x17D8
  • x86/CPU/AMD: Add X86_FEATURE_ZEN6
  • x86/cpufeatures: Free up unused feature bits
  • x86/cpufeatures: Flip the /proc/cpuinfo appearance logic
  • x86/cpu: Add a VMX flag to enumerate 5-level EPT support to userspace
  • x86/cpufeatures: Add the CPU feature bit for FRED
  • x86/cpufeatures,opcode,msr: Add the WRMSRNS instruction support
  • x86: KVM: Add feature flag for CPUID.80000021H:EAX[bit 1]

Unit test Results

root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel# lsmod | grep ccp
ccp                   126976  1 kvm_amd
rng_core               20480  2 ccp
root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel# dmesg | grep -i ccp
[    4.696154] ccp 0000:55:00.5: enabling device (0000 -> 0002)
[    4.701413] ccp 0000:55:00.5: sev enabled
[    4.701416] ccp 0000:55:00.5: psp enabled
[    4.702375] ccp 0000:d1:00.5: enabling device (0000 -> 0002)
[    4.705551] ccp 0000:d1:00.5: sev enabled
[    4.705553] ccp 0000:d1:00.5: psp enabled
[    5.262189] ccp 0000:55:00.5: SEV API:1.55 build:65
[    5.262198] ccp 0000:55:00.5: SEV API:1.55 build:65
root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel#
root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel# grep . /sys/class/hwmon/hwmon*/name
/sys/class/hwmon/hwmon0/name:k10temp
/sys/class/hwmon/hwmon1/name:k10temp
root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel# lscpu | grep -i 'family'
BIOS CPU family:                         107
CPU family:                              26
root@volcano9dee-hostos:/home/amd/Narasimha/PR_Velinux/kernel# cat /proc/cpuinfo | grep 'cpu family' | head
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
cpu family      : 26
git clone https://github.com/lm-sensors/lm-sensors.git
cd lm-sensors
make
sudo make install
sudo sensors-detect --auto
sensors

    Chip `IPMI BMC KCS' (confidence: 8)

Note: there is no driver for IPMI BMC KCS yet.
Check https://hwmon.wiki.kernel.org/device_support_status for updates.

No modules to load, skipping modules configuration.

Unloading i2c-dev... OK
Unloading cpuid... OK

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +33.0°C

k10temp-pci-00cb
Adapter: PCI adapter
Tctl:         +32.5°C

jsmattsonjr and others added 9 commits November 25, 2025 14:46
commit 329369c upstream.

Define an X86_FEATURE_* flag for CPUID.80000021H:EAX.[bit 1], and
advertise the feature to userspace via KVM_GET_SUPPORTED_CPUID.

Per AMD's "Processor Programming Reference (PPR) for AMD Family 19h
Model 61h, Revision B1 Processors (56713-B1-PUB)," this CPUID bit
indicates that a WRMSR to MSR_FS_BASE, MSR_GS_BASE, or
MSR_KERNEL_GS_BASE is non-serializing. This is a change in previously
architected behavior.

Effectively, this CPUID bit is a "defeature" bit, or a reverse
polarity feature bit. When this CPUID bit is clear, the feature
(serialization on WRMSR to any of these three MSRs) is available. When
this CPUID bit is set, the feature is not available.

KVM_GET_SUPPORTED_CPUID must pass this bit through from the underlying
hardware, if it is set. Leaving the bit clear claims that WRMSR to
these three MSRs will be serializing in a guest running under
KVM. That isn't true. Though KVM could emulate the feature by
intercepting writes to the specified MSRs, it does not do so
today. The guest is allowed direct read/write access to these MSRs
without interception, so the innate hardware behavior is preserved
under KVM.

Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231005031237.1652871-1-jmattson@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit a4cb5ec upstream.

WRMSRNS is an instruction that behaves exactly like WRMSR, with
the only difference being that it is not a serializing instruction
by default. Under certain conditions, WRMSRNS may replace WRMSR to
improve performance.

Add its CPU feature bit, opcode to the x86 opcode map, and an
always inline API __wrmsrns() to embed WRMSRNS into the code.

Signed-off-by: Xin Li <xin3.li@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Shan Kang <shan.kang@intel.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231205105030.8698-2-xin3.li@intel.com
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 51c158f upstream.

Any FRED enabled CPU will always have the following features as its
baseline:

  1) LKGS, load attributes of the GS segment but the base address into
     the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor
     cache.

  2) WRMSRNS, non-serializing WRMSR for faster MSR writes.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Xin Li <xin3.li@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Shan Kang <shan.kang@intel.com>
Link: https://lore.kernel.org/r/20231205105030.8698-7-xin3.li@intel.com
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit b1a3c36 upstream.

Add a VMX flag in /proc/cpuinfo, ept_5level, so that userspace can query
whether or not the CPU supports 5-level EPT paging.  EPT capabilities are
enumerated via MSR, i.e. aren't accessible to userspace without help from
the kernel, and knowing whether or not 5-level EPT is supported is useful
for debug, triage, testing, etc.

For example, when EPT is enabled, bits 51:48 of guest physical addresses
are consumed by the CPU if and only if 5-level EPT is enabled.  For CPUs
with MAXPHYADDR > 48, KVM *can't* map all legal guest memory without
5-level EPT, making 5-level EPT support valuable information for userspace.

Reported-by: Yi Lai <yi1.lai@intel.com>
Cc: Tao Su <tao1.su@linux.intel.com>
Cc: Xudong Hao <xudong.hao@intel.com>
Link: https://lore.kernel.org/r/20240110002340.485595-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 78ce84b upstream.

I'm getting tired of telling people to put a magic "" in the

  #define X86_FEATURE		/* "" ... */

comment to hide the new feature flag from the user-visible
/proc/cpuinfo.

Flip the logic to make it explicit: an explicit "<name>" in the comment
adds the flag to /proc/cpuinfo and otherwise not, by default.

Add the "<name>" of all the existing flags to keep backwards
compatibility with userspace.

There should be no functional changes resulting from this.

[Backport change]
ff89862

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20240618113840.24163-1-bp@kernel.org
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 7a470e826d7521bec6af789deab31cfa4fd05af3 upstream.

Linux defined feature bits X86_FEATURE_P3 and X86_FEATURE_P4 are not
used anywhere. Commit f31d731 ("x86: use X86_FEATURE_NOPL in
alternatives") got rid of the last usage in 2008. Remove the related
mappings and code.

Just like all X86_FEATURE bits, the raw bit numbers can be exposed to
userspace via MODULE_DEVICE_TABLE(). There is a very small theoretical
chance of userspace getting confused if these bits got reassigned and
changed logical meaning.  But these bits were never used for a device
table, so it's highly unlikely this will ever happen in practice.

[ dhansen: clarify userspace visibility of these bits ]

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/all/20241107233000.2742619-1-sohil.mehta%40intel.com
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 24ee8d9432b5744fce090af3d829a39aa4abf63f upstream.

Add a synthetic feature flag for Zen6.

  [  bp: Move the feature flag to a free slot and avoid future merge
     conflicts from incoming stuff. ]

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250513204857.3376577-1-yazen.ghannam@amd.com
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 63935e2ee1f2a371e511f853737b9efebc238bc7 upstream.

Add a new CCP/PSP PCI device ID.

Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit f116af2eb51ed9df24911537fda32a033f1c58da upstream.

Add thermal info support for newer AMD Family 1Ah-based models.

Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Link: https://lore.kernel.org/r/20250729001644.257645-1-avadhut.naik@amd.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
@guojinhui-liam guojinhui-liam merged commit 99955de into openvelinux:6.6-velinux Dec 14, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants