linux.git/arch, branch v3.12.65

KVM: MIPS: Drop other CPU ASIDs on guest MMU changes

2016-10-17T07:46:19+00:00

commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.

When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
TLB entries on the local CPU. This doesn't work correctly on an SMP host
when the guest is migrated to a different physical CPU, as it could pick
up stale TLB mappings from the last time the vCPU ran on that physical
CPU.

Therefore invalidate both user and kernel host ASIDs on other CPUs,
which will cause new ASIDs to be generated when it next runs on those
CPUs.

We're careful only to do this if the TLB entry was already valid, and
only for the kernel ASID where the virtual address it mapped is outside
of the guest user address range.

Signed-off-by: James Hogan 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Jiri Slaby

KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register

2016-10-17T07:46:19+00:00

commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream.

The MMCR2 register is available twice, one time with number 785
(privileged access), and one time with number 769 (unprivileged,
but it can be disabled completely). In former times, the Linux
kernel was using the unprivileged register 769 only, but since
commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number
for MMCR2"), it uses the privileged register 785 instead.
The KVM-PR code then of course also switched to use the SPR 785,
but this is causing older guest kernels to crash, since these
kernels still access 769 instead. So to support older kernels
with KVM-PR again, we have to support register 769 in KVM-PR, too.

Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41
Signed-off-by: Thomas Huth 
Signed-off-by: Paul Mackerras 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S PR: Emulate TIR register

2016-10-17T07:35:09+00:00

commit a5948fa092a04dfd6b9ee31c99eb6896c158eb08 upstream.

In parallel to the Processor ID Register (PIR) threaded POWER8 also adds a
Thread ID Register (TIR). Since PR KVM doesn't emulate more than one thread
per core, we can just always expose 0 here.

Signed-off-by: Alexander Graf 
Signed-off-by: Jiri Slaby

KVM: PPC: Book3S PR: Ignore PMU SPRs

2016-10-17T07:34:18+00:00

commit f8f6eb0d189cf2724af5ebc8cad460c78fb1994e upstream.

When we expose a POWER8 CPU into the guest, it will start accessing PMU SPRs
that we don't emulate. Just ignore accesses to them.

Signed-off-by: Alexander Graf 
Signed-off-by: Jiri Slaby

KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write

2016-10-07T08:06:55+00:00

commit dccbfcf52cebb8963246eba5b177b77f26b34da0 upstream.

If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
write with vmcs02 as the current VMCS.
This will incorrectly apply modifications intended for vmcs01 to vmcs02
and L2 can use it to gain access to L0's x2APIC registers by disabling
virtualized x2APIC while using msr bitmap that assumes enabled.

Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
current VMCS.  An alternative solution would temporarily make vmcs01 the
current VMCS, but it requires more care.

Fixes: 8d14695f9542 ("x86, apicv: add virtual x2apic support")
Reported-by: Jim Mattson 
Reviewed-by: Wanpeng Li 
Signed-off-by: Radim Krčmář 
Signed-off-by: Jiri Slaby

powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support

2016-10-07T08:06:55+00:00

commit 66443efa83dc73775100b7442962ce2cb0d4472e upstream.

When booting from an OpenFirmware which supports it, we use the
"ibm,client-architecture-support" firmware call to communicate
our capabilities to firmware.

The format of the structure we pass to firmware is specified in
PAPR (Power Architecture Platform Requirements), or the public version
LoPAPR (Linux on Power Architecture Platform Reference).

Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte
field at bytes 17-20 for the "Platform Facilities Enable". This is
followed by a 1 byte field at byte 21 for "Sub-Processor Represenation
Level".

Comparing to the code, there we have the Platform Facilities
options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its
full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is
incorrectly placed at byte 18.

Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes
to hopefully make it clearer in future.

As far as I'm aware nothing actually consumes this value at this time,
so the effect of this bug is nil in practice.

It does mean we've been incorrectly setting bit 15 of the "Platform
Facilities Enable" option for the past ~3 1/2 years, so we should avoid
allocating that bit to anything else in future.

Fixes: df77c7992029 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8")
Signed-off-by: Michael Ellerman 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Jiri Slaby

avr32: off by one in at32_init_pio()

2016-10-07T08:06:52+00:00

commit 55f1cf83d5cf885c75267269729805852039c834 upstream.

The pio_dev[] array has MAX_NR_PIO_DEVICES elements so the > should be
>=.

Fixes: 5f97f7f9400d ('[PATCH] avr32 architecture')
Signed-off-by: Dan Carpenter 
Signed-off-by: Jiri Slaby

tile: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO

2016-10-07T08:06:51+00:00

commit cdf8b4633075f2171d440d2e37c9c2609019a81a upstream.

AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for tile at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for
the VDSO address.

This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which tile doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
date.

Fixes: 4a556f4f56da ("tile: implement gettimeofday() via vDSO")
Signed-off-by: James Hogan 
Cc: Chris Metcalf 
Signed-off-by: Chris Metcalf 
Signed-off-by: Jiri Slaby

ARM: sa1111: fix pcmcia suspend/resume

2016-10-07T08:06:50+00:00

commit 06dfe5cc0cc684e735cb0232fdb756d30780b05d upstream.

SA1111 PCMCIA was broken when PCMCIA switched to using dev_pm_ops for
the PCMCIA socket class.  PCMCIA used to handle suspend/resume via the
socket hosting device, which happened at normal device suspend/resume
time.

However, the referenced commit changed this: much of the resume now
happens much earlier, in the noirq resume handler of dev_pm_ops.

However, on SA1111, the PCMCIA device is not accessible as the SA1111
has not been resumed at _noirq time.  It's slightly worse than that,
because the SA1111 has already been put to sleep at _noirq time, so
suspend doesn't work properly.

Fix this by converting the core SA1111 code to use dev_pm_ops as well,
and performing its own suspend/resume at noirq time.

This fixes these errors in the kernel log:

pcmcia_socket pcmcia_socket0: time out after reset
pcmcia_socket pcmcia_socket1: time out after reset

and the resulting lack of PCMCIA cards after a S2RAM cycle.

Fixes: d7646f7632549 ("pcmcia: use dev_pm_ops for class pcmcia_socket_class")
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

ARM: sa1100: clear reset status prior to reboot

2016-10-07T08:06:50+00:00

commit da60626e7d02a4f385cae80e450afc8b07035368 upstream.

Clear the current reset status prior to rebooting the platform.  This
adds the bit missing from 04fef228fb00 ("[ARM] pxa: introduce
reset_status and clear_reset_status for driver's usage").

Fixes: 04fef228fb00 ("[ARM] pxa: introduce reset_status and clear_reset_status for driver's usage")
Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby