linux-toradex.git/arch, branch v3.18.17

KVM: VMX: Preserve host CR4.MCE value while in guest mode.

2015-06-28T17:39:27+00:00

[ Upstream commit 085e68eeafbf76e21848ad5bafaecec88a11dd64 ]

The host's decision to enable machine check exceptions should remain
in force during non-root mode.  KVM was writing 0 to cr4 on VCPU reset
and passed a slightly-modified 0 to the vmcs.guest_cr4 value.

Tested: Built.
On earlier version, tested by injecting machine check
while a guest is spinning.

Before the change, if guest CR4.MCE==0, then the machine check is
escalated to Catastrophic Error (CATERR) and the machine dies.
If guest CR4.MCE==1, then the machine check causes VMEXIT and is
handled normally by host Linux. After the change, injecting a machine
check causes normal Linux machine check handling.

Signed-off-by: Ben Serebrin 
Reviewed-by: Venkatesh Srinivas 
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin

x86: Store a per-cpu shadow copy of CR4

2015-06-28T17:39:27+00:00

[ Upstream commit 1e02ce4cccdcb9688386e5b8d2c9fa4660b45389 ]

Context switches and TLB flushes can change individual bits of CR4.
CR4 reads take several cycles, so store a shadow copy of CR4 in a
per-cpu variable.

To avoid wasting a cache line, I added the CR4 shadow to
cpu_tlbstate, which is already touched in switch_mm.  The heaviest
users of the cr4 shadow will be switch_mm and __switch_to_xtra, and
__switch_to_xtra is called shortly after switch_mm during context
switch, so the cacheline is likely to be hot.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Kees Cook 
Cc: Andrea Arcangeli 
Cc: Vince Weaver 
Cc: "hillf.zj" 
Cc: Valdis Kletnieks 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/3a54dd3353fffbf84804398e00dfdc5b7c1afd7d.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86: Clean up cr4 manipulation

2015-06-28T17:39:27+00:00

[ Upstream commit 375074cc736ab1d89a708c0a8d7baa4a70d5d476 ]

CR4 manipulation was split, seemingly at random, between direct
(write_cr4) and using a helper (set/clear_in_cr4).  Unfortunately,
the set_in_cr4 and clear_in_cr4 helpers also poke at the boot code,
which only a small subset of users actually wanted.

This patch replaces all cr4 access in functions that don't leave cr4
exactly the way they found it with new helpers cr4_set_bits,
cr4_clear_bits, and cr4_set_bits_and_update_boot.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrea Arcangeli 
Cc: Vince Weaver 
Cc: "hillf.zj" 
Cc: Valdis Kletnieks 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Kees Cook 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/495a10bdc9e67016b8fd3945700d46cfd5c12c2f.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr

2015-06-28T17:39:26+00:00

[ Upstream commit 98b228f55014870092c15d7d168fecac69f2f12a ]

Until now, the EFI stub was only setting the 32 bit cmd_line_ptr in
the setup_header structure, so on 64 bit platforms this could be truncated.
This patch adds setting the upper bits of the buffer address in
ext_cmd_line_ptr.  This case was likely never hit, as the allocation
for this buffer is done at the lowest available address.  Only
x86_64 kernels have this problem, as the 1-1 mapping mandated
by EFI ensures that all memory is 32 bit addressable on 32 bit
platforms.  The EFI stub does not support mixed mode, so the
32 bit kernel on 64 bit firmware case does not need to be handled.

Signed-off-by: Roy Franz 
Cc: 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

x86/iommu: Fix header comments regarding standard and _FINISH macros

2015-06-28T17:39:24+00:00

[ Upstream commit b44915927ca88084a7292e4ddd4cf91036f365e1 ]

The comment line regarding IOMMU_INIT and IOMMU_INIT_FINISH
macros is incorrect:

  "The standard vs the _FINISH differs in that the _FINISH variant
  will continue detecting other IOMMUs in the call list..."

It should be "..the *standard* variant will continue
detecting..."

Fix that. Also, make it readable while at it.

Signed-off-by: Aravind Gopalakrishnan 
Signed-off-by: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: konrad.wilk@oracle.com
Fixes: 6e9636693373 ("x86, iommu: Update header comments with appropriate naming")
Link: http://lkml.kernel.org/r/1428508017-5316-1-git-send-email-Aravind.Gopalakrishnan@amd.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

ARM: shmobile: r8a7791: Correct SYSCIER value

2015-06-28T17:39:16+00:00

[ Upstream commit 78420b5dca18f2034f18925f5608cda2c960c3f3 ]

Set the SYSCIER as per the values indicated in the documentation.
The value previously used appears to been copied from the r8a7779
implementation but on closer inspection is not correct for the r8a7791.

Fixes: 5f6108bb9643 ("ARM: shmobile: r8a7791 SYSC setup code")
Reported-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
Signed-off-by: Sasha Levin

ARM: shmobile: r8a7790: Correct SYSCIER value

2015-06-28T17:39:15+00:00

[ Upstream commit ee72f6adfdd95b53432eb60b6944c6fe2790dd13 ]

Set the SYSCIER as per the values indicated in the documentation.
The value previously used appears to been copied from the r8a7779
implementation but on closer inspection is not correct for the r8a7790.

Fixes: a48f165509c1 ("ARM: shmobile: r8a7790 SYSC setup code")
Reported-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
Signed-off-by: Sasha Levin

xtensa: xtfpga: fix hardware lockup caused by LCD driver

2015-06-28T17:39:15+00:00

[ Upstream commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 ]

LCD driver is always built for the XTFPGA platform, but its base address
is not configurable, and is wrong for ML605/KC705. Its initialization
locks up KC705 board hardware.

Make the whole driver optional, and its base address and bus width
configurable. Implement 4-bit bus access method.

Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

ARM: shmobile: r8a7791: Correct SDHI clock labels and output-names

2015-06-28T17:39:14+00:00

[ Upstream commit 2ea0d4ec39ac837e34c07b4783a7c900940e6eaf ]

There appears to have been some inconsistency and confusion here as on
the r8a7790 these clocks are referred to as SD(HI)1 and SD(HI)2 while on
the r8a7791 and r8a7794 they are referred to as SD(HI)2 and SD(HI)3.

Fixes: 59e79895b95892863 ("ARM: shmobile: r8a7791: Add clocks")
Reported-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin

ARM: shmobile: r8a7791: add USBDMAC{0,1} clocks to device tree

2015-06-28T17:39:14+00:00

[ Upstream commit b9473d9f621b68327776b66d4b9a8ba5e0b8b4cb ]

Signed-off-by: Yoshihiro Shimoda 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
Signed-off-by: Sasha Levin