<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/include/asm/cpu.h, branch linux-4.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-07-27T18:35:37Z</updated>
<entry>
<title>Merge tag 'for-linus-4.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip</title>
<updated>2016-07-27T18:35:37Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2016-07-27T18:35:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=08fd8c17686c6b09fa410a26d516548dd80ff147'/>
<id>urn:sha1:08fd8c17686c6b09fa410a26d516548dd80ff147</id>
<content type='text'>
Pull xen updates from David Vrabel:
 "Features and fixes for 4.8-rc0:

   - ACPI support for guests on ARM platforms.
   - Generic steal time support for arm and x86.
   - Support cases where kernel cpu is not Xen VCPU number (e.g., if
     in-guest kexec is used).
   - Use the system workqueue instead of a custom workqueue in various
     places"

* tag 'for-linus-4.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: (47 commits)
  xen: add static initialization of steal_clock op to xen_time_ops
  xen/pvhvm: run xen_vcpu_setup() for the boot CPU
  xen/evtchn: use xen_vcpu_id mapping
  xen/events: fifo: use xen_vcpu_id mapping
  xen/events: use xen_vcpu_id mapping in events_base
  x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to shared_info
  x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op
  xen: introduce xen_vcpu_id mapping
  x86/acpi: store ACPI ids from MADT for future usage
  x86/xen: update cpuid.h from Xen-4.7
  xen/evtchn: add IOCTL_EVTCHN_RESTRICT
  xen-blkback: really don't leak mode property
  xen-blkback: constify instance of "struct attribute_group"
  xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
  xen-blkback: prefer xenbus_scanf() over xenbus_gather()
  xen: support runqueue steal time on xen
  arm/xen: add support for vm_assist hypercall
  xen: update xen headers
  xen-pciback: drop superfluous variables
  xen-pciback: short-circuit read path used for merging write values
  ...
</content>
</entry>
<entry>
<title>x86/acpi: store ACPI ids from MADT for future usage</title>
<updated>2016-07-25T12:30:53Z</updated>
<author>
<name>Vitaly Kuznetsov</name>
</author>
<published>2016-06-30T15:56:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3e9e57fad3d8530aa30787f861c710f598ddc4e7'/>
<id>urn:sha1:3e9e57fad3d8530aa30787f861c710f598ddc4e7</id>
<content type='text'>
Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids diverge from Linux's cpu ids.

Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
</content>
</entry>
<entry>
<title>x86/smp: Remove stack_smp_processor_id()</title>
<updated>2016-07-15T08:26:30Z</updated>
<author>
<name>Andy Lutomirski</name>
</author>
<published>2016-07-14T20:22:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fb59831b496a5bb7d0a06c7e702d88d1757edfca'/>
<id>urn:sha1:fb59831b496a5bb7d0a06c7e702d88d1757edfca</id>
<content type='text'>
It serves no purpose -- raw_smp_processor_id() works fine.  This
change will be needed to move thread_info off the stack.

Signed-off-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/a2bf4f07fbc30fb32f9f7f3f8f94ad3580823847.1468527351.git.luto@kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/cpu: Unify CPU family, model, stepping calculation</title>
<updated>2015-11-24T08:15:54Z</updated>
<author>
<name>Borislav Petkov</name>
</author>
<published>2015-11-23T10:12:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=99f925ce927e4ac313d9af8bd1bf55796e2cdcb1'/>
<id>urn:sha1:99f925ce927e4ac313d9af8bd1bf55796e2cdcb1</id>
<content type='text'>
Add generic functions which calc family, model and stepping from
the CPUID_1.EAX leaf and stick them into the library we have.

Rename those which do call CPUID with the prefix "x86_cpuid" as
suggested by Paolo Bonzini.

No functionality change.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/1448273546-2567-2-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86: Use common outgoing-CPU-notification code</title>
<updated>2015-03-11T20:22:35Z</updated>
<author>
<name>Paul E. McKenney</name>
</author>
<published>2015-02-25T19:42:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2a442c9c6453d3d043dfd89f2e03a1deff8a6f06'/>
<id>urn:sha1:2a442c9c6453d3d043dfd89f2e03a1deff8a6f06</id>
<content type='text'>
This commit removes the open-coded CPU-offline notification with new
common code.  Among other things, this change avoids calling scheduler
code using RCU from an offline CPU that RCU is ignoring.  It also allows
Xen to notice at online time that the CPU did not go offline correctly.
Note that Xen has the surviving CPU carry out some cleanup operations,
so if the surviving CPU times out, these cleanup operations might have
been carried out while the outgoing CPU was still running.  It might
therefore be unwise to bring this CPU back online, and this commit
avoids doing so.

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: &lt;x86@kernel.org&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: David Vrabel &lt;david.vrabel@citrix.com&gt;
Cc: &lt;xen-devel@lists.xenproject.org&gt;
</content>
</entry>
<entry>
<title>x86: delete __cpuinit usage from all x86 files</title>
<updated>2013-07-14T23:36:56Z</updated>
<author>
<name>Paul Gortmaker</name>
</author>
<published>2013-06-18T22:23:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=148f9bb87745ed45f7a11b2cbd3bc0f017d5d257'/>
<id>urn:sha1:148f9bb87745ed45f7a11b2cbd3bc0f017d5d257</id>
<content type='text'>
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit  -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings.  In any case, they are temporary and harmless.

This removes all the arch/x86 uses of the __cpuinit macros from
all C files.  x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: x86@kernel.org
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
</entry>
<entry>
<title>x86, topology: Debug CPU0 hotplug</title>
<updated>2012-11-14T23:28:11Z</updated>
<author>
<name>Fenghua Yu</name>
</author>
<published>2012-11-13T19:32:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a71c8bc5dfefbbf80ef90739791554ef7ea4401b'/>
<id>urn:sha1:a71c8bc5dfefbbf80ef90739791554ef7ea4401b</id>
<content type='text'>
CONFIG_DEBUG_HOTPLUG_CPU0 is for debugging the CPU0 hotplug feature. The switch
offlines CPU0 as soon as possible and boots userspace up with CPU0 offlined.
User can online CPU0 back after boot time. The default value of the switch is
off.

To debug CPU0 hotplug, you need to enable CPU0 offline/online feature by either
turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during compilation or giving
cpu0_hotplug kernel parameter at boot.

It's safe and early place to take down CPU0 after all hotplug notifiers
are installed and SMP is booted.

Please note that some applications or drivers, e.g. some versions of udevd,
during boot time may put CPU0 online again in this CPU0 hotplug debug mode.

In this debug mode, setup_local_APIC() may report a warning on max_loops&lt;=0
when CPU0 is onlined back after boot time. This is because pending interrupt in
IRR can not move to ISR. The warning is not CPU0 specfic and it can happen on
other CPUs as well. It is harmless except the first CPU0 online takes a bit
longer time. And so this debug mode is useful to expose this issue. I'll send
a seperate patch to fix this generic warning issue.

Signed-off-by: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Link: http://lkml.kernel.org/r/1352835171-3958-15-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>x86, hotplug: Wake up CPU0 via NMI instead of INIT, SIPI, SIPI</title>
<updated>2012-11-14T23:28:03Z</updated>
<author>
<name>Fenghua Yu</name>
</author>
<published>2012-11-14T12:36:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e1c467e69040c3be68959332959c07fb3d818e87'/>
<id>urn:sha1:e1c467e69040c3be68959332959c07fb3d818e87</id>
<content type='text'>
Instead of waiting for STARTUP after INITs, BSP will execute the BIOS boot-strap
code which is not a desired behavior for waking up BSP. To avoid the boot-strap
code, wake up CPU0 by NMI instead.

This works to wake up soft offlined CPU0 only. If CPU0 is hard offlined (i.e.
physically hot removed and then hot added), NMI won't wake it up. We'll change
this code in the future to wake up hard offlined CPU0 if real platform and
request are available.

AP is still waken up as before by INIT, SIPI, SIPI sequence.

Signed-off-by: Fenghua Yu &lt;fenghua.yu@intel.com&gt;
Link: http://lkml.kernel.org/r/1352896613-25957-1-git-send-email-fenghua.yu@intel.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>x86: Fix mwait_usable section mismatch</title>
<updated>2011-02-14T11:08:28Z</updated>
<author>
<name>Borislav Petkov</name>
</author>
<published>2011-02-11T17:17:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1c9d16e35911090dee3f9313e6af13af623d66ee'/>
<id>urn:sha1:1c9d16e35911090dee3f9313e6af13af623d66ee</id>
<content type='text'>
We use it in non __cpuinit code now too so drop marker.

Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
LKML-Reference: &lt;20110211171754.GA21047@aftab&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86, hotplug: Fix powersavings with offlined cores on AMD</title>
<updated>2011-01-22T02:14:54Z</updated>
<author>
<name>Borislav Petkov</name>
</author>
<published>2011-01-20T14:42:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=93789b32dbf355e70f18b17a82e8661677a7f7fb'/>
<id>urn:sha1:93789b32dbf355e70f18b17a82e8661677a7f7fb</id>
<content type='text'>
ea53069231f9317062910d6e772cca4ce93de8c8 made a CPU use monitor/mwait
when offline. This is not the optimal choice for AMD wrt to powersavings
and we'd prefer our cores to halt (i.e. enter C1) instead. For this, the
same selection whether to use monitor/mwait has to be used as when we
select the idle routine for the machine.

With this patch, offlining cores 1-5 on a X6 machine allows core0 to
boost again.

[ hpa: putting this in urgent since it is a (power) regression fix ]

Reported-by: Andreas Herrmann &lt;andreas.herrmann3@amd.com&gt;
Cc: stable@kernel.org # 37.x
Cc: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: Venkatesh Pallipadi &lt;venki@google.com&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.hl&gt;
Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
LKML-Reference: &lt;1295534572-10730-1-git-send-email-bp@amd64.org&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
</content>
</entry>
</feed>
