<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch, branch v3.4.84</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>KVM: SVM: fix cr8 intercept window</title>
<updated>2014-03-24T04:37:07+00:00</updated>
<author>
<name>Radim Krčmář</name>
<email>rkrcmar@redhat.com</email>
</author>
<published>2014-03-11T18:11:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=18bd55f61fa9f46082820741d753b3b919244d8a'/>
<id>18bd55f61fa9f46082820741d753b3b919244d8a</id>
<content type='text'>
commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream.

We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.

Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.

Signed-off-by: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Reviewed-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream.

We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.

Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.

Signed-off-by: Radim Krčmář &lt;rkrcmar@redhat.com&gt;
Reviewed-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/amd/numa: Fix northbridge quirk to assign correct NUMA node</title>
<updated>2014-03-24T04:37:05+00:00</updated>
<author>
<name>Daniel J Blueman</name>
<email>daniel@numascale.com</email>
</author>
<published>2014-03-13T11:43:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bb7d79fc8250eaa01ac6f82f9001ffcec0e7ca36'/>
<id>bb7d79fc8250eaa01ac6f82f9001ffcec0e7ca36</id>
<content type='text'>
commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream.

For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most
systems.

Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.

Signed-off-by: Daniel J Blueman &lt;daniel@numascale.com&gt;
Acked-by: Steffen Persvold &lt;sp@numascale.com&gt;
Acked-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream.

For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most
systems.

Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.

Signed-off-by: Daniel J Blueman &lt;daniel@numascale.com&gt;
Acked-by: Steffen Persvold &lt;sp@numascale.com&gt;
Acked-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 7991/1: sa1100: fix compile problem on Collie</title>
<updated>2014-03-24T04:37:05+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2014-02-25T21:41:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8271b4d83a6f070ba1cd3a6e4fab36dcf7c2207a'/>
<id>8271b4d83a6f070ba1cd3a6e4fab36dcf7c2207a</id>
<content type='text'>
commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream.

Due to a problem in the MFD Kconfig it was not possible to
compile the UCB battery driver for the Collie SA1100 system,
in turn making it impossible to compile in the battery driver.
(See patch "mfd: include all drivers in subsystem menu".)

After fixing the MFD Kconfig (separate patch) a compile error
appears in the Collie battery driver due to the &lt;mach/collie.h&gt;
implicitly requiring &lt;mach/hardware.h&gt; through &lt;linux/gpio.h&gt;
via &lt;mach/gpio.h&gt; prior to commit
40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".

Fix this up by including the required header into
&lt;mach/collie.h&gt;.

Cc: Andrea Adami &lt;andrea.adami@gmail.com&gt;
Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream.

Due to a problem in the MFD Kconfig it was not possible to
compile the UCB battery driver for the Collie SA1100 system,
in turn making it impossible to compile in the battery driver.
(See patch "mfd: include all drivers in subsystem menu".)

After fixing the MFD Kconfig (separate patch) a compile error
appears in the Collie battery driver due to the &lt;mach/collie.h&gt;
implicitly requiring &lt;mach/hardware.h&gt; through &lt;linux/gpio.h&gt;
via &lt;mach/gpio.h&gt; prior to commit
40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".

Fix this up by including the required header into
&lt;mach/collie.h&gt;.

Cc: Andrea Adami &lt;andrea.adami@gmail.com&gt;
Cc: Dmitry Eremin-Solenikov &lt;dbaryshkov@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc: Align p_dyn, p_rela and p_st symbols</title>
<updated>2014-03-24T04:37:05+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-03-03T21:31:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ec012303c26a1d4d6251d74401ee290a063154ac'/>
<id>ec012303c26a1d4d6251d74401ee290a063154ac</id>
<content type='text'>
commit a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67 upstream.

The 64bit relocation code places a few symbols in the text segment.
These symbols are only 4 byte aligned where they need to be 8 byte
aligned. Add an explicit alignment.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Tested-by: Laurent Dufour &lt;ldufour@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67 upstream.

The 64bit relocation code places a few symbols in the text segment.
These symbols are only 4 byte aligned where they need to be 8 byte
aligned. Add an explicit alignment.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Tested-by: Laurent Dufour &lt;ldufour@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/smp/spinlock: Fix leakage of the spinlock interrupt line for every CPU online/offline</title>
<updated>2014-03-11T23:10:06+00:00</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2013-04-16T18:08:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=63f12e8d2bea38715b30a6051325230f6ec25a3b'/>
<id>63f12e8d2bea38715b30a6051325230f6ec25a3b</id>
<content type='text'>
commit 66ff0fe9e7bda8aec99985b24daad03652f7304e upstream.

While we don't use the spinlock interrupt line (see for details
commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23 -
xen: disable PV spinlocks on HVM) - we should still do the proper
init / deinit sequence. We did not do that correctly and for the
CPU init for PVHVM guest we would allocate an interrupt line - but
failed to deallocate the old interrupt line.

This resulted in leakage of an irq_desc but more importantly this splat
as we online an offlined CPU:

genirq: Flags mismatch irq 71. 0002cc20 (spinlock1) vs. 0002cc20 (spinlock1)
Pid: 2542, comm: init.late Not tainted 3.9.0-rc6upstream #1
Call Trace:
 [&lt;ffffffff811156de&gt;] __setup_irq+0x23e/0x4a0
 [&lt;ffffffff81194191&gt;] ? kmem_cache_alloc_trace+0x221/0x250
 [&lt;ffffffff811161bb&gt;] request_threaded_irq+0xfb/0x160
 [&lt;ffffffff8104c6f0&gt;] ? xen_spin_trylock+0x20/0x20
 [&lt;ffffffff813a8423&gt;] bind_ipi_to_irqhandler+0xa3/0x160
 [&lt;ffffffff81303758&gt;] ? kasprintf+0x38/0x40
 [&lt;ffffffff8104c6f0&gt;] ? xen_spin_trylock+0x20/0x20
 [&lt;ffffffff810cad35&gt;] ? update_max_interval+0x15/0x40
 [&lt;ffffffff816605db&gt;] xen_init_lock_cpu+0x3c/0x78
 [&lt;ffffffff81660029&gt;] xen_hvm_cpu_notify+0x29/0x33
 [&lt;ffffffff81676bdd&gt;] notifier_call_chain+0x4d/0x70
 [&lt;ffffffff810bb2a9&gt;] __raw_notifier_call_chain+0x9/0x10
 [&lt;ffffffff8109402b&gt;] __cpu_notify+0x1b/0x30
 [&lt;ffffffff8166834a&gt;] _cpu_up+0xa0/0x14b
 [&lt;ffffffff816684ce&gt;] cpu_up+0xd9/0xec
 [&lt;ffffffff8165f754&gt;] store_online+0x94/0xd0
 [&lt;ffffffff8141d15b&gt;] dev_attr_store+0x1b/0x20
 [&lt;ffffffff81218f44&gt;] sysfs_write_file+0xf4/0x170
 [&lt;ffffffff811a2864&gt;] vfs_write+0xb4/0x130
 [&lt;ffffffff811a302a&gt;] sys_write+0x5a/0xa0
 [&lt;ffffffff8167ada9&gt;] system_call_fastpath+0x16/0x1b
cpu 1 spinlock event irq -16
smpboot: Booting Node 0 Processor 1 APIC 0x2

And if one looks at the /proc/interrupts right after
offlining (CPU1):

  70:          0          0  xen-percpu-ipi       spinlock0
  71:          0          0  xen-percpu-ipi       spinlock1
  77:          0          0  xen-percpu-ipi       spinlock2

There is the oddity of the 'spinlock1' still being present.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 66ff0fe9e7bda8aec99985b24daad03652f7304e upstream.

While we don't use the spinlock interrupt line (see for details
commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23 -
xen: disable PV spinlocks on HVM) - we should still do the proper
init / deinit sequence. We did not do that correctly and for the
CPU init for PVHVM guest we would allocate an interrupt line - but
failed to deallocate the old interrupt line.

This resulted in leakage of an irq_desc but more importantly this splat
as we online an offlined CPU:

genirq: Flags mismatch irq 71. 0002cc20 (spinlock1) vs. 0002cc20 (spinlock1)
Pid: 2542, comm: init.late Not tainted 3.9.0-rc6upstream #1
Call Trace:
 [&lt;ffffffff811156de&gt;] __setup_irq+0x23e/0x4a0
 [&lt;ffffffff81194191&gt;] ? kmem_cache_alloc_trace+0x221/0x250
 [&lt;ffffffff811161bb&gt;] request_threaded_irq+0xfb/0x160
 [&lt;ffffffff8104c6f0&gt;] ? xen_spin_trylock+0x20/0x20
 [&lt;ffffffff813a8423&gt;] bind_ipi_to_irqhandler+0xa3/0x160
 [&lt;ffffffff81303758&gt;] ? kasprintf+0x38/0x40
 [&lt;ffffffff8104c6f0&gt;] ? xen_spin_trylock+0x20/0x20
 [&lt;ffffffff810cad35&gt;] ? update_max_interval+0x15/0x40
 [&lt;ffffffff816605db&gt;] xen_init_lock_cpu+0x3c/0x78
 [&lt;ffffffff81660029&gt;] xen_hvm_cpu_notify+0x29/0x33
 [&lt;ffffffff81676bdd&gt;] notifier_call_chain+0x4d/0x70
 [&lt;ffffffff810bb2a9&gt;] __raw_notifier_call_chain+0x9/0x10
 [&lt;ffffffff8109402b&gt;] __cpu_notify+0x1b/0x30
 [&lt;ffffffff8166834a&gt;] _cpu_up+0xa0/0x14b
 [&lt;ffffffff816684ce&gt;] cpu_up+0xd9/0xec
 [&lt;ffffffff8165f754&gt;] store_online+0x94/0xd0
 [&lt;ffffffff8141d15b&gt;] dev_attr_store+0x1b/0x20
 [&lt;ffffffff81218f44&gt;] sysfs_write_file+0xf4/0x170
 [&lt;ffffffff811a2864&gt;] vfs_write+0xb4/0x130
 [&lt;ffffffff811a302a&gt;] sys_write+0x5a/0xa0
 [&lt;ffffffff8167ada9&gt;] system_call_fastpath+0x16/0x1b
cpu 1 spinlock event irq -16
smpboot: Booting Node 0 Processor 1 APIC 0x2

And if one looks at the /proc/interrupts right after
offlining (CPU1):

  70:          0          0  xen-percpu-ipi       spinlock0
  71:          0          0  xen-percpu-ipi       spinlock1
  77:          0          0  xen-percpu-ipi       spinlock2

There is the oddity of the 'spinlock1' still being present.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/smp: Fix leakage of timer interrupt line for every CPU online/offline.</title>
<updated>2014-03-11T23:10:06+00:00</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2013-04-16T17:49:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=32ed904ec15d37d35afae9ce784951ec955d20a5'/>
<id>32ed904ec15d37d35afae9ce784951ec955d20a5</id>
<content type='text'>
commit 888b65b4bc5e7fcbbb967023300cd5d44dba1950 upstream.

In the PVHVM path when we do CPU online/offline path we would
leak the timer%d IRQ line everytime we do a offline event. The
online path (xen_hvm_setup_cpu_clockevents via
x86_cpuinit.setup_percpu_clockev) would allocate a new interrupt
line for the timer%d.

But we would still use the old interrupt line leading to:

kernel BUG at /home/konrad/ssd/konrad/linux/kernel/hrtimer.c:1261!
invalid opcode: 0000 [#1] SMP
RIP: 0010:[&lt;ffffffff810b9e21&gt;]  [&lt;ffffffff810b9e21&gt;] hrtimer_interrupt+0x261/0x270
.. snip..
 &lt;IRQ&gt;
 [&lt;ffffffff810445ef&gt;] xen_timer_interrupt+0x2f/0x1b0
 [&lt;ffffffff81104825&gt;] ? stop_machine_cpu_stop+0xb5/0xf0
 [&lt;ffffffff8111434c&gt;] handle_irq_event_percpu+0x7c/0x240
 [&lt;ffffffff811175b9&gt;] handle_percpu_irq+0x49/0x70
 [&lt;ffffffff813a74a3&gt;] __xen_evtchn_do_upcall+0x1c3/0x2f0
 [&lt;ffffffff813a760a&gt;] xen_evtchn_do_upcall+0x2a/0x40
 [&lt;ffffffff8167c26d&gt;] xen_hvm_callback_vector+0x6d/0x80
 &lt;EOI&gt;
 [&lt;ffffffff81666d01&gt;] ? start_secondary+0x193/0x1a8
 [&lt;ffffffff81666cfd&gt;] ? start_secondary+0x18f/0x1a8

There is also the oddity (timer1) in the /proc/interrupts after
offlining CPU1:

  64:       1121          0  xen-percpu-virq      timer0
  78:          0          0  xen-percpu-virq      timer1
  84:          0       2483  xen-percpu-virq      timer2

This patch fixes it.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 888b65b4bc5e7fcbbb967023300cd5d44dba1950 upstream.

In the PVHVM path when we do CPU online/offline path we would
leak the timer%d IRQ line everytime we do a offline event. The
online path (xen_hvm_setup_cpu_clockevents via
x86_cpuinit.setup_percpu_clockev) would allocate a new interrupt
line for the timer%d.

But we would still use the old interrupt line leading to:

kernel BUG at /home/konrad/ssd/konrad/linux/kernel/hrtimer.c:1261!
invalid opcode: 0000 [#1] SMP
RIP: 0010:[&lt;ffffffff810b9e21&gt;]  [&lt;ffffffff810b9e21&gt;] hrtimer_interrupt+0x261/0x270
.. snip..
 &lt;IRQ&gt;
 [&lt;ffffffff810445ef&gt;] xen_timer_interrupt+0x2f/0x1b0
 [&lt;ffffffff81104825&gt;] ? stop_machine_cpu_stop+0xb5/0xf0
 [&lt;ffffffff8111434c&gt;] handle_irq_event_percpu+0x7c/0x240
 [&lt;ffffffff811175b9&gt;] handle_percpu_irq+0x49/0x70
 [&lt;ffffffff813a74a3&gt;] __xen_evtchn_do_upcall+0x1c3/0x2f0
 [&lt;ffffffff813a760a&gt;] xen_evtchn_do_upcall+0x2a/0x40
 [&lt;ffffffff8167c26d&gt;] xen_hvm_callback_vector+0x6d/0x80
 &lt;EOI&gt;
 [&lt;ffffffff81666d01&gt;] ? start_secondary+0x193/0x1a8
 [&lt;ffffffff81666cfd&gt;] ? start_secondary+0x18f/0x1a8

There is also the oddity (timer1) in the /proc/interrupts after
offlining CPU1:

  64:       1121          0  xen-percpu-virq      timer0
  78:          0          0  xen-percpu-virq      timer1
  84:          0       2483  xen-percpu-virq      timer2

This patch fixes it.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/boot: Disable BIOS SMP MP table search.</title>
<updated>2014-03-11T23:10:06+00:00</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2012-09-19T12:30:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=79b6a2d6bd21bf90b38dbad0cf9210235944e8f9'/>
<id>79b6a2d6bd21bf90b38dbad0cf9210235944e8f9</id>
<content type='text'>
commit bd49940a35ec7d488ae63bd625639893b3385b97 upstream.

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f-&gt;100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f-&gt;100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff81ac07e2&gt;] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [&lt;ffffffff81ad31c6&gt;] __early_ioremap+0x18a/0x248
 [&lt;ffffffff81624731&gt;] ? printk+0x48/0x4a
 [&lt;ffffffff81ad32ac&gt;] early_ioremap+0x13/0x15
 [&lt;ffffffff81acc140&gt;] get_mpc_size+0x2f/0x67
 [&lt;ffffffff81acc284&gt;] smp_scan_config+0x10c/0x136
 [&lt;ffffffff81acc2e4&gt;] default_find_smp_config+0x36/0x5a
 [&lt;ffffffff81ac3085&gt;] setup_arch+0x5b3/0xb5b
 [&lt;ffffffff81624731&gt;] ? printk+0x48/0x4a
 [&lt;ffffffff81abca7f&gt;] start_kernel+0x90/0x390
 [&lt;ffffffff81abc356&gt;] x86_64_start_reservations+0x131/0x136
 [&lt;ffffffff81abfa83&gt;] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
Acked-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bd49940a35ec7d488ae63bd625639893b3385b97 upstream.

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f-&gt;100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f-&gt;100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff81ac07e2&gt;] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [&lt;ffffffff81ad31c6&gt;] __early_ioremap+0x18a/0x248
 [&lt;ffffffff81624731&gt;] ? printk+0x48/0x4a
 [&lt;ffffffff81ad32ac&gt;] early_ioremap+0x13/0x15
 [&lt;ffffffff81acc140&gt;] get_mpc_size+0x2f/0x67
 [&lt;ffffffff81acc284&gt;] smp_scan_config+0x10c/0x136
 [&lt;ffffffff81acc2e4&gt;] default_find_smp_config+0x36/0x5a
 [&lt;ffffffff81ac3085&gt;] setup_arch+0x5b3/0xb5b
 [&lt;ffffffff81624731&gt;] ? printk+0x48/0x4a
 [&lt;ffffffff81abca7f&gt;] start_kernel+0x90/0x390
 [&lt;ffffffff81abc356&gt;] x86_64_start_reservations+0x131/0x136
 [&lt;ffffffff81abfa83&gt;] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
Acked-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Yijing Wang &lt;wangyijing@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: PPC: Emulate dcbf</title>
<updated>2014-03-11T23:10:03+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2013-01-17T12:50:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=67bc20f722e2d3b77566f3eac9e9f6ce1b890d23'/>
<id>67bc20f722e2d3b77566f3eac9e9f6ce1b890d23</id>
<content type='text'>
commit d3286144c92ec876da9e30320afa875699b7e0f1 upstream.

Guests can trigger MMIO exits using dcbf. Since we don't emulate cache
incoherent MMIO, just do nothing and move on.

Reported-by: Ben Collins &lt;ben.c@servergy.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Ben Collins &lt;ben.c@servergy.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d3286144c92ec876da9e30320afa875699b7e0f1 upstream.

Guests can trigger MMIO exits using dcbf. Since we don't emulate cache
incoherent MMIO, just do nothing and move on.

Reported-by: Ben Collins &lt;ben.c@servergy.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Tested-by: Ben Collins &lt;ben.c@servergy.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>s390/kvm: dont announce RRBM support</title>
<updated>2014-03-11T23:10:03+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2012-10-02T14:25:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=115f50635c5addb145f20e090fa6345ee31fb2b8'/>
<id>115f50635c5addb145f20e090fa6345ee31fb2b8</id>
<content type='text'>
commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream.

Newer kernels (linux-next with the transparent huge page patches)
use rrbm if the feature is announced via feature bit 66.
RRBM will cause intercepts, so KVM does not handle it right now,
causing an illegal instruction in the guest.
The  easy solution is to disable the feature bit for the guest.

This fixes bugs like:
Kernel BUG at 0000000000124c2a [verbose debug info unavailable]
illegal operation: 0001 [#1] SMP
Modules linked in: virtio_balloon virtio_net ipv6 autofs4
CPU: 0 Not tainted 3.5.4 #1
Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670)
Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80)
     R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
     00000000003cc000 0000000000000004 0000000000000000 0000000079800000
     0000000000040000 0000000000000000 000000007bed3918 000000007cf40000
     0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c
     000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0
 Krnl Code:&gt;0000000000124c2a: b9810025          ogr     %r2,%r5
           0000000000124c2e: 41343000           la      %r3,0(%r4,%r3)
           0000000000124c32: a716fffa           brct    %r1,124c26
           0000000000124c36: b9010022           lngr    %r2,%r2
           0000000000124c3a: e3d0f0800004       lg      %r13,128(%r15)
           0000000000124c40: eb22003f000c       srlg    %r2,%r2,63
[ 2150.713198] Call Trace:
[ 2150.713223] ([&lt;00000000002312c4&gt;] page_referenced_one+0x6c/0x27c)
[ 2150.713749]  [&lt;0000000000233812&gt;] page_referenced+0x32a/0x410
[...]

CC: Alex Graf &lt;agraf@suse.de&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream.

Newer kernels (linux-next with the transparent huge page patches)
use rrbm if the feature is announced via feature bit 66.
RRBM will cause intercepts, so KVM does not handle it right now,
causing an illegal instruction in the guest.
The  easy solution is to disable the feature bit for the guest.

This fixes bugs like:
Kernel BUG at 0000000000124c2a [verbose debug info unavailable]
illegal operation: 0001 [#1] SMP
Modules linked in: virtio_balloon virtio_net ipv6 autofs4
CPU: 0 Not tainted 3.5.4 #1
Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670)
Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80)
     R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
     00000000003cc000 0000000000000004 0000000000000000 0000000079800000
     0000000000040000 0000000000000000 000000007bed3918 000000007cf40000
     0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c
     000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0
 Krnl Code:&gt;0000000000124c2a: b9810025          ogr     %r2,%r5
           0000000000124c2e: 41343000           la      %r3,0(%r4,%r3)
           0000000000124c32: a716fffa           brct    %r1,124c26
           0000000000124c36: b9010022           lngr    %r2,%r2
           0000000000124c3a: e3d0f0800004       lg      %r13,128(%r15)
           0000000000124c40: eb22003f000c       srlg    %r2,%r2,63
[ 2150.713198] Call Trace:
[ 2150.713223] ([&lt;00000000002312c4&gt;] page_referenced_one+0x6c/0x27c)
[ 2150.713749]  [&lt;0000000000233812&gt;] page_referenced+0x32a/0x410
[...]

CC: Alex Graf &lt;agraf@suse.de&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: s390: move kvm_guest_enter,exit closer to sie</title>
<updated>2014-03-11T23:10:03+00:00</updated>
<author>
<name>Dominik Dingel</name>
<email>dingel@linux.vnet.ibm.com</email>
</author>
<published>2013-07-26T13:04:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bf5597c693051a29efb77a6853daa869cd9667ab'/>
<id>bf5597c693051a29efb77a6853daa869cd9667ab</id>
<content type='text'>
commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream.

Any uaccess between guest_enter and guest_exit could trigger a page fault,
the page fault handler would handle it as a guest fault and translate a
user address as guest address.

Signed-off-by: Dominik Dingel &lt;dingel@linux.vnet.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
CC: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[hq: Backported to 3.4: adjust context]
Signed-off-by: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream.

Any uaccess between guest_enter and guest_exit could trigger a page fault,
the page fault handler would handle it as a guest fault and translate a
user address as guest address.

Signed-off-by: Dominik Dingel &lt;dingel@linux.vnet.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
CC: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[hq: Backported to 3.4: adjust context]
Signed-off-by: Qiang Huang &lt;h.huangqiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
