<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/arch, branch v3.0.85</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.0.85</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.0.85'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2013-06-27T17:34:31Z</updated>
<entry>
<title>KVM: x86: remove vcpu's CPL check in host-invoked XCR set</title>
<updated>2013-06-27T17:34:31Z</updated>
<author>
<name>Zhanghaoyu (A)</name>
<email>haoyu.zhang@huawei.com</email>
</author>
<published>2013-06-14T07:36:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1819a873d94cd7abeb94f235175052f72fe6fa2c'/>
<id>urn:sha1:1819a873d94cd7abeb94f235175052f72fe6fa2c</id>
<content type='text'>
commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.

__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
called in two flows, one is invoked by guest, call stack shown as below,

  handle_xsetbv(or xsetbv_interception)
    kvm_set_xcr
      __kvm_set_xcr

the other one is invoked by host, for example during system reset:

  kvm_arch_vcpu_ioctl
    kvm_vcpu_ioctl_x86_set_xcrs
      __kvm_set_xcr

The former does need the CPL check, but the latter does not.

Signed-off-by: Zhang Haoyu &lt;haoyu.zhang@huawei.com&gt;
[Tweaks to commit message. - Paolo]
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tilepro: work around module link error with gcc 4.7</title>
<updated>2013-06-27T17:34:31Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@tilera.com</email>
</author>
<published>2013-06-15T20:47:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a0631b300bac987a591ae485d8a19a08aa57b4d2'/>
<id>urn:sha1:a0631b300bac987a591ae485d8a19a08aa57b4d2</id>
<content type='text'>
commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.

gcc 4.7.x is emitting calls to __ffsdi2 where previously
it used to inline the appropriate ctz instructions.
While this needs to be fixed in gcc, it's also easy to avoid
having it cause build failures when building with those
compilers by exporting __ffsdi2 to modules.

Signed-off-by: Chris Metcalf &lt;cmetcalf@tilera.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86: Fix typo in kexec register clearing</title>
<updated>2013-06-20T18:28:21Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-06-05T18:47:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0ffdfdbe55c84906dd65627f069619bec54e5422'/>
<id>urn:sha1:0ffdfdbe55c84906dd65627f069619bec54e5422</id>
<content type='text'>
commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1 upstream.

Fixes a typo in register clearing code. Thanks to PaX Team for fixing
this originally, and James Troup for pointing it out.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: http://lkml.kernel.org/r/20130605184718.GA8396@www.outflux.net
Cc: PaX Team &lt;pageexec@freemail.hu&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>um: Serve io_remap_pfn_range()</title>
<updated>2013-06-07T19:46:39Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2012-02-07T00:22:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9392bf7c8a7fd63c1ff1dbba237d67b95dae5cf9'/>
<id>urn:sha1:9392bf7c8a7fd63c1ff1dbba237d67b95dae5cf9</id>
<content type='text'>
commit 4d94d6d030adfdea4837694d293ec6918d133ab2 upstream.

At some places io_remap_pfn_range() is needed.
UML has to serve it like all other archs do.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Tested-by: Antoine Martin &lt;antoine@nagafix.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x</title>
<updated>2013-06-07T19:46:36Z</updated>
<author>
<name>Martin Michlmayr</name>
<email>tbm@cyrius.com</email>
</author>
<published>2013-04-21T16:14:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=891694374dbdf88b12f41fa412ead40a4d255071'/>
<id>urn:sha1:891694374dbdf88b12f41fa412ead40a4d255071</id>
<content type='text'>
commit 99e11334dcb846f9b76fb808196c7f47aa83abb3 upstream.

Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
(rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
to Marek Vasut for identifying this issue!

Signed-off-by: Martin Michlmayr &lt;tbm@cyrius.com&gt;
Tested-by: Marek Vasut &lt;marex@denx.de&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: plat-orion: Fix num_resources and id for ge10 and ge11</title>
<updated>2013-06-07T19:46:34Z</updated>
<author>
<name>Gregory CLEMENT</name>
<email>gregory.clement@free-electrons.com</email>
</author>
<published>2013-05-19T20:12:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8a3e6d89936003e13011ab01dacdf96c66a0e465'/>
<id>urn:sha1:8a3e6d89936003e13011ab01dacdf96c66a0e465</id>
<content type='text'>
commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream.

When platform data were moved from arch/arm/mach-mv78xx0/common.c to
arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion:
Consolidate ethernet platform data", there were few typo made on
gigabit Ethernet interface ge10 and ge11. This commit writes back
their initial value, which allows to use this interfaces again.

Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>avr32: fix relocation check for signed 18-bit offset</title>
<updated>2013-06-07T19:46:34Z</updated>
<author>
<name>Hans-Christian Egtvedt</name>
<email>egtvedt@samfundet.no</email>
</author>
<published>2013-05-13T20:22:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e9a91cb47886388540eaf68f981e7a3d4b04a27c'/>
<id>urn:sha1:e9a91cb47886388540eaf68f981e7a3d4b04a27c</id>
<content type='text'>
commit e68c636d88db3fda74e664ecb1a213ae0d50a7d8 upstream.

Caught by static code analysis by David.

Reported-by: David Binderman &lt;dcb314@hotmail.com&gt;
Signed-off-by: Hans-Christian Egtvedt &lt;egtvedt@samfundet.no&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.</title>
<updated>2013-05-19T17:04:38Z</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2013-05-05T13:30:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a3b5b07e0d750c300d771a0a8e5ad24898bcdd9b'/>
<id>urn:sha1:a3b5b07e0d750c300d771a0a8e5ad24898bcdd9b</id>
<content type='text'>
commit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream.

If a user did:

	echo 0 &gt; /sys/devices/system/cpu/cpu1/online
	echo 1 &gt; /sys/devices/system/cpu/cpu1/online

we would (this a build with DEBUG enabled) get to:
smpboot: ++++++++++++++++++++=_---CPU UP  1
.. snip..
smpboot: Stack at about ffff880074c0ff44
smpboot: CPU1: has booted.

and hang. The RCU mechanism would kick in an try to IPI the CPU1
but the IPIs (and all other interrupts) would never arrive at the
CPU1. At first glance at least. A bit digging in the hypervisor
trace shows that (using xenanalyze):

[vla] d4v1 vec 243 injecting
   0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
]  0.043163639 --|x d4v1 vmentry cycles 1468
]  0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254
   0.043164913 --|x d4v1 inj_virq vec 243  real
  [vla] d4v1 vec 243 injecting
   0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3
]  0.043165526 --|x d4v1 vmentry cycles 1472
]  0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254
   0.043166800 --|x d4v1 inj_virq vec 243  real
  [vla] d4v1 vec 243 injecting

there is a pending event (subsequent debugging shows it is the IPI
from the VCPU0 when smpboot.c on VCPU1 has done
"set_cpu_online(smp_processor_id(), true)") and the guest VCPU1 is
interrupted with the callback IPI (0xf3 aka 243) which ends up calling
__xen_evtchn_do_upcall.

The __xen_evtchn_do_upcall seems to do *something* but not acknowledge
the pending events. And the moment the guest does a 'cli' (that is the
ffffffff81673254 in the log above) the hypervisor is invoked again to
inject the IPI (0xf3) to tell the guest it has pending interrupts.
This repeats itself forever.

The culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup
we set each per_cpu(xen_vcpu, cpu) to point to the
shared_info-&gt;vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info
to register per-CPU  structures (xen_vcpu_setup).
This is used to allow events for more than 32 VCPUs and for performance
optimizations reasons.

When the user performs the VCPU hotplug we end up calling the
the xen_vcpu_setup once more. We make the hypercall which returns
-EINVAL as it does not allow multiple registration calls (and
already has re-assigned where the events are being set). We pick
the fallback case and set per_cpu(xen_vcpu, cpu) to point to the
shared_info-&gt;vcpu_info[vcpu] (which is a good fallback during bootup).
However the hypervisor is still setting events in the register
per-cpu structure (per_cpu(xen_vcpu_info, cpu)).

As such when the events are set by the hypervisor (such as timer one),
and when we iterate in __xen_evtchn_do_upcall we end up reading stale
events from the shared_info-&gt;vcpu_info[vcpu] instead of the
per_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the
events that the hypervisor has set and the hypervisor keeps on reminding
us to ack the events which we never do.

The fix is simple. Don't on the second time when xen_vcpu_setup is
called over-write the per_cpu(xen_vcpu, cpu) if it points to
per_cpu(xen_vcpu_info).

Acked-by: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices</title>
<updated>2013-05-19T17:04:36Z</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2013-05-08T23:48:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f3fb49dfccbf7bb7005bd57bb7385c3ee80d8c52'/>
<id>urn:sha1:f3fb49dfccbf7bb7005bd57bb7385c3ee80d8c52</id>
<content type='text'>
commit e65f131a14726e5f1b880a528271a52428e5b3a5 upstream.

Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver)
broke the SPI display/panel driver probe on RX-51/N900. The exact cause is
not fully understood, but it seems to be related to the probe order. SPI
communication to the panel driver (spi1.2) fails unless the touchscreen
(spi1.0) has been probed/initialized before. When the omap2-mcspi driver
was converted to a platform driver, it resulted in that the devices are
probed immediately after the board registers them in the order they are
listed in the board file.

Fix the issue by moving the touchscreen before the panel in the SPI
device list.

The patch fixes the following failure:

[    1.260955] acx565akm spi1.2: invalid display ID
[    1.265899] panel-acx565akm display0: acx_panel_probe panel detect error
[    1.273071] omapdss CORE error: driver probe failed: -19

Tested-by: Sebastian Reichel &lt;sre@debian.org&gt;
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Cc: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Cc: Joni Lapilainen &lt;joni.lapilainen@gmail.com&gt;
Cc: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: VMX: fix halt emulation while emulating invalid guest sate</title>
<updated>2013-05-19T17:04:35Z</updated>
<author>
<name>Gleb Natapov</name>
<email>gleb@redhat.com</email>
</author>
<published>2013-05-08T15:38:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e171327c07f33c79dab763e08feb7b0ad24dfe71'/>
<id>urn:sha1:e171327c07f33c79dab763e08feb7b0ad24dfe71</id>
<content type='text'>
commit 8d76c49e9ffeee839bc0b7a3278a23f99101263e upstream.

The invalid guest state emulation loop does not check halt_request
which causes 100% cpu loop while guest is in halt and in invalid
state, but more serious issue is that this leaves halt_request set, so
random instruction emulated by vm86 #GP exit can be interpreted
as halt which causes guest hang. Fix both problems by handling
halt_request in emulation loop.

Reported-by: Tomas Papan &lt;tomas.papan@gmail.com&gt;
Tested-by: Tomas Papan &lt;tomas.papan@gmail.com&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Gleb Natapov &lt;gleb@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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