<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/kernel/apic, branch linux-5.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-06-09T08:30:06Z</updated>
<entry>
<title>x86: Fix return value of __setup handlers</title>
<updated>2022-06-09T08:30:06Z</updated>
<author>
<name>Randy Dunlap</name>
</author>
<published>2022-03-14T01:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a81340705c9754bbb812c8191c42d6643b9de8c6'/>
<id>urn:sha1:a81340705c9754bbb812c8191c42d6643b9de8c6</id>
<content type='text'>
[ Upstream commit 12441ccdf5e2f5a01a46e344976cbbd3d46845c9 ]

__setup() handlers should return 1 to obsolete_checksetup() in
init/main.c to indicate that the boot option has been handled. A return
of 0 causes the boot option/value to be listed as an Unknown kernel
parameter and added to init's (limited) argument (no '=') or environment
(with '=') strings. So return 1 from these x86 __setup handlers.

Examples:

  Unknown kernel command line parameters "apicpmtimer
    BOOT_IMAGE=/boot/bzImage-517rc8 vdso=1 ring3mwait=disable", will be
    passed to user space.

  Run /sbin/init as init process
   with arguments:
     /sbin/init
     apicpmtimer
   with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc8
     vdso=1
     ring3mwait=disable

Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
Fixes: 77b52b4c5c66 ("x86: add "debugpat" boot option")
Fixes: e16fd002afe2 ("x86/cpufeature: Enable RING3MWAIT for Knights Landing")
Fixes: b8ce33590687 ("x86_64: convert to clock events")
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Link: https://lore.kernel.org/r/20220314012725.26661-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/platform/uv: Update TSC sync state for UV5</title>
<updated>2022-06-09T08:29:33Z</updated>
<author>
<name>Mike Travis</name>
</author>
<published>2022-04-06T19:51:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df3ea29d649d9daede5d4b74fc146173d518e0ed'/>
<id>urn:sha1:df3ea29d649d9daede5d4b74fc146173d518e0ed</id>
<content type='text'>
[ Upstream commit bb3ab81bdbd53f88f26ffabc9fb15bd8466486ec ]

The UV5 platform synchronizes the TSCs among all chassis, and will not
proceed to OS boot without achieving synchronization.  Previous UV
platforms provided a register indicating successful synchronization.
This is no longer available on UV5.  On this platform TSC_ADJUST
should not be reset by the kernel.

Signed-off-by: Mike Travis &lt;mike.travis@hpe.com&gt;
Signed-off-by: Steve Wahl &lt;steve.wahl@hpe.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Dimitri Sivanich &lt;dimitri.sivanich@hpe.com&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/20220406195149.228164-3-steve.wahl@hpe.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'bitmap-5.17-rc1' of git://github.com/norov/linux</title>
<updated>2022-01-23T04:20:44Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2022-01-23T04:20:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3689f9f8b0c52dfd8f5995e4b58917f8f3ac3ee3'/>
<id>urn:sha1:3689f9f8b0c52dfd8f5995e4b58917f8f3ac3ee3</id>
<content type='text'>
Pull bitmap updates from Yury Norov:

 - introduce for_each_set_bitrange()

 - use find_first_*_bit() instead of find_next_*_bit() where possible

 - unify for_each_bit() macros

* tag 'bitmap-5.17-rc1' of git://github.com/norov/linux:
  vsprintf: rework bitmap_list_string
  lib: bitmap: add performance test for bitmap_print_to_pagebuf
  bitmap: unify find_bit operations
  mm/percpu: micro-optimize pcpu_is_populated()
  Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
  find: micro-optimize for_each_{set,clear}_bit()
  include/linux: move for_each_bit() macros from bitops.h to find.h
  cpumask: replace cpumask_next_* with cpumask_first_* where appropriate
  tools: sync tools/bitmap with mother linux
  all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
  cpumask: use find_first_and_bit()
  lib: add find_first_and_bit()
  arch: remove GENERIC_FIND_FIRST_BIT entirely
  include: move find.h from asm_generic to linux
  bitops: move find_bit_*_le functions from le.h to find.h
  bitops: protect find_first_{,zero}_bit properly
</content>
</entry>
<entry>
<title>Replace for_each_*_bit_from() with for_each_*_bit() where appropriate</title>
<updated>2022-01-15T16:47:31Z</updated>
<author>
<name>Yury Norov</name>
</author>
<published>2021-08-14T21:17:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=749443de8dde3b8b420ee8b4daac4d929a6adeb9'/>
<id>urn:sha1:749443de8dde3b8b420ee8b4daac4d929a6adeb9</id>
<content type='text'>
A couple of kernel functions call for_each_*_bit_from() with start
bit equal to 0. Replace them with for_each_*_bit().

No functional changes, but might improve on readability.

Signed-off-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Tested-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
</content>
</entry>
<entry>
<title>x86/apic/msi: Use PCI device MSI property</title>
<updated>2021-12-16T21:16:37Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2021-12-10T22:18:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b3f82364117a0b7f666ce023195b636c4803c46c'/>
<id>urn:sha1:b3f82364117a0b7f666ce023195b636c4803c46c</id>
<content type='text'>
instead of fiddling with MSI descriptors.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Link: https://lore.kernel.org/r/20211210221813.372357371@linutronix.de

</content>
</entry>
<entry>
<title>PCI/MSI: Make arch_restore_msi_irqs() less horrible.</title>
<updated>2021-12-09T10:52:21Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2021-12-06T22:27:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ae72f3156729541581f526b85883ca53a20df2fa'/>
<id>urn:sha1:ae72f3156729541581f526b85883ca53a20df2fa</id>
<content type='text'>
Make arch_restore_msi_irqs() return a boolean which indicates whether the
core code should restore the MSI message or not. Get rid of the indirection
in x86.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;	# PCI
Link: https://lore.kernel.org/r/20211206210224.485668098@linutronix.de

</content>
</entry>
<entry>
<title>genirq/msi, treewide: Use a named struct for PCI/MSI attributes</title>
<updated>2021-12-09T10:52:21Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2021-12-06T22:27:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e58f2259b91c02974c20db7b28d39d810a21249b'/>
<id>urn:sha1:e58f2259b91c02974c20db7b28d39d810a21249b</id>
<content type='text'>
The unnamed struct sucks and is in the way of further cleanups. Stick the
PCI related MSI data into a real data structure and cleanup all users.

No functional change.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20211206210224.374863119@linutronix.de

</content>
</entry>
<entry>
<title>x86/apic: Reduce cache line misses in __x2apic_send_IPI_mask()</title>
<updated>2021-10-29T08:02:17Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2021-10-07T14:35:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cc95a07fef06a2c7917acd827b3a8322772969eb'/>
<id>urn:sha1:cc95a07fef06a2c7917acd827b3a8322772969eb</id>
<content type='text'>
Using per-cpu storage for @x86_cpu_to_logical_apicid is not optimal.

Broadcast IPI will need at least one cache line per cpu to access this
field.

__x2apic_send_IPI_mask() is using standard bitmask operators.

By converting x86_cpu_to_logical_apicid to an array, we divide by 16x
number of needed cache lines, because we find 16 values per cache
line. CPU prefetcher can kick nicely.

Also move @cluster_masks to READ_MOSTLY section to avoid false sharing.

Tested on a dual socket host with 256 cpus, cost for a full broadcast
is now 11 usec instead of 33 usec.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lkml.kernel.org/r/20211007143556.574911-1-eric.dumazet@gmail.com
</content>
</entry>
<entry>
<title>Merge tag 'x86-irq-2021-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2021-08-30T22:20:05Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2021-08-30T22:20:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ccd8ec4a3f9a5d3d97766231b04e7321dcc2df1e'/>
<id>urn:sha1:ccd8ec4a3f9a5d3d97766231b04e7321dcc2df1e</id>
<content type='text'>
Pull x86 PIRQ updates from Thomas Gleixner:
 "A set of updates to support port 0x22/0x23 based PCI configuration
  space which can be found on various ALi chipsets and is also available
  on older Intel systems which expose a PIRQ router.

  While the Intel support is more or less nostalgia, the ALi chips are
  still in use on popular embedded boards used for routers"

* tag 'x86-irq-2021-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Fix typo s/ECLR/ELCR/ for the PIC register
  x86: Avoid magic number with ELCR register accesses
  x86/PCI: Add support for the Intel 82426EX PIRQ router
  x86/PCI: Add support for the Intel 82374EB/82374SB (ESC) PIRQ router
  x86/PCI: Add support for the ALi M1487 (IBC) PIRQ router
  x86: Add support for 0x22/0x23 port I/O configuration space
</content>
</entry>
<entry>
<title>x86: Avoid magic number with ELCR register accesses</title>
<updated>2021-08-10T21:31:43Z</updated>
<author>
<name>Maciej W. Rozycki</name>
</author>
<published>2021-07-20T03:28:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d25316616842b593de6f89ce2101f1af62f4d559'/>
<id>urn:sha1:d25316616842b593de6f89ce2101f1af62f4d559</id>
<content type='text'>
Define PIC_ELCR1 and PIC_ELCR2 macros for accesses to the ELCR registers 
implemented by many chipsets in their embedded 8259A PIC cores, avoiding 
magic numbers that are difficult to handle, and complementing the macros 
we already have for registers originally defined with discrete 8259A PIC 
implementations.  No functional change.

Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2107200237300.9461@angie.orcam.me.uk

</content>
</entry>
</feed>
