13 Oct, 2013
2 commits
-
Pull gcc "asm goto" miscompilation workaround from Ingo Molnar:
"This is the fix for the GCC miscompilation discussed in the following
lkml thread:[x86] BUG: unable to handle kernel paging request at 00740060
The bug in GCC has been fixed by Jakub and the fix will be part of the
GCC 4.8.2 release expected to be released next week - so the quirk's
version test checks for miscompilation bug -
Pull x86 fixes from Ingo Molnar:
"A build fix and a reboot quirk"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/reboot: Add reboot quirk for Dell Latitude E5410
x86, build, pci: Fix PCI_MSI build on !SMP
11 Oct, 2013
2 commits
-
Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Implement a workaround suggested by Jakub Jelinek.
Reported-and-tested-by: Fengguang Wu
Reported-by: Oleg Nesterov
Reported-by: Peter Zijlstra
Suggested-by: Jakub Jelinek
Reviewed-by: Richard Henderson
Cc: Linus Torvalds
Cc: Andrew Morton
Cc:
Signed-off-by: Ingo Molnar -
Pull kvm fixes from Paolo Bonzini:
"Fixes for 3.12-rc5: two old PPC bugs and one new (3.12-rc2) x86 bug"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: ppc: booke: check range page invalidation progress on page setup
KVM: PPC: Book3S HV: Fix typo in saving DSCR
KVM: nVMX: fix shadow on EPT
10 Oct, 2013
1 commit
-
72f857950f6f19 broke shadow on EPT. This patch reverts it and fixes PAE
on nEPT (which reverted commit fixed) in other way.Shadow on EPT is now broken because while L1 builds shadow page table
for L2 (which is PAE while L2 is in real mode) it never loads L2's
GUEST_PDPTR[0-3]. They do not need to be loaded because without nested
virtualization HW does this during guest entry if EPT is disabled,
but in our case L0 emulates L2's vmentry while EPT is enables, so we
cannot rely on vmcs12->guest_pdptr[0-3] to contain up-to-date values
and need to re-read PDPTEs from L2 memory. This is what kvm_set_cr3()
is doing, but by clearing cache bits during L2 vmentry we drop values
that kvm_set_cr3() read from memory.So why the same code does not work for PAE on nEPT? kvm_set_cr3()
reads pdptes into vcpu->arch.walk_mmu->pdptrs[]. walk_mmu points to
vcpu->arch.nested_mmu while nested guest is running, but ept_load_pdptrs()
uses vcpu->arch.mmu which contain incorrect values. Fix that by using
walk_mmu in ept_(load|save)_pdptrs.Signed-off-by: Gleb Natapov
Reviewed-by: Paolo Bonzini
Tested-by: Paolo Bonzini
Signed-off-by: Paolo Bonzini
09 Oct, 2013
1 commit
-
Pull perf fixes from Ingo Molnar:
"Various fixlets:On the kernel side:
- fix a race
- fix a bug in the handling of the perf ring-buffer data pageOn the tooling side:
- fix the handling of certain corrupted perf.data files
- fix a bug in 'perf probe'
- fix a bug in 'perf record + perf sched'
- fix a bug in 'make install'
- fix a bug in libaudit feature-detection on certain distros"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf session: Fix infinite loop on invalid perf.data file
perf tools: Fix installation of libexec components
perf probe: Fix to find line information for probe list
perf tools: Fix libaudit test
perf stat: Set child_pid after perf_evlist__prepare_workload()
perf tools: Add default handler for mmap2 events
perf/x86: Clean up cap_user_time* setting
perf: Fix perf_pmu_migrate_context
06 Oct, 2013
1 commit
-
Dell Latitude E5410 needs reboot=pci to actually reboot.
Signed-off-by: Ville Syrjälä
Link: http://lkml.kernel.org/r/1380888964-14517-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar
05 Oct, 2013
4 commits
-
Pull PCI fix from Bjorn Helgaas:
"We merged what was intended to be an MMCONFIG cleanup, but in fact,
for systems without _CBA (which is almost everything), it broke
extended config space for domain 0 and it broke all config space for
other domains.This reverts the change"
* tag 'pci-v3.12-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero" -
This reverts commit 07f9b61c3915e8eb156cb4461b3946736356ad02.
07f9b61c was intended to be a cleanup that didn't change anything, but in
fact, for systems without _CBA (which is almost everything), it broke
extended config space for domain 0 and all config space for other domains.Reference: http://lkml.kernel.org/r/20131004011806.GE20450@dangermouse.emea.sgi.com
Reported-by: Hedi Berriche
Signed-off-by: Bjorn Helgaas -
Commit ebd97be635 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removed the ARCH_SUPPORTS_MSI option which architectures could select
to indicate that they support MSI. Now, all architectures are supposed
to build fine when MSI support is enabled: instead of having the
architecture tell *when* MSI support can be used, it's up to the
architecture code to ensure that MSI support can be enabled.On x86, commit ebd97be635 removed the following line:
select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
Which meant that MSI support was only available when the local APIC
and I/O APIC were enabled. While this is always true on SMP or x86-64,
it is not necessarily the case on i386 !SMP.The below patch makes sure that the local APIC and I/O APIC support is
always enabled when MSI support is enabled. To do so, it:* Ensures the X86_UP_APIC option is not visible when PCI_MSI is
enabled. This is the option that allows, on UP machines, to enable
or not the APIC support. It is already not visible on SMP systems,
or x86-64 systems, for example. We're simply also making it
invisible on i386 MSI systems.* Ensures that the X86_LOCAL_APIC and X86_IO_APIC options are 'y'
when PCI_MSI is enabled.Notice that this change requires a change in drivers/iommu/Kconfig to
avoid a recursive Kconfig dependencey. The AMD_IOMMU option selects
PCI_MSI, but was depending on X86_IO_APIC. This dependency is no
longer needed: as soon as PCI_MSI is selected, the presence of
X86_IO_APIC is guaranteed. Moreover, the AMD_IOMMU already depended on
X86_64, which already guaranteed that X86_IO_APIC was enabled, so this
dependency was anyway redundant.Signed-off-by: Thomas Petazzoni
Link: http://lkml.kernel.org/r/1380794354-9079-1-git-send-email-thomas.petazzoni@free-electrons.com
Reported-by: Konrad Rzeszutek Wilk
Acked-by: Bjorn Helgaas
Signed-off-by: H. Peter Anvin -
Pull x86 fixes from Ingo Molnar:
"Two simplefb fixes"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/simplefb: Mark framebuffer mem-resources as IORESOURCE_BUSY to avoid bootup warning
x86/simplefb: Fix overflow causing bogus fall-back
04 Oct, 2013
1 commit
-
Currently the cap_user_time_zero capability has different tests than
cap_user_time; even though they expose the exact same data.Switch from CONSTANT && NONSTOP to sched_clock_stable to also deal
with multi cabinet machines and drop the tsc_disabled() check.. non of
this will work sanely without tsc anyway.Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-nmgn0j0muo1r4c94vlfh23xy@git.kernel.org
Signed-off-by: Ingo Molnar
03 Oct, 2013
1 commit
-
IORESOURCE_BUSY is used to mark temporary driver mem-resources
instead of global regions. This suppresses warnings if regions
overlap with a region marked as BUSY.This was always the case for VESA/VGA/EFI framebuffer regions so
do the same for simplefb regions. The reason we do this is to
allow device handover to real GPU drivers like
i915/radeon/nouveau which get the same regions via PCI BARs.Maybe at some point we will be able to unregister platform
devices properly during the handover. In this case the simplefb
region would get removed before the new region is created.
However, this is currently not the case and would require rather
huge changes in remove_conflicting_framebuffers(). Add the BUSY
marker now and try to eventually rewrite the handover for a next release.Also see kernel/resource.c for more information:
/*
* if a resource is "BUSY", it's not a hardware resource
* but a driver mapping of such a resource; we don't want
* to warn for those; some drivers legitimately map only
* partial hardware resources. (example: vesafb)
*/This suppresses warnings like:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390()
Info: mapping multiple BARs. Your kernel is fine.
Call Trace:
dump_stack+0x54/0x8d
warn_slowpath_common+0x7d/0xa0
warn_slowpath_fmt+0x4c/0x50
iomem_map_sanity_check+0xac/0xe0
__ioremap_caller+0x2e3/0x390
ioremap_wc+0x32/0x40
i915_driver_load+0x670/0xf50 [i915]
...Reported-by: Tom Gundersen
Tested-by: Tom Gundersen
Tested-by: Pavel Roskin
Signed-off-by: David Herrmann
Link: http://lkml.kernel.org/r/1380724864-1757-1-git-send-email-dh.herrmann@gmail.com
Signed-off-by: Ingo Molnar
02 Oct, 2013
2 commits
-
On my MacBook Air lfb_size is 4M, which makes the bitshit
overflow (to 256GB - larger than 32 bits), meaning we fall
back to efifb unnecessarily.Cast to u64 to avoid the overflow.
Signed-off-by: Tom Gundersen
Reviewed-by: David Herrmann
Cc: Geert Uytterhoeven
Cc: Stephen Warren
Cc: Stephen Warren
Link: http://lkml.kernel.org/r/1380644320-1026-1-git-send-email-teg@jklm.no
Signed-off-by: Ingo Molnar -
Pull two KVM fixes from Gleb Natapov.
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: VMX: do not check bit 12 of EPT violation exit qualification when undefined
ARM: kvm: rename cpu_reset to avoid name clash
29 Sep, 2013
2 commits
-
…nt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler, timer and x86 fixes from Ingo Molnar:
- A context tracking ARM build and functional fix
- A handful of ARM clocksource/clockevent driver fixes
- An AMD microcode patch level sysfs reporting fixlet* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
arm: Fix build error with context tracking calls* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource: em_sti: Set cpu_possible_mask to fix SMP broadcast
clocksource: of: Respect device tree node status
clocksource: exynos_mct: Set IRQ affinity when the CPU goes online
arm: clocksource: mvebu: Use the main timer as clock source from DT* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode/AMD: Fix patch level reporting for family 15h -
Pull perf fixes from Ingo Molnar:
"A couple of tooling fixlets and a PMU detection printout fix"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86: Fix PMU detection printout when no PMU is detected
perf symbols: Demangle cloned functions
perf machine: Fix path unpopulated in machine__create_modules()
perf tools: Explicitly add libdl dependency
perf probe: Fix probing symbols with optimization suffix
perf trace: Add mmap2 handler
perf kmem: Make it work again on non NUMA machines
28 Sep, 2013
1 commit
-
Ran into this cryptic PMU bootup log recently:
[ 0.124047] Performance Events:
[ 0.125000] smpboot: ...Turns out we print this if no PMU is detected. Fall back to
the right condition so that the following is printed:[ 0.122381] Performance Events: no PMU driver, software events only.
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Link: http://lkml.kernel.org/n/tip-u2fwaUffakjp0qkpRfqljgsn@git.kernel.org
Signed-off-by: Ingo Molnar
27 Sep, 2013
1 commit
-
On AMD family 14h, applying microcode patch on the a core (core0)
would also affect the other core (core1) in the same compute
unit. The driver would skip applying the patch on core1, but it
still need to update kernel structures to reflect the proper
patch level.The current logic is not updating the struct
ucode_cpu_info.cpu_sig.rev of the skipped core. This causes the
/sys/devices/system/cpu/cpu1/microcode/version to report
incorrect patch level as shown below:$ grep . cpu?/microcode/version
cpu0/microcode/version:0x600063d
cpu1/microcode/version:0x6000626
cpu2/microcode/version:0x600063d
cpu3/microcode/version:0x6000626
cpu4/microcode/version:0x600063dSigned-off-by: Suravee Suthikulpanit
Acked-by: Borislav Petkov
Cc:
Cc:
Cc:
Link: http://lkml.kernel.org/r/1285806432-1995-1-git-send-email-suravee.suthikulpanit@amd.com
Signed-off-by: Ingo Molnar
26 Sep, 2013
3 commits
-
Pull Xen fixes from Konrad Rzeszutek Wilk:
"Bug-fixes and one update to the kernel-paramters.txt documentation.- Fix PV spinlocks triggering jump_label code bug
- Remove extraneous code in the tpm front driver
- Fix ballooning out of pages when non-preemptible
- Fix deadlock when using a 32-bit initial domain with large amount
of memory
- Add xen_nopvpsin parameter to the documentation"* tag 'stable/for-linus-3.12-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/spinlock: Document the xen_nopvspin parameter.
xen/p2m: check MFN is in range before using the m2p table
xen/balloon: don't alloc page while non-preemptible
xen: Do not enable spinlocks before jump_label_init() has executed
tpm: xen-tpmfront: Remove the locality sysfs attribute
tpm: xen-tpmfront: Fix default durations -
Pull x86 fixes from Ingo Molnar:
"An EFI fix and two reboot-quirk fixes"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/reboot: Fix apparent cut-n-paste mistake in Dell reboot workaround
x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically
x86, efi: Don't map Boot Services on i386 -
Pull perf fixes from Ingo Molnar:
"Assorted standalone fixes"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel: Add model number for Avoton Silvermont
perf: Fix capabilities bitfield compatibility in 'struct perf_event_mmap_page'
perf/x86/intel/uncore: Don't use smp_processor_id() in validate_group()
perf: Update ABI comment
tools lib lk: Uninclude linux/magic.h in debugfs.c
perf tools: Fix old GCC build error in trace-event-parse.c:parse_proc_kallsyms()
perf probe: Fix finder to find lines of given function
perf session: Check for SIGINT in more loops
perf tools: Fix compile with libelf without get_phdrnum
perf tools: Fix buildid cache handling of kallsyms with kcore
perf annotate: Fix objdump line parsing offset validation
perf tools: Fill in new definitions for madvise()/mmap() flags
perf tools: Sharpen the libaudit dependencies test
25 Sep, 2013
4 commits
-
On hosts with more than 168 GB of memory, a 32-bit guest may attempt
to grant map an MFN that is error cannot lookup in its mapping of the
m2p table. There is an m2p lookup as part of m2p_add_override() and
m2p_remove_override(). The lookup falls off the end of the mapped
portion of the m2p and (because the mapping is at the highest virtual
address) wraps around and the lookup causes a fault on what appears to
be a user space address.do_page_fault() (thinking it's a fault to a userspace address), tries
to lock mm->mmap_sem. If the gntdev device is used for the grant map,
m2p_add_override() is called from from gnttab_mmap() with mm->mmap_sem
already locked. do_page_fault() then deadlocks.The deadlock would most commonly occur when a 64-bit guest is started
and xenconsoled attempts to grant map its console ring.Introduce mfn_to_pfn_no_overrides() which checks the MFN is within the
mapped portion of the m2p table before accessing the table and use
this in m2p_add_override(), m2p_remove_override(), and mfn_to_pfn()
(which already had the correct range check).All faults caused by accessing the non-existant parts of the m2p are
thus within the kernel address space and exception_fixup() is called
without trying to lock mm->mmap_sem.This means that for MFNs that are outside the mapped range of the m2p
then mfn_to_pfn() will always look in the m2p overrides. This is
correct because it must be a foreign MFN (and the PFN in the m2p in
this case is only relevant for the other domain).Signed-off-by: David Vrabel
Cc: Stefano Stabellini
Cc: Jan Beulich
--
v3: check for auto_translated_physmap in mfn_to_pfn_no_overrides()
v2: in mfn_to_pfn() look in m2p_overrides if the MFN is out of
range as it's probably foreign.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Stefano Stabellini -
Bit 12 is undefined in any of the following cases:
- If the "NMI exiting" VM-execution control is 1 and the "virtual NMIs"
VM-execution control is 0.
- If the VM exit sets the valid bit in the IDT-vectoring information fieldSigned-off-by: Gleb Natapov
[Add parentheses around & within && - Paolo]
Signed-off-by: Paolo Bonzini -
This seems to have been copied from the Optiplex 990 entry
above, but somoene forgot to change the ident text.Signed-off-by: Dave Jones
Link: http://lkml.kernel.org/r/20130925001344.GA13554@redhat.com
Signed-off-by: Ingo Molnar -
xen_init_spinlocks() currently calls static_key_slow_inc() before
jump_label_init() is invoked. When CONFIG_JUMP_LABEL is set (which usually is
the case) the effect of this static_key_slow_inc() is deferred until after
jump_label_init(). This is different from when CONFIG_JUMP_LABEL is not set, in
which case the key is set immediately. Thus, depending on the value of config
option, we may observe different behavior.In addition, when we come to __jump_label_transform() from jump_label_init(),
the key (paravirt_ticketlocks_enabled) is already enabled. On processors where
ideal_nop is not the same as default_nop this will cause a BUG() since it is
expected that before a key is enabled the latter is replaced by the former
during initialization.To address this problem we need to move
static_key_slow_inc(¶virt_ticketlocks_enabled) so that it is called
after jump_label_init(). We also need to make sure that this is done before
other cpus start to boot. early_initcall appears to be a good place to do so.
(Note that we cannot move whole xen_init_spinlocks() there since pv_lock_ops
need to be set before alternative_instructions() runs.)Signed-off-by: Konrad Rzeszutek Wilk
[v2: Added extra comments in the code]
Signed-off-by: Boris Ostrovsky
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Steven Rostedt
23 Sep, 2013
2 commits
-
Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.
Signed-off-by: Masoud Sharbiani
Signed-off-by: Vinson Lee
Cc: Robin Holt
Cc: Russell King
Cc: Guan Xuetao
Cc:
Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org
Signed-off-by: Ingo Molnar -
Signed-off-by: Yan, Zheng
Cc: a.p.zijlstra@chello.nl
Cc: eranian@google.com
Cc: ak@linux.intel.com
Link: http://lkml.kernel.org/r/1379837953-17755-1-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar
20 Sep, 2013
3 commits
-
Pull EFI fix from Matt Flemin:
" * Fix WARNING on i386 by only enabling a workaround for x86-64 since
we've never encountered the bug on i386 - Josh Boyer "Signed-off-by: Ingo Molnar
-
Solve the problems around the broken definition of perf_event_mmap_page::
cap_usr_time and cap_usr_rdpmc fields which used to overlap, partially
fixed by:860f085b74e9 ("perf: Fix broken union in 'struct perf_event_mmap_page'")
The problem with the fix (merged in v3.12-rc1 and not yet released
officially), noticed by Vince Weaver is that the new behavior is
not detectable by new user-space, and that due to the reuse of the
field names it's easy to mis-compile a binary if old headers are used
on a new kernel or new headers are used on an old kernel.To solve all that make this change explicit, detectable and self-contained,
by iterating the ABI the following way:- Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not
confuse old user-space binaries. RDPMC will be marked as unavailable
to old binaries but that's within the ABI, this is a capability bit.- Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new
libraries can reliably detect that bit 0 is deprecated and perma-zero
without having to check the kernel version.- Use bits 2, 3, 4 for the newly defined, correct functionality:
cap_user_rdpmc : 1, /* The RDPMC instruction can be used to read counts */
cap_user_time : 1, /* The time_* fields are used */
cap_user_time_zero : 1, /* The time_zero field is used */- Rename all the bitfield names in perf_event.h to be different from the
old names, to make sure it's not possible to mis-compile it
accidentally with old assumptions.The 'size' field can then be used in the future to add new fields and it
will act as a natural ABI version indicator as well.Also adjust tools/perf/ userspace for the new definitions, noticed by
Adrian Hunter.Reported-by: Vince Weaver
Signed-off-by: Peter Zijlstra
Also-Fixed-by: Adrian Hunter
Link: http://lkml.kernel.org/n/tip-zr03yxjrpXesOzzupszqglbv@git.kernel.org
Signed-off-by: Ingo Molnar -
uncore_validate_group() can't call smp_processor_id() because it is
in preemptible context. Pass NUMA_NO_NODE to the allocator instead.Signed-off-by: Yan, Zheng
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/1379400493-11505-1-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar
19 Sep, 2013
2 commits
-
Pull x86 fixes from Ingo Molnar:
"Misc fixes"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/intel/lpss: Add pin control support to Intel low power subsystem
perf/x86/intel: Mark MEM_LOAD_UOPS_MISS_RETIRED as precise on SNB
x86: Remove now-unused save_rest()
x86/smpboot: Fix announce_cpu() to printk() the last "OK" properly -
Pull perf fixes from Ingo Molnar:
"Two small fixes"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix UAPI export of PERF_EVENT_IOC_ID
perf/x86/intel: Fix Silvermont offcore masks
18 Sep, 2013
2 commits
-
Add patch to fix 32bit EFI service mapping (rhbz 726701)
Multiple people are reporting hitting the following WARNING on i386,
WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
Call Trace:
[] warn_slowpath_common+0x5f/0x80
[] ? __ioremap_caller+0x3d3/0x440
[] ? __ioremap_caller+0x3d3/0x440
[] warn_slowpath_null+0x1d/0x20
[] __ioremap_caller+0x3d3/0x440
[] ? get_usage_chars+0xfb/0x110
[] ? vprintk_emit+0x147/0x480
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] ioremap_cache+0x1a/0x20
[] ? efi_enter_virtual_mode+0x1e4/0x3de
[] efi_enter_virtual_mode+0x1e4/0x3de
[] start_kernel+0x286/0x2f4
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x12c/0x12fDue to the workaround described in commit 916f676f8 ("x86, efi: Retain
boot service code until after switching to virtual mode") EFI Boot
Service regions are mapped for a period during boot. Unfortunately, with
the limited size of the i386 direct kernel map it's possible that some
of the Boot Service regions will not be directly accessible, which
causes them to be ioremap()'d, triggering the above warning as the
regions are marked as E820_RAM in the e820 memmap.There are currently only two situations where we need to map EFI Boot
Service regions,1. To workaround the firmware bug described in 916f676f8
2. To access the ACPI BGRT imagebut since we haven't seen an i386 implementation that requires either,
this simple fix should suffice for now.[ Added to changelog - Matt ]
Reported-by: Bryan O'Donoghue
Acked-by: Tom Zanussi
Acked-by: Darren Hart
Cc: Josh Triplett
Cc: Matthew Garrett
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc:
Signed-off-by: Josh Boyer
Signed-off-by: Matt Fleming -
Set "blocked by NMI" flag if EPT violation happens during IRET from NMI
otherwise NMI can be called recursively causing stack corruption.Signed-off-by: Gleb Natapov
17 Sep, 2013
3 commits
-
After nested vmentry stale cache can be used to reload L2 PDPTR pointers
which will cause L2 guest to fail. Fix it by invalidating cache on nested
vmentry emulation.https://bugzilla.kernel.org/show_bug.cgi?id=60830
Signed-off-by: Gleb Natapov
Signed-off-by: Paolo Bonzini -
Page tables in a read-only memory slot will currently cause a triple
fault because the page walker uses gfn_to_hva and it fails on such a slot.OVMF uses such a page table; however, real hardware seems to be fine with
that as long as the accessed/dirty bits are set. Save whether the slot
is readonly, and later check it when updating the accessed and dirty bits.Reviewed-by: Xiao Guangrong
Reviewed-by: Gleb Natapov
Signed-off-by: Paolo Bonzini -
Opcode CA
This gets used by a DOS based NetWare guest.
Signed-off-by: Bruce Rogers
Reviewed-by: Gleb Natapov
Signed-off-by: Paolo Bonzini
14 Sep, 2013
2 commits
-
x86 chips with LPSS (low power subsystem) such as Lynxpoint and
Baytrail have SoC like peripheral support and controllable pins.At the moment, Baytrail needs the pinctrl-baytrail driver to let
peripherals control their gpio resources, but more pincontrol
functions such as pin muxing and grouping are possible to add
later.Signed-off-by: Mathias Nyman
Reviewed-by: Mika Westerberg
Cc: Rafael J. Wysocki
Link: http://lkml.kernel.org/r/1379080949-21734-1-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Ingo Molnar -
On Intel SNB (SNB, SNB-EP), the event MEM_LOAD_UOPS_MISS_RETIRED
supports PEBS. It was missing for the SNB PEBS event constraint
table thereby preventing any measurement with PEBS for it.This patch adds the event to the PEBS table for SNB.
WARNING: it should be noted that this event like a few others
are subject to the erratum BT241 for Xeon E5 (SNB-EP). As such,
the event may undercount when used with PEBS unless the
workaround is implemented. But without this patch and just the
workaround, the kernel would not allow precise sampling on this
event. BT241 is documented in:http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf
Signed-off-by: Stephane Eranian
Cc: peterz@infradead.org
Cc: ak@linux.intel.com
Cc: zheng.z.yan@intel.com
Link: http://lkml.kernel.org/r/20130913201646.GA23981@google.com
Signed-off-by: Ingo Molnar
