linux-toradex.git/arch/x86, branch v3.6.8

KVM: x86: Fix invalid secondary exec controls in vmx_cpuid_update()

2012-11-26T20:14:17+00:00

commit 29282fde80d44e587f8c152b10049a56e61659f0 upstream.

The commit [ad756a16: KVM: VMX: Implement PCID/INVPCID for guests with
EPT] introduced the unconditional access to SECONDARY_VM_EXEC_CONTROL,
and this triggers kernel warnings like below on old CPUs:

    vmwrite error: reg 401e value a0568000 (err 12)
    Pid: 13649, comm: qemu-kvm Not tainted 3.7.0-rc4-test2+ #154
    Call Trace:
     [] vmwrite_error+0x27/0x29 [kvm_intel]
     [] vmcs_writel+0x1b/0x20 [kvm_intel]
     [] vmx_cpuid_update+0x74/0x170 [kvm_intel]
     [] kvm_vcpu_ioctl_set_cpuid2+0x76/0x90 [kvm]
     [] kvm_arch_vcpu_ioctl+0xc37/0xed0 [kvm]
     [] ? __vunmap+0x9c/0x110
     [] ? vmx_vcpu_load+0x39/0x1a0 [kvm_intel]
     [] ? kvm_arch_vcpu_load+0x52/0x1a0 [kvm]
     [] ? vcpu_load+0x74/0xd0 [kvm]
     [] kvm_vcpu_ioctl+0x110/0x5e0 [kvm]
     [] ? kvm_dev_ioctl+0x4d/0x4a0 [kvm]
     [] do_vfs_ioctl+0x8f/0x530
     [] ? remove_vma+0x56/0x60
     [] ? do_munmap+0x328/0x400
     [] ? fget_light+0x4c/0x100
     [] sys_ioctl+0x91/0xb0
     [] system_call_fastpath+0x1a/0x1f

This patch adds a check for the availability of secondary exec
control to avoid these warnings.

Signed-off-by: Takashi Iwai 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

xen/mmu: Use Xen specific TLB flush instead of the generic one.

2012-11-17T21:18:28+00:00

commit 95a7d76897c1e7243d4137037c66d15cbf2cce76 upstream.

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

Tested-by:  Jingjie Jiang 
Suggested-by:  Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Use memblock memory loop instead of e820_RAM

2012-10-31T17:10:32+00:00

commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: efi: Turn off efi_enabled after setup on mixed fw/kernel

2012-10-31T17:10:31+00:00

commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala 
Reported-by: Maxim Kammerer 
Signed-off-by: Olof Johansson 
Acked-by: Maarten Lankhorst 
Cc: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi: Defer freeing boot services memory until after ACPI init

2012-10-31T17:10:31+00:00

commit 785107923a83d8456bbd8564e288a24d84109a46 upstream.

Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.

Signed-off-by: Josh Triplett 
Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org
Signed-off-by: H. Peter Anvin 
Cc: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Undo incorrect revert in arch/x86/mm/init.c

2012-10-31T17:10:31+00:00

commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.

Commit

    844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped

added back some lines back wrongly that has been removed in commit

    7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"

remove them again.

Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com
Acked-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Find_early_table_space based on ranges that are actually being mapped

2012-10-31T17:10:23+00:00

commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream.

Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()

This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address
the panic reported here:

  https://lkml.org/lkml/2012/10/20/160
  https://lkml.org/lkml/2012/10/21/157

Signed-off-by: Jacob Shin 
Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie
Tested-by: Tom Rini 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, mm: Trim memory in memblock to be page aligned

2012-10-31T17:09:56+00:00

commit 6ede1fd3cb404c0016de6ac529df46d561bd558b upstream.

We will not map partial pages, so need to make sure memblock
allocation will not allocate those bytes out.

Also we will use for_each_mem_pfn_range() to loop to map memory
range to keep them consistent.

Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/mm: Fix the size calculation of mapping tables"

2012-10-31T17:09:40+00:00

commit 7b16bbf97375d9fb7fc107b3f80afeb94a204e44 upstream.

Commit:

   722bc6b16771 x86/mm: Fix the size calculation of mapping tables

Tried to address the issue that the first 2/4M should use 4k pages
if PSE enabled, but extra counts should only be valid for x86_32.

This commit caused a kdump regression: the kdump kernel hangs.

Work is in progress to fundamentally fix the various page table
initialization issues that we have, via the design suggested
by H. Peter Anvin, but it's not ready yet to be merged.

So, to get a working kdump revert to the last known working version,
which is the revert of this commit and of a followup fix (which was
incomplete):

   bd2753b2dda7 x86/mm: Only add extra pages count for the first memory range during pre-allocation

Tested kdump on physical and virtual machines.

Signed-off-by: Dave Young 
Acked-by: Yinghai Lu 
Acked-by: Cong Wang 
Acked-by: Flavio Leitner 
Tested-by: Flavio Leitner 
Cc: Dan Carpenter 
Cc: Cong Wang 
Cc: Flavio Leitner 
Cc: Tejun Heo 
Cc: ianfang.cn@gmail.com
Cc: Vivek Goyal 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86-64: Fix page table accounting

2012-10-31T17:09:38+00:00

commit 876ee61aadf01aa0db981b5d249cbdd53dc28b5e upstream.

Commit 20167d3421a089a1bf1bd680b150dc69c9506810 ("x86-64: Fix
accounting in kernel_physical_mapping_init()") went a little too
far by entirely removing the counting of pre-populated page
tables: this should be done at boot time (to cover the page
tables set up in early boot code), but shouldn't be done during
memory hot add.

Hence, re-add the removed increments of "pages", but make them
and the one in phys_pte_init() conditional upon !after_bootmem.

Reported-Acked-and-Tested-by: Hugh Dickins 
Signed-off-by: Jan Beulich 
Link: http://lkml.kernel.org/r/506DAFBA020000780009FA8C@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman