Merge branch 'kvm-updates-2.6.26' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm

Currently, kvm module in EXPERIMENTAL stage on IA64. This means that

interfaces are not stable enough to use. So, plase had better don't run

critical applications in virtual machine. We will try our best to make it

strong in future versions!

				Guide: How to boot up guests on kvm/ia64

This guide is to describe how to enable kvm support for IA-64 systems.

1. Get the kvm source from git.kernel.org.

	Userspace source:

		git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git

	Kernel Source:

		git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git

2. Compile the source code.

	2.1 Compile userspace code:

		(1)cd ./kvm-userspace

		(2)./configure

		(3)cd kernel

		(4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)

		(5)cd ..

		(6)make qemu

		(7)cd qemu; make install

	2.2 Compile kernel source code:

		(1) cd ./$kernel_dir

		(2) Make menuconfig

		(3) Enter into virtualization option, and choose kvm.

		(4) make

		(5) Once (4) done, make modules_install

		(6) Make initrd, and use new kernel to reboot up host machine.

		(7) Once (6) done, cd $kernel_dir/arch/ia64/kvm

		(8) insmod kvm.ko; insmod kvm-intel.ko

Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.

3. Get Guest Firmware named as Flash.fd, and put it under right place:

	(1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.

	(2) If you have no firmware at hand, Please download its source from

		hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg

	    you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.

	(3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu

4. Boot up Linux or Windows guests:

	4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.

	4.2 Boot up guests use the following command.

		/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image

		(xx is the number of virtual processors for the guest, now the maximum value is 4)

5. Known possibile issue on some platforms with old Firmware.

If meet strange host crashe issues, try to solve it through either of the following ways:

(1): Upgrade your Firmware to the latest one.

(2): Applying the below patch to kernel source.

diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S

index 0b53344..f02b0f7 100644

--- a/arch/ia64/kernel/pal.S

+++ b/arch/ia64/kernel/pal.S

@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)

	mov ar.pfs = loc1

	mov rp = loc0

	;;

-	srlz.d				// seralize restoration of psr.l

+	srlz.i			// seralize restoration of psr.l

+	;;

	br.ret.sptk.many b0

 END(ia64_pal_call_static)

6. Bug report:

	If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.

	https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/

Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!

								Xiantao Zhang <xiantao.zhang@intel.com>

											2008.3.10

0xAC	00-1F	linux/raw.h

0xAD	00	Netfilter device	in development:

					<mailto:rusty@rustcorp.com.au>	

0xAE	all	linux/kvm.h		Kernel-based Virtual Machine

					<mailto:kvm-devel@lists.sourceforge.net>

0xB0	all	RATIO devices		in development:

					<mailto:vgo@ratio.de>

0xB1	00-1F	PPPoX			<mailto:mostrows@styx.uwaterloo.ca>

Hollis Blanchard <hollisb@us.ibm.com>

15 Apr 2008

Various notes on the implementation of KVM for PowerPC 440:

To enforce isolation, host userspace, guest kernel, and guest userspace all

run at user privilege level. Only the host kernel runs in supervisor mode.

Executing privileged instructions in the guest traps into KVM (in the host

kernel), where we decode and emulate them. Through this technique, unmodified

440 Linux kernels can be run (slowly) as guests. Future performance work will

focus on reducing the overhead and frequency of these traps.

The usual code flow is started from userspace invoking an "run" ioctl, which

causes KVM to switch into guest context. We use IVPR to hijack the host

interrupt vectors while running the guest, which allows us to direct all

interrupts to kvmppc_handle_interrupt(). At this point, we could either

- handle the interrupt completely (e.g. emulate "mtspr SPRG0"), or

- let the host interrupt handler run (e.g. when the decrementer fires), or

- return to host userspace (e.g. when the guest performs device MMIO)

Address spaces: We take advantage of the fact that Linux doesn't use the AS=1

address space (in host or guest), which gives us virtual address space to use

for guest mappings. While the guest is running, the host kernel remains mapped

in AS=0, but the guest can only use AS=1 mappings.

TLB entries: The TLB entries covering the host linear mapping remain

present while running the guest. This reduces the overhead of lightweight

exits, which are handled by KVM running in the host kernel. We keep three

copies of the TLB:

 - guest TLB: contents of the TLB as the guest sees it

 - shadow TLB: the TLB that is actually in hardware while guest is running

 - host TLB: to restore TLB state when context switching guest -> host

When a TLB miss occurs because a mapping was not present in the shadow TLB,

but was present in the guest TLB, KVM handles the fault without invoking the

guest. Large guest pages are backed by multiple 4KB shadow pages through this

mechanism.

IO: MMIO and DCR accesses are emulated by userspace. We use virtio for network

and block IO, so those drivers must be enabled in the guest. It's possible

that some qemu device emulation (e.g. e1000 or rtl8139) may also work with

little effort.

*** BIG FAT WARNING ***

The kvm module is currently in EXPERIMENTAL state for s390. This means that

the interface to the module is not yet considered to remain stable. Thus, be

prepared that we keep breaking your userspace application and guest

compatibility over and over again until we feel happy with the result. Make sure

your guest kernel, your host kernel, and your userspace launcher are in a

consistent state.

This Documentation describes the unique ioctl calls to /dev/kvm, the resulting

kvm-vm file descriptors, and the kvm-vcpu file descriptors that differ from x86.

1. ioctl calls to /dev/kvm

KVM does support the following ioctls on s390 that are common with other

architectures and do behave the same:

KVM_GET_API_VERSION

KVM_CREATE_VM		(*) see note

KVM_CHECK_EXTENSION

KVM_GET_VCPU_MMAP_SIZE

Notes:

* KVM_CREATE_VM may fail on s390, if the calling process has multiple

threads and has not called KVM_S390_ENABLE_SIE before.

In addition, on s390 the following architecture specific ioctls are supported:

ioctl:		KVM_S390_ENABLE_SIE

args:		none

see also:	include/linux/kvm.h

This call causes the kernel to switch on PGSTE in the user page table. This

operation is needed in order to run a virtual machine, and it requires the

calling process to be single-threaded. Note that the first call to KVM_CREATE_VM

will implicitly try to switch on PGSTE if the user process has not called

KVM_S390_ENABLE_SIE before. User processes that want to launch multiple threads

before creating a virtual machine have to call KVM_S390_ENABLE_SIE, or will

observe an error calling KVM_CREATE_VM. Switching on PGSTE is a one-time

operation, is not reversible, and will persist over the entire lifetime of

the calling process. It does not have any user-visible effect other than a small

performance penalty.

2. ioctl calls to the kvm-vm file descriptor

KVM does support the following ioctls on s390 that are common with other

architectures and do behave the same:

KVM_CREATE_VCPU

KVM_SET_USER_MEMORY_REGION      (*) see note

KVM_GET_DIRTY_LOG		(**) see note

Notes:

*  kvm does only allow exactly one memory slot on s390, which has to start

   at guest absolute address zero and at a user address that is aligned on any

   page boundary. This hardware "limitation" allows us to have a few unique

   optimizations. The memory slot doesn't have to be filled

   with memory actually, it may contain sparse holes. That said, with different

   user memory layout this does still allow a large flexibility when

   doing the guest memory setup.

** KVM_GET_DIRTY_LOG doesn't work properly yet. The user will receive an empty

log. This ioctl call is only needed for guest migration, and we intend to

implement this one in the future.

In addition, on s390 the following architecture specific ioctls for the kvm-vm

file descriptor are supported:

ioctl:		KVM_S390_INTERRUPT

args:		struct kvm_s390_interrupt *

see also:	include/linux/kvm.h

This ioctl is used to submit a floating interrupt for a virtual machine.

Floating interrupts may be delivered to any virtual cpu in the configuration.

Only some interrupt types defined in include/linux/kvm.h make sense when

submitted as floating interrupts. The following interrupts are not considered

to be useful as floating interrupts, and a call to inject them will result in

-EINVAL error code: program interrupts and interprocessor signals. Valid

floating interrupts are:

KVM_S390_INT_VIRTIO

KVM_S390_INT_SERVICE

3. ioctl calls to the kvm-vcpu file descriptor

KVM does support the following ioctls on s390 that are common with other

architectures and do behave the same:

KVM_RUN

KVM_GET_REGS

KVM_SET_REGS

KVM_GET_SREGS

KVM_SET_SREGS

KVM_GET_FPU

KVM_SET_FPU

In addition, on s390 the following architecture specific ioctls for the

kvm-vcpu file descriptor are supported:

ioctl:		KVM_S390_INTERRUPT

args:		struct kvm_s390_interrupt *

see also:	include/linux/kvm.h

This ioctl is used to submit an interrupt for a specific virtual cpu.

Only some interrupt types defined in include/linux/kvm.h make sense when

submitted for a specific cpu. The following interrupts are not considered

to be useful, and a call to inject them will result in -EINVAL error code:

service processor calls and virtio interrupts. Valid interrupt types are:

KVM_S390_PROGRAM_INT

KVM_S390_SIGP_STOP

KVM_S390_RESTART

KVM_S390_SIGP_SET_PREFIX

KVM_S390_INT_EMERGENCY

ioctl:		KVM_S390_STORE_STATUS

args:		unsigned long

see also:	include/linux/kvm.h

This ioctl stores the state of the cpu at the guest real address given as

argument, unless one of the following values defined in include/linux/kvm.h

is given as arguement:

KVM_S390_STORE_STATUS_NOADDR - the CPU stores its status to the save area in

absolute lowcore as defined by the principles of operation

KVM_S390_STORE_STATUS_PREFIXED - the CPU stores its status to the save area in

its prefix page just like the dump tool that comes with zipl. This is useful

to create a system dump for use with lkcdutils or crash.

ioctl:		KVM_S390_SET_INITIAL_PSW

args:		struct kvm_s390_psw *

see also:	include/linux/kvm.h

This ioctl can be used to set the processor status word (psw) of a stopped cpu

prior to running it with KVM_RUN. Note that this call is not required to modify

the psw during sie intercepts that fall back to userspace because struct kvm_run

does contain the psw, and this value is evaluated during reentry of KVM_RUN

after the intercept exit was recognized.

ioctl:		KVM_S390_INITIAL_RESET

args:		none

see also:	include/linux/kvm.h

This ioctl can be used to perform an initial cpu reset as defined by the

principles of operation. The target cpu has to be in stopped state.

W:	kvm.sourceforge.net

S:	Supported

KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC

P:	Hollis Blanchard

M:	hollisb@us.ibm.com

L:	kvm-ppc-devel@lists.sourceforge.net

W:	kvm.sourceforge.net

S:	Supported

KERNEL VIRTUAL MACHINE For Itanium(KVM/IA64)

P:	Anthony Xu

M:	anthony.xu@intel.com

W:	kvm.sourceforge.net

S:	Supported

KERNEL VIRTUAL MACHINE for s390 (KVM/s390)

P:	Carsten Otte

M:	cotte@de.ibm.com

P:	Christian Borntraeger

M:	borntraeger@de.ibm.com

M:	linux390@de.ibm.com

L:	linux-s390@vger.kernel.org

W:	http://www.ibm.com/developerworks/linux/linux390/

S:	Supported

KEXEC

P:	Eric Biederman

M:	ebiederm@xmission.com