Merge tag 'signed-kvm-ppc-next' of git://github.com/agraf/linux-2.6 into kvm

	- Documentation on the firmware assisted dump mechanism "fadump".

hvcs.txt

	- IBM "Hypervisor Virtual Console Server" Installation Guide

kvm_440.txt

	- Various notes on the implementation of KVM for PowerPC 440.

mpc52xx.txt

	- Linux 2.6.x on MPC52xx family

pmu-ebb.txt

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.

4.4 KVM_CHECK_EXTENSION

Capability: basic

Capability: basic, KVM_CAP_CHECK_EXTENSION_VM for vm ioctl

Architectures: all

Type: system ioctl

Type: system ioctl, vm ioctl

Parameters: extension identifier (KVM_CAP_*)

Returns: 0 if unsupported; 1 (or some other positive integer) if supported

Generally 0 means no and 1 means yes, but some extensions may report

additional information in the integer return value.

Based on their initialization different VMs may have different capabilities.

It is thus encouraged to use the vm ioctl to query for capabilities (available

with KVM_CAP_CHECK_EXTENSION_VM on the vm fd)

4.5 KVM_GET_VCPU_MMAP_SIZE

  PPC   | KVM_REG_PPC_PID               | 64

  PPC   | KVM_REG_PPC_ACOP              | 64

  PPC   | KVM_REG_PPC_VRSAVE            | 32

  PPC   | KVM_REG_PPC_LPCR              | 64

  PPC   | KVM_REG_PPC_LPCR              | 32

  PPC   | KVM_REG_PPC_LPCR_64           | 64

  PPC   | KVM_REG_PPC_PPR               | 64

  PPC   | KVM_REG_PPC_ARCH_COMPAT       | 32

  PPC   | KVM_REG_PPC_DABRX             | 32

appear if the VCPU performed a load or store of the appropriate width directly

to the byte array.

NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR,

      KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding

NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR and

      KVM_EXIT_EPR the corresponding

operations are complete (and guest state is consistent) only after userspace

has re-entered the kernel with KVM_RUN.  The kernel side will first finish

incomplete operations and then check for pending signals.  Userspace

			__u8  is_write;

		} dcr;

powerpc specific.

Deprecated - was used for 440 KVM.

		/* KVM_EXIT_OSI */

		struct {

         this function/index combination

6. Capabilities that can be enabled

-----------------------------------

6. Capabilities that can be enabled on vCPUs

--------------------------------------------

There are certain capabilities that change the behavior of the virtual CPU or

the virtual machine when enabled. To enable them, please see section 4.37.

This capability enables the in-kernel irqchip for s390. Please refer to

"4.24 KVM_CREATE_IRQCHIP" for details.

7. Capabilities that can be enabled on VMs

------------------------------------------

There are certain capabilities that change the behavior of the virtual

machine when enabled. To enable them, please see section 4.37. Below

you can find a list of capabilities and what their effect on the VM

is when enabling them.

The following information is provided along with the description:

  Architectures: which instruction set architectures provide this ioctl.

      x86 includes both i386 and x86_64.

  Parameters: what parameters are accepted by the capability.

  Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)

      are not detailed, but errors with specific meanings are.

7.1 KVM_CAP_PPC_ENABLE_HCALL

Architectures: ppc

Parameters: args[0] is the sPAPR hcall number

	    args[1] is 0 to disable, 1 to enable in-kernel handling

This capability controls whether individual sPAPR hypercalls (hcalls)

get handled by the kernel or not.  Enabling or disabling in-kernel

handling of an hcall is effective across the VM.  On creation, an

initial set of hcalls are enabled for in-kernel handling, which

consists of those hcalls for which in-kernel handlers were implemented

before this capability was implemented.  If disabled, the kernel will

not to attempt to handle the hcall, but will always exit to userspace

to handle it.  Note that it may not make sense to enable some and

disable others of a group of related hcalls, but KVM does not prevent

userspace from doing that.

If the hcall number specified is not one that has an in-kernel

implementation, the KVM_ENABLE_CAP ioctl will fail with an EINVAL

error.

	}

}

int kvm_dev_ioctl_check_extension(long ext)

int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)

{

	int r;

	switch (ext) {

	*(int *)rtn = 0;

}

int kvm_dev_ioctl_check_extension(long ext)

int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)

{

	int r;