<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pm24.git/arch/x86/kernel/cpu, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>https://git.kobert.dev/pm24.git/atom/arch/x86/kernel/cpu?h=master</id>
<link rel='self' href='https://git.kobert.dev/pm24.git/atom/arch/x86/kernel/cpu?h=master'/>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/'/>
<updated>2024-12-06T18:57:05Z</updated>
<entry>
<title>x86/CPU/AMD: WARN when setting EFER.AUTOIBRS if and only if the WRMSR fails</title>
<updated>2024-12-06T18:57:05Z</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2024-12-06T16:20:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=492077668fb453b8b16c842fcf3fafc2ebc190e9'/>
<id>urn:sha1:492077668fb453b8b16c842fcf3fafc2ebc190e9</id>
<content type='text'>
When ensuring EFER.AUTOIBRS is set, WARN only on a negative return code
from msr_set_bit(), as '1' is used to indicate the WRMSR was successful
('0' indicates the MSR bit was already set).

Fixes: 8cc68c9c9e92 ("x86/CPU/AMD: Make sure EFER[AIBRSE] is set")
Reported-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/Z1MkNofJjt7Oq0G6@google.com
Closes: https://lore.kernel.org/all/20241205220604.GA2054199@thelio-3990X
</content>
</entry>
<entry>
<title>x86/cacheinfo: Delete global num_cache_leaves</title>
<updated>2024-12-06T12:13:36Z</updated>
<author>
<name>Ricardo Neri</name>
<email>ricardo.neri-calderon@linux.intel.com</email>
</author>
<published>2024-11-28T00:22:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=9677be09e5e4fbe48aeccb06ae3063c5eba331c3'/>
<id>urn:sha1:9677be09e5e4fbe48aeccb06ae3063c5eba331c3</id>
<content type='text'>
Linux remembers cpu_cachinfo::num_leaves per CPU, but x86 initializes all
CPUs from the same global "num_cache_leaves".

This is erroneous on systems such as Meteor Lake, where each CPU has a
distinct num_leaves value. Delete the global "num_cache_leaves" and
initialize num_leaves on each CPU.

init_cache_level() no longer needs to set num_leaves. Also, it never had to
set num_levels as it is unnecessary in x86. Keep checking for zero cache
leaves. Such condition indicates a bug.

  [ bp: Cleanup. ]

Signed-off-by: Ricardo Neri &lt;ricardo.neri-calderon@linux.intel.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: stable@vger.kernel.org # 6.3+
Link: https://lore.kernel.org/r/20241128002247.26726-3-ricardo.neri-calderon@linux.intel.com
</content>
</entry>
<entry>
<title>x86/cpu/topology: Remove limit of CPUs due to disabled IO/APIC</title>
<updated>2024-12-05T13:43:32Z</updated>
<author>
<name>Fernando Fernandez Mancera</name>
<email>ffmancera@riseup.net</email>
</author>
<published>2024-12-02T14:58:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=73da582a476ea6e3512f89f8ed57dfed945829a2'/>
<id>urn:sha1:73da582a476ea6e3512f89f8ed57dfed945829a2</id>
<content type='text'>
The rework of possible CPUs management erroneously disabled SMP when the
IO/APIC is disabled either by the 'noapic' command line parameter or during
IO/APIC setup. SMP is possible without IO/APIC.

Remove the ioapic_is_disabled conditions from the relevant possible CPU
management code paths to restore the orgininal behaviour.

Fixes: 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management")
Signed-off-by: Fernando Fernandez Mancera &lt;ffmancera@riseup.net&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241202145905.1482-1-ffmancera@riseup.net
</content>
</entry>
<entry>
<title>x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation</title>
<updated>2024-12-04T20:30:14Z</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2024-11-13T02:07:00Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=c9a4b55431e5220347881e148725bed69c84e037'/>
<id>urn:sha1:c9a4b55431e5220347881e148725bed69c84e037</id>
<content type='text'>
Under some conditions, MONITOR wakeups on Lunar Lake processors
can be lost, resulting in significant user-visible delays.

Add Lunar Lake to X86_BUG_MONITOR so that wake_up_idle_cpu()
always sends an IPI, avoiding this potential delay.

Reported originally here:

	https://bugzilla.kernel.org/show_bug.cgi?id=219364

[ dhansen: tweak subject ]

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc:stable@vger.kernel.org
Link: https://lore.kernel.org/all/a4aa8842a3c3bfdb7fe9807710eef159cbf0e705.1731463305.git.len.brown%40intel.com
</content>
</entry>
<entry>
<title>Merge tag 'x86_urgent_for_v6.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2024-12-01T20:35:37Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-12-01T20:35:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=58ac609b99db0b03f3b09299c8fa3a76face3370'/>
<id>urn:sha1:58ac609b99db0b03f3b09299c8fa3a76face3370</id>
<content type='text'>
Pull x86 fixes from Borislav Petkov:

 - Add a terminating zero end-element to the array describing AMD CPUs
   affected by erratum 1386 so that the matching loop actually
   terminates instead of going off into the weeds

 - Update the boot protocol documentation to mention the fact that the
   preferred address to load the kernel to is considered in the
   relocatable kernel case too

 - Flush the memory buffer containing the microcode patch after applying
   microcode on AMD Zen1 and Zen2, to avoid unnecessary slowdowns

 - Make sure the PPIN CPU feature flag is cleared on all CPUs if PPIN
   has been disabled

* tag 'x86_urgent_for_v6.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/CPU/AMD: Terminate the erratum_1386_microcode array
  x86/Documentation: Update algo in init_size description of boot protocol
  x86/microcode/AMD: Flush patch buffer mapping after application
  x86/mm: Carve out INVLPG inline asm for use by others
  x86/cpu: Fix PPIN initialization
</content>
</entry>
<entry>
<title>x86/CPU/AMD: Terminate the erratum_1386_microcode array</title>
<updated>2024-11-26T14:12:00Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2024-11-26T13:47:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=ff6cdc407f4179748f4673c39b0921503199a0ad'/>
<id>urn:sha1:ff6cdc407f4179748f4673c39b0921503199a0ad</id>
<content type='text'>
The erratum_1386_microcode array requires an empty entry at the end.
Otherwise x86_match_cpu_with_stepping() will continue iterate the array after
it ended.

Add an empty entry to erratum_1386_microcode to its end.

Fixes: 29ba89f189528 ("x86/CPU/AMD: Improve the erratum 1386 workaround")
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20241126134722.480975-1-bigeasy@linutronix.de
</content>
</entry>
<entry>
<title>x86: fix off-by-one in access_ok()</title>
<updated>2024-11-25T20:19:05Z</updated>
<author>
<name>David Laight</name>
<email>David.Laight@ACULAB.COM</email>
</author>
<published>2024-11-24T15:39:00Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=573f45a9f9a47fed4c7957609689b772121b33d7'/>
<id>urn:sha1:573f45a9f9a47fed4c7957609689b772121b33d7</id>
<content type='text'>
When the size isn't a small constant, __access_ok() will call
valid_user_address() with the address after the last byte of the user
buffer.

It is valid for a buffer to end with the last valid user address so
valid_user_address() must allow accesses to the base of the guard page.

[ This introduces an off-by-one in the other direction for the plain
  non-sized accesses, but since we have that guard region that is a
  whole page, those checks "allowing" accesses to that guard region
  don't really matter. The access will fault anyway, whether to the
  guard page or if the address has been masked to all ones - Linus ]

Fixes: 86e6b1547b3d0 ("x86: fix user address masking non-canonical speculation issue")
Signed-off-by: David Laight &lt;david.laight@aculab.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>x86/microcode/AMD: Flush patch buffer mapping after application</title>
<updated>2024-11-25T10:43:21Z</updated>
<author>
<name>Borislav Petkov (AMD)</name>
<email>bp@alien8.de</email>
</author>
<published>2024-11-19T11:21:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=c809b0d0e52d01c30066367b2952c4c4186b1047'/>
<id>urn:sha1:c809b0d0e52d01c30066367b2952c4c4186b1047</id>
<content type='text'>
Due to specific requirements while applying microcode patches on Zen1
and 2, the patch buffer mapping needs to be flushed from the TLB after
application. Do so.

If not, unnecessary and unnatural delays happen in the boot process.

Reported-by: Thomas De Schampheleire &lt;thomas.de_schampheleire@nokia.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Tested-by: Thomas De Schampheleire &lt;thomas.de_schampheleire@nokia.com&gt;
Cc: &lt;stable@kernel.org&gt; # f1d84b59cbb9 ("x86/mm: Carve out INVLPG inline asm for use by others")
Link: https://lore.kernel.org/r/ZyulbYuvrkshfsd2@antipodes
</content>
</entry>
<entry>
<title>x86/cpu: Fix PPIN initialization</title>
<updated>2024-11-25T09:11:33Z</updated>
<author>
<name>Tony Luck</name>
<email>tony.luck@intel.com</email>
</author>
<published>2024-11-22T23:42:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=d9bb40544653cf039fe79225ec1d742183e2339a'/>
<id>urn:sha1:d9bb40544653cf039fe79225ec1d742183e2339a</id>
<content type='text'>
On systems that enumerate PPIN (protected processor inventory
number) using CPUID, but where the BIOS locked the MSR to
prevent access /proc/cpuinfo reports "intel_ppin" feature as
present on all logical CPUs except for CPU 0.

This happens because ppin_init() uses x86_match_cpu() to
determine whether PPIN is supported. When called on CPU 0
the test for locked PPIN MSR results in:

	clear_cpu_cap(c, info-&gt;feature);

This clears the X86 FEATURE bit in boot_cpu_data. When other
CPUs are brought online the x86_match_cpu() fails, and the
PPIN FEATURE bit remains set for those other CPUs.

Fix by using setup_clear_cpu_cap() instead of clear_cpu_cap()
which force clears the FEATURE bit for all CPUS.

Reported-by: Adeel Ashad &lt;adeel.arshad@intel.com&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20241122234212.27451-1-tony.luck@intel.com
</content>
</entry>
<entry>
<title>Merge tag 'x86_misc_for_6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2024-11-22T20:52:03Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-11-22T20:52:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=5af5d43f848e95019d0e018e67a7a341c6a5e00d'/>
<id>urn:sha1:5af5d43f848e95019d0e018e67a7a341c6a5e00d</id>
<content type='text'>
Pull misc x86 updates from Dave Hansen:
 "As usual for this branch, these are super random: a compile fix for
  some newish LLVM checks and making sure a Kconfig text reference to
  'RSB' matches the normal definition:

   - Rework some CPU setup code to keep LLVM happy on 32-bit

   - Correct RSB terminology in Kconfig text"

* tag 'x86_misc_for_6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/cpu: Make sure flag_is_changeable_p() is always being used
  x86/bugs: Correct RSB terminology in Kconfig
</content>
</entry>
</feed>
