This case is a pure user space error we do not need to record. Moreover,
it can be misused to flood the kernel log. Remove it.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Fix:

[ 1001.499596] ===================================================
[ 1001.499599] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 1001.499601] ---------------------------------------------------
[ 1001.499604] include/linux/kvm_host.h:301 invoked rcu_dereference_check() without protection!
	......
[ 1001.499636] Pid: 6035, comm: qemu-system-x86 Not tainted 2.6.37-rc6+ #62
[ 1001.499638] Call Trace:
[ 1001.499644]  [] lockdep_rcu_dereference+0x9d/0xa5
[ 1001.499653]  [] gfn_to_memslot+0x8d/0xc8 [kvm]
[ 1001.499661]  [] gfn_to_hva+0x16/0x3f [kvm]
[ 1001.499669]  [] kvm_read_guest_page+0x1e/0x5e [kvm]
[ 1001.499681]  [] kvm_read_guest_page_mmu+0x53/0x5e [kvm]
[ 1001.499699]  [] load_pdptrs+0x3f/0x9c [kvm]
[ 1001.499705]  [] ? vmx_set_cr0+0x507/0x517 [kvm_intel]
[ 1001.499717]  [] kvm_arch_vcpu_ioctl_set_sregs+0x1f3/0x3c0 [kvm]
[ 1001.499727]  [] kvm_vcpu_ioctl+0x6a5/0xbc5 [kvm]
Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Instead of exchanging the guest and host rcx, have separate storage
for each.  This allows us to avoid using the xchg instruction, which
is is a little slower than normal operations.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Change

  push top-of-stack
  pop guest-rcx
  pop dummy

to

  pop guest-rcx

which is the same thing, only simpler.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

On some CPUs, a ple_gap of 41 is simply insufficient to ever trigger
PLE exits, even with the minimalistic PLE test from kvm-unit-tests.

http://git.kernel.org/?p=virt/kvm/kvm-unit-tests.git;a=commitdiff;h=eda71b28fa122203e316483b35f37aaacd42f545

For example, the Xeon X5670 CPU needs a ple_gap of at least 48 in
order to get pause loop exits:

# modprobe kvm_intel ple_gap=47
# taskset 1 /usr/local/bin/qemu-system-x86_64 \
  -device testdev,chardev=log -chardev stdio,id=log \
  -kernel x86/vmexit.flat -append ple-round-robin -smp 2
VNC server running on `::1:5900'
enabling apic
enabling apic
ple-round-robin 58298446
# rmmod kvm_intel
# modprobe kvm_intel ple_gap=48
# taskset 1 /usr/local/bin/qemu-system-x86_64 \
   -device testdev,chardev=log -chardev stdio,id=log \
   -kernel x86/vmexit.flat -append ple-round-robin -smp 2
VNC server running on `::1:5900'
enabling apic
enabling apic
ple-round-robin 36616

Increase the ple_gap to 128 to be on the safe side.
Signed-off-by: NRik van Riel <riel@redhat.com>
Acked-by: NZhai, Edwin <edwin.zhai@intel.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

This patch adds the necessary code to run perf-kvm on AMD
machines.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

When emulating real mode, we fake some state:

 - tr.base points to a fake vm86 tss
 - segment registers are made to conform to vm86 restrictions

change vmx_get_segment() not to expose this fake state to userspace;
instead, return the original state.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

When emulating real mode we play with tr hidden state, but leave
tr.selector alone.  That works well, except for save/restore, since
loading TR writes it to the hidden state in vmx->rmode.

Fix by also saving and restoring the tr selector; this makes things
more consistent and allows migration to work during the early
boot stages of Windows XP.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Previously SPRGs 4-7 were improperly read and written in
kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

WARNING: arch/x86/built-in.o(.text+0x1bb74): Section mismatch in reference from the function kvm_guest_cpu_online() to the function .cpuinit.text:kvm_guest_cpu_init()
The function kvm_guest_cpu_online() references
the function __cpuinit kvm_guest_cpu_init().
This is often because kvm_guest_cpu_online lacks a __cpuinit
annotation or the annotation of kvm_guest_cpu_init is wrong.

This patch fixes the warning.

Tested with linux-next (next-20101231)
Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
Acked-by: NRik van Riel <riel@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Instead, drop large mappings, which were the reason we dropped shadow.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

[petr: Second author]
[michael, geert: Cleanups and updates]
Signed-off-by: NMilan Jurik <milan.jurik@xylab.cz>
Signed-off-by: NPetr Stehlik <pstehlik@sophics.cz>
Signed-off-by: NMichael Schmitz <schmitz@debian.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: netdev@vger.kernel.org

[geert: Cleanups and updates]
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NPetr Stehlik <pstehlik@sophics.cz>

[geert: Cleanups and updates]
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NPetr Stehlik <pstehlik@sophics.cz>

Add improved support for running under the ARAnyM emulator
(Atari Running on Any Machine - http://aranym.org/).

[michael, geert: Cleanups and updates]
Signed-off-by: NPetr Stehlik <pstehlik@sophics.cz>
Signed-off-by: NMichael Schmitz <schmitz@debian.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Reported-by: NPhillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: Nmatt mooney <mfm@muteddisk.com>
Acked-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

On m68k, it doesn't make sense to reserve memory for the PPC exception
handlers, and APUS support is dead.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

This will be needed by the ARAnyM Native Feature initialization code.
Also document that the VEC_TRACE check is needed for 68020/30.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

So basic initialization is all in one place.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add helper function handle_kernel_fault() in signal.c, so frame_extra_sizes
can become static, and to avoid future code duplication.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

[AV: on architectures where default conflicts with existing
flags, that is]
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Support for Always Running APIC timer (ARAT) was introduced in
commit db954b58. This feature
allows us to avoid switching timers from LAPIC to something else
(e.g. HPET) and go into timer broadcasts when entering deep
C-states.

AMD processors don't provide a CPUID bit for that feature but
they also keep APIC timers running in deep C-states (except for
cases when the processor is affected by erratum 400). Therefore
we should set ARAT feature bit on AMD CPUs.
Tested-by: NBorislav Petkov <borislav.petkov@amd.com>
Acked-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: NMark Langsdorf <mark.langsdorf@amd.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com>
LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Commit 7f74f8f2
(x86 quirk: Fix polarity for IRQ0 pin2 override on SB800
systems) introduced a regression. It removed some SB600 specific
code to determine the revision ID without adapting a
corresponding revision ID check for SB600.

See this mail thread:

  http://marc.info/?l=linux-kernel&m=129980296006380&w=2

This patch adapts the corresponding check to cover all SB600
revisions.
Tested-by: NWang Lei <f3d27b@gmail.com>
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org # 38.x, 37.x, 32.x
LKML-Reference: <20110315143137.GD29499@alberich.amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a
core serializing instruction such as "cpuid" should be executed on _each_ core
before the new instruction is made visible.

Failure to do so can lead to unspecified behavior (Intel XMC erratas include
General Protection Fault in the list), so we should avoid this at all cost.

This problem can affect modified code executed by interrupt handlers after
interrupt are re-enabled at the end of stop_machine, because no core serializing
instruction is executed between the code modification and the moment interrupts
are reenabled.

Because stop_machine_text_poke performs the text modification from the first CPU
decrementing stop_machine_first, modified code executed in thread context is
also affected by this problem. To explain why, we have to split the CPUs in two
categories: the CPU that initiates the text modification (calls text_poke_smp)
and all the others. The scheduler, executed on all other CPUs after
stop_machine, issues an "iret" core serializing instruction, and therefore
handles core serialization for all these CPUs. However, the text modification
initiator can continue its execution on the same thread and access the modified
text without any scheduler call. Given that the CPU that initiates the code
modification is not guaranteed to be the one actually performing the code
modification, it falls into the XMC errata.

Q: Isn't this executed from an IPI handler, which will return with IRET (a
   serializing instruction) anyway?
A: No, now stop_machine uses per-cpu workqueue, so that handler will be
   executed from worker threads. There is no iret anymore.
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
LKML-Reference: <20110303160137.GB1590@Krystal>
Reviewed-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: <stable@kernel.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

The EDGE Port module of some ColdFire parts using the intc-simr interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The EDGE Port module of some ColdFire parts using the intc-2 interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The reality is that you do not need the abiltity to configure the
clock divider for ColdFire CPUs. It is a fixed ratio on any given
ColdFire family member. It is not the same for all ColdFire parts,
but it is always the same in a model range. So hard define the divider
for each supported ColdFire CPU type and remove the Kconfig option.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5407/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/532x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5307/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/527x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:39:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:55:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5272/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:67:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:68:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:69:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5249/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/523x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

rch/m68knommu/platform/520x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5206e/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast  CC      kernel/panic.o
arch/m68knommu/platform/5206e/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206e/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Fix these compiler warnings:

arch/m68knommu/platform/5206/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Signed-off-by: NAlexander Kurz <linux@kbdbabel.org>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The intc-simr interrupt controller on some ColdFire CPUs has a set range of
interrupts its supports (64 through 128 or 192 depending on model). We
shouldn't be setting this handler for every possible interrupt from 0 to
255. Set more appropriate limits, and this means we can drop the interrupt
number check in the mask and unmask routines.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>