<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/kernel/apic, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2015-10-28T02:13:06Z</updated>
<entry>
<title>x86/apic: Serialize LVTT and TSC_DEADLINE writes</title>
<updated>2015-10-28T02:13:06Z</updated>
<author>
<name>Shaohua Li</name>
</author>
<published>2015-07-30T23:24:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=51b366f06578c32bc97b7b35d827945cdae6f877'/>
<id>urn:sha1:51b366f06578c32bc97b7b35d827945cdae6f877</id>
<content type='text'>
[ Upstream commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 ]

The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
guaranteed that the write to LVTT has reached the APIC before the
TSC_DEADLINE MSR is written. In such a case the write to the MSR is
ignored and as a consequence the local timer interrupt never fires.

The SDM decribes this issue for xAPIC and x2APIC modes. The
serialization methods recommended by the SDM differ.

xAPIC:
 "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
  2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter.
  3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
  4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."

x2APIC:
 "To allow for efficient access to the APIC registers in x2APIC mode,
  the serializing semantics of WRMSR are relaxed when writing to the
  APIC registers. Thus, system software should not use 'WRMSR to APIC
  registers in x2APIC mode' as a serializing instruction. Read and write
  accesses to the APIC registers will occur in program order. A WRMSR to
  an APIC register may complete before all preceding stores are globally
  visible; software can prevent this by inserting a serializing
  instruction, an SFENCE, or an MFENCE before the WRMSR."

The xAPIC method is to just wait for the memory mapped write to hit
the LVTT by checking whether the MSR write has reached the hardware.
There is no reason why a proper MFENCE after the memory mapped write would
not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
xAPIC case as well.

Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
support.

[ tglx: Massaged the changelog ]

Signed-off-by: Shaohua Li &lt;shli@fb.com&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: &lt;Kernel-team@fb.com&gt;
Cc: &lt;lenb@kernel.org&gt;
Cc: &lt;fenghua.yu@intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: stable@vger.kernel.org #v3.7+
Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>x86: numachip: Fix 16-bit APIC ID truncation</title>
<updated>2015-03-28T14:08:32Z</updated>
<author>
<name>Daniel J Blueman</name>
</author>
<published>2014-11-04T08:29:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f8ac6343a34f407b237a7b7924f2182a1ddb7216'/>
<id>urn:sha1:f8ac6343a34f407b237a7b7924f2182a1ddb7216</id>
<content type='text'>
[ Upstream commit 00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f ]

Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes
booting large systems, where the wrong core would receive the startup and
init IPIs, causing hanging.

Signed-off-by: Daniel J Blueman &lt;daniel@numascale.com&gt;
Cc: Steffen Persvold &lt;sp@numascale.com&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: http://lkml.kernel.org/r/1415089784-28779-1-git-send-email-daniel@numascale.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v3.18-rc1' into x86/urgent</title>
<updated>2014-10-24T20:26:37Z</updated>
<author>
<name>H. Peter Anvin</name>
</author>
<published>2014-10-24T20:26:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=db65bcfd9563a7531c3dd46c350565705be1fd84'/>
<id>urn:sha1:db65bcfd9563a7531c3dd46c350565705be1fd84</id>
<content type='text'>
Reason:
Need to apply audit patch on top of v3.18-rc1.

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>x86, apic: Handle a bad TSC more gracefully</title>
<updated>2014-10-22T19:31:46Z</updated>
<author>
<name>Andy Lutomirski</name>
</author>
<published>2014-10-15T17:12:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b47dcbdc5161d3d5756f430191e2840d9b855492'/>
<id>urn:sha1:b47dcbdc5161d3d5756f430191e2840d9b855492</id>
<content type='text'>
If the TSC is unusable or disabled, then this patch fixes:

 - Confusion while trying to clear old APIC interrupts.
 - Division by zero and incorrect programming of the TSC deadline
   timer.

This fixes boot if the CPU has a TSC deadline timer but a missing or
broken TSC.  The failure to boot can be observed with qemu using
-cpu qemu64,-tsc,+tsc-deadline

This also happens to me in nested KVM for unknown reasons.
With this patch, I can boot cleanly (although without a TSC).

Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Bandan Das &lt;bsd@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/e2fa274e498c33988efac0ba8b7e3120f7f92d78.1413393027.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu</title>
<updated>2014-10-15T05:48:18Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-10-15T05:48:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0429fbc0bdc297d64188483ba029a23773ae07b0'/>
<id>urn:sha1:0429fbc0bdc297d64188483ba029a23773ae07b0</id>
<content type='text'>
Pull percpu consistent-ops changes from Tejun Heo:
 "Way back, before the current percpu allocator was implemented, static
  and dynamic percpu memory areas were allocated and handled separately
  and had their own accessors.  The distinction has been gone for many
  years now; however, the now duplicate two sets of accessors remained
  with the pointer based ones - this_cpu_*() - evolving various other
  operations over time.  During the process, we also accumulated other
  inconsistent operations.

  This pull request contains Christoph's patches to clean up the
  duplicate accessor situation.  __get_cpu_var() uses are replaced with
  with this_cpu_ptr() and __this_cpu_ptr() with raw_cpu_ptr().

  Unfortunately, the former sometimes is tricky thanks to C being a bit
  messy with the distinction between lvalues and pointers, which led to
  a rather ugly solution for cpumask_var_t involving the introduction of
  this_cpu_cpumask_var_ptr().

  This converts most of the uses but not all.  Christoph will follow up
  with the remaining conversions in this merge window and hopefully
  remove the obsolete accessors"

* 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (38 commits)
  irqchip: Properly fetch the per cpu offset
  percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t -fix
  ia64: sn_nodepda cannot be assigned to after this_cpu conversion. Use __this_cpu_write.
  percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t
  Revert "powerpc: Replace __get_cpu_var uses"
  percpu: Remove __this_cpu_ptr
  clocksource: Replace __this_cpu_ptr with raw_cpu_ptr
  sparc: Replace __get_cpu_var uses
  avr32: Replace __get_cpu_var with __this_cpu_write
  blackfin: Replace __get_cpu_var uses
  tile: Use this_cpu_ptr() for hardware counters
  tile: Replace __get_cpu_var uses
  powerpc: Replace __get_cpu_var uses
  alpha: Replace __get_cpu_var
  ia64: Replace __get_cpu_var uses
  s390: cio driver &amp;__get_cpu_var replacements
  s390: Replace __get_cpu_var uses
  mips: Replace __get_cpu_var uses
  MIPS: Replace __get_cpu_var uses in FPU emulator.
  arm: Replace __this_cpu_ptr with raw_cpu_ptr
  ...
</content>
</entry>
<entry>
<title>Merge branches 'x86-ras-for-linus', 'x86-uv-for-linus' and 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-10-14T00:31:22Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-10-14T00:31:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=77654908ff1a58cee4886298968b5262884aff0b'/>
<id>urn:sha1:77654908ff1a58cee4886298968b5262884aff0b</id>
<content type='text'>
Pull x86 ras, uv and vdso fixlets from Ingo Molnar:
 "ras: tone down a kernel message to only occur during initial bootup,
    not during suspend/resume cycles.

  uv: a cleanup commit

  vdso: a fix to error checking"

* 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mce: Avoid showing repetitive message from intel_init_thermal()

* 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic/uv: Remove unnecessary #ifdef

* 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/vdso: Fix vdso2c's special_pages[] error checking
</content>
</entry>
<entry>
<title>Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2014-10-14T00:28:16Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-10-14T00:28:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2fd7476de999124bbf6830aa59ac092c882280fe'/>
<id>urn:sha1:2fd7476de999124bbf6830aa59ac092c882280fe</id>
<content type='text'>
Pull x86 fixes from Ingo Molnar:
 "Misc smaller fixes that missed the v3.17 cycle"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/build: Add arch/x86/purgatory/ make generated files to gitignore
  x86: Fix section conflict for numachip
  x86: Reject x32 executables if x32 ABI not supported
  x86_64, entry: Filter RFLAGS.NT on entry from userspace
  x86, boot, kaslr: Fix nuisance warning on 32-bit builds
</content>
</entry>
<entry>
<title>x86: Fix section conflict for numachip</title>
<updated>2014-10-08T09:18:49Z</updated>
<author>
<name>Andi Kleen</name>
</author>
<published>2014-09-24T04:32:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2dee5c43da3a981489a4f18972827139afcbee82'/>
<id>urn:sha1:2dee5c43da3a981489a4f18972827139afcbee82</id>
<content type='text'>
A variable cannot be both __read_mostly and const. This
is a meaningless combination.

Just make it only const.

This fixes the LTO build with numachip enabled.

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/1411533139-25708-1-git-send-email-andi@firstfloor.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
</entry>
<entry>
<title>percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t -fix</title>
<updated>2014-09-08T22:17:43Z</updated>
<author>
<name>Mel Gorman</name>
</author>
<published>2014-09-08T22:06:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=59f6e2073c72d36c814a4417320bfa4874faa228'/>
<id>urn:sha1:59f6e2073c72d36c814a4417320bfa4874faa228</id>
<content type='text'>
A commit in linux-next was causing boot to fail and bisection
identified the patch 4ba2968420fa ("percpu: Resolve ambiguities in
__get_cpu_var/cpumask_var_").  One of the changes in that patch looks
very suspicious.  Reverting the full patch fixes boot as does this
fixlet.

Signed-off-by: Mel Gorman &lt;mgorman@suse.de&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Christoph Lameter &lt;cl@linux.com&gt;
</content>
</entry>
<entry>
<title>x86 / PM: Set IRQCHIP_SKIP_SET_WAKE for IOAPIC IRQ chip objects</title>
<updated>2014-09-01T11:49:07Z</updated>
<author>
<name>Rafael J. Wysocki</name>
</author>
<published>2014-09-01T11:49:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5613570b133a294355d35fa66162afe7607a8abb'/>
<id>urn:sha1:5613570b133a294355d35fa66162afe7607a8abb</id>
<content type='text'>
Set the IRQCHIP_SKIP_SET_WAKE for IOAPIC IRQ chip objects so that
interrupts from them can work as wakeup interrupts for suspend-to-idle.

After this change, running enable_irq_wake() on one of the IRQs in
question will succeed and IRQD_WAKEUP_STATE will be set for it, so
all of the suspend-to-idle wakeup mechanics introduced previously
will work for it automatically.

Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
