Merge branch 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvm

4.29 KVM_GET_VCPU_EVENTS

Capability: KVM_CAP_VCPU_EVENTS

Extended by: KVM_CAP_INTR_SHADOW

Architectures: x86

Type: vm ioctl

Parameters: struct kvm_vcpu_event (out)

		__u8 injected;

		__u8 nr;

		__u8 soft;

		__u8 pad;

		__u8 shadow;

	} interrupt;

	struct {

		__u8 injected;

	__u32 flags;

};

KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that

interrupt.shadow contains a valid state. Otherwise, this field is undefined.

4.30 KVM_SET_VCPU_EVENTS

Capability: KVM_CAP_VCPU_EVENTS

Extended by: KVM_CAP_INTR_SHADOW

Architectures: x86

Type: vm ioctl

Parameters: struct kvm_vcpu_event (in)

KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel

KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector

If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in

the flags field to signal that interrupt.shadow contains a valid state and

shall be written into the VCPU.

4.32 KVM_GET_DEBUGREGS

Capability: KVM_CAP_DEBUGREGS

Architectures: x86

Type: vm ioctl

Parameters: struct kvm_debugregs (out)

Returns: 0 on success, -1 on error

Reads debug registers from the vcpu.

struct kvm_debugregs {

	__u64 db[4];

	__u64 dr6;

	__u64 dr7;

	__u64 flags;

	__u64 reserved[9];

};

4.33 KVM_SET_DEBUGREGS

Capability: KVM_CAP_DEBUGREGS

Architectures: x86

Type: vm ioctl

Parameters: struct kvm_debugregs (in)

Returns: 0 on success, -1 on error

Writes debug registers into the vcpu.

See KVM_GET_DEBUGREGS for the data structure. The flags field is unused

yet and must be cleared on entry.

4.34 KVM_SET_USER_MEMORY_REGION

Capability: KVM_CAP_USER_MEM

Architectures: all

Type: vm ioctl

Parameters: struct kvm_userspace_memory_region (in)

Returns: 0 on success, -1 on error

struct kvm_userspace_memory_region {

	__u32 slot;

	__u32 flags;

	__u64 guest_phys_addr;

	__u64 memory_size; /* bytes */

	__u64 userspace_addr; /* start of the userspace allocated memory */

};

/* for kvm_memory_region::flags */

#define KVM_MEM_LOG_DIRTY_PAGES  1UL

This ioctl allows the user to create or modify a guest physical memory

slot.  When changing an existing slot, it may be moved in the guest

physical memory space, or its flags may be modified.  It may not be

resized.  Slots may not overlap in guest physical address space.

Memory for the region is taken starting at the address denoted by the

field userspace_addr, which must point at user addressable memory for

the entire memory slot size.  Any object may back this memory, including

anonymous memory, ordinary files, and hugetlbfs.

It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr

be identical.  This allows large pages in the guest to be backed by large

pages in the host.

The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which

instructs kvm to keep track of writes to memory within the slot.  See

the KVM_GET_DIRTY_LOG ioctl.

When the KVM_CAP_SYNC_MMU capability, changes in the backing of the memory

region are automatically reflected into the guest.  For example, an mmap()

that affects the region will be made visible immediately.  Another example

is madvise(MADV_DROP).

It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.

The KVM_SET_MEMORY_REGION does not allow fine grained control over memory

allocation and is deprecated.

4.35 KVM_SET_TSS_ADDR

Capability: KVM_CAP_SET_TSS_ADDR

Architectures: x86

Type: vm ioctl

Parameters: unsigned long tss_address (in)

Returns: 0 on success, -1 on error

This ioctl defines the physical address of a three-page region in the guest

physical address space.  The region must be within the first 4GB of the

guest physical address space and must not conflict with any memory slot

or any mmio address.  The guest may malfunction if it accesses this memory

region.

This ioctl is required on Intel-based hosts.  This is needed on Intel hardware

because of a quirk in the virtualization implementation (see the internals

documentation when it pops into existence).

4.36 KVM_ENABLE_CAP

Capability: KVM_CAP_ENABLE_CAP

Architectures: ppc

Type: vcpu ioctl

Parameters: struct kvm_enable_cap (in)

Returns: 0 on success; -1 on error

+Not all extensions are enabled by default. Using this ioctl the application

can enable an extension, making it available to the guest.

On systems that do not support this ioctl, it always fails. On systems that

do support it, it only works for extensions that are supported for enablement.

To check if a capability can be enabled, the KVM_CHECK_EXTENSION ioctl should

be used.

struct kvm_enable_cap {

       /* in */

       __u32 cap;

The capability that is supposed to get enabled.

       __u32 flags;

A bitfield indicating future enhancements. Has to be 0 for now.

       __u64 args[4];

Arguments for enabling a feature. If a feature needs initial values to

function properly, this is the place to put them.

       __u8  pad[64];

};

4.37 KVM_GET_MP_STATE

Capability: KVM_CAP_MP_STATE

Architectures: x86, ia64

Type: vcpu ioctl

Parameters: struct kvm_mp_state (out)

Returns: 0 on success; -1 on error

struct kvm_mp_state {

	__u32 mp_state;

};

Returns the vcpu's current "multiprocessing state" (though also valid on

uniprocessor guests).

Possible values are:

 - KVM_MP_STATE_RUNNABLE:        the vcpu is currently running

 - KVM_MP_STATE_UNINITIALIZED:   the vcpu is an application processor (AP)

                                 which has not yet received an INIT signal

 - KVM_MP_STATE_INIT_RECEIVED:   the vcpu has received an INIT signal, and is

                                 now ready for a SIPI

 - KVM_MP_STATE_HALTED:          the vcpu has executed a HLT instruction and

                                 is waiting for an interrupt

 - KVM_MP_STATE_SIPI_RECEIVED:   the vcpu has just received a SIPI (vector

                                 accesible via KVM_GET_VCPU_EVENTS)

This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel

irqchip, the multiprocessing state must be maintained by userspace.

4.38 KVM_SET_MP_STATE

Capability: KVM_CAP_MP_STATE

Architectures: x86, ia64

Type: vcpu ioctl

Parameters: struct kvm_mp_state (in)

Returns: 0 on success; -1 on error

Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for

arguments.

This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel

irqchip, the multiprocessing state must be maintained by userspace.

5. The kvm_run structure

by kvm.  The 'data' member contains the written data if 'is_write' is

true, and should be filled by application code otherwise.

NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, 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

can re-enter the guest with an unmasked signal pending to complete

pending operations.

		/* KVM_EXIT_HYPERCALL */

		struct {

			__u64 nr;

			__u32 pad;

		} hypercall;

Unused.

Unused.  This was once used for 'hypercall to userspace'.  To implement

such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390).

Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.

		/* KVM_EXIT_TPR_ACCESS */

		struct {

powerpc specific.

		/* KVM_EXIT_OSI */

		struct {

			__u64 gprs[32];

		} osi;

MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch

hypercalls and exit with this exit struct that contains all the guest gprs.

If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.

Userspace can now handle the hypercall and when it's done modify the gprs as

necessary. Upon guest entry all guest GPRs will then be replaced by the values

in this struct.

		/* Fix the size of the union. */

		char padding[256];

	};

KVM CPUID bits

Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010

=====================================================

A guest running on a kvm host, can check some of its features using

cpuid. This is not always guaranteed to work, since userspace can

mask-out some, or even all KVM-related cpuid features before launching

a guest.

KVM cpuid functions are:

function: KVM_CPUID_SIGNATURE (0x40000000)

returns : eax = 0,

          ebx = 0x4b4d564b,

          ecx = 0x564b4d56,

          edx = 0x4d.

Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".

This function queries the presence of KVM cpuid leafs.

function: define KVM_CPUID_FEATURES (0x40000001)

returns : ebx, ecx, edx = 0

          eax = and OR'ed group of (1 << flag), where each flags is:

flag                               || value || meaning

=============================================================================

KVM_FEATURE_CLOCKSOURCE            ||     0 || kvmclock available at msrs

                                   ||       || 0x11 and 0x12.

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

KVM_FEATURE_NOP_IO_DELAY           ||     1 || not necessary to perform delays

                                   ||       || on PIO operations.

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

KVM_FEATURE_MMU_OP                 ||     2 || deprecated.

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

KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs

                                   ||       || 0x4b564d00 and 0x4b564d01

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

KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side

                                   ||       || per-cpu warps are expected in

                                   ||       || kvmclock.

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

The x86 kvm shadow mmu

======================

The mmu (in arch/x86/kvm, files mmu.[ch] and paging_tmpl.h) is responsible

for presenting a standard x86 mmu to the guest, while translating guest

physical addresses to host physical addresses.

The mmu code attempts to satisfy the following requirements:

- correctness: the guest should not be able to determine that it is running

               on an emulated mmu except for timing (we attempt to comply

               with the specification, not emulate the characteristics of

               a particular implementation such as tlb size)

- security:    the guest must not be able to touch host memory not assigned

               to it

- performance: minimize the performance penalty imposed by the mmu

- scaling:     need to scale to large memory and large vcpu guests

- hardware:    support the full range of x86 virtualization hardware

- integration: Linux memory management code must be in control of guest memory

               so that swapping, page migration, page merging, transparent

               hugepages, and similar features work without change

- dirty tracking: report writes to guest memory to enable live migration

               and framebuffer-based displays

- footprint:   keep the amount of pinned kernel memory low (most memory

               should be shrinkable)

- reliablity:  avoid multipage or GFP_ATOMIC allocations

Acronyms

========

pfn   host page frame number

hpa   host physical address

hva   host virtual address

gfn   guest frame number

gpa   guest physical address

gva   guest virtual address

ngpa  nested guest physical address

ngva  nested guest virtual address

pte   page table entry (used also to refer generically to paging structure

      entries)

gpte  guest pte (referring to gfns)

spte  shadow pte (referring to pfns)

tdp   two dimensional paging (vendor neutral term for NPT and EPT)

Virtual and real hardware supported

===================================

The mmu supports first-generation mmu hardware, which allows an atomic switch

of the current paging mode and cr3 during guest entry, as well as

two-dimensional paging (AMD's NPT and Intel's EPT).  The emulated hardware

it exposes is the traditional 2/3/4 level x86 mmu, with support for global

pages, pae, pse, pse36, cr0.wp, and 1GB pages.  Work is in progress to support

exposing NPT capable hardware on NPT capable hosts.

Translation

===========

The primary job of the mmu is to program the processor's mmu to translate

addresses for the guest.  Different translations are required at different

times:

- when guest paging is disabled, we translate guest physical addresses to

  host physical addresses (gpa->hpa)

- when guest paging is enabled, we translate guest virtual addresses, to

  guest physical addresses, to host physical addresses (gva->gpa->hpa)

- when the guest launches a guest of its own, we translate nested guest

  virtual addresses, to nested guest physical addresses, to guest physical

  addresses, to host physical addresses (ngva->ngpa->gpa->hpa)

The primary challenge is to encode between 1 and 3 translations into hardware

that support only 1 (traditional) and 2 (tdp) translations.  When the

number of required translations matches the hardware, the mmu operates in

direct mode; otherwise it operates in shadow mode (see below).

Memory

======

Guest memory (gpa) is part of the user address space of the process that is

using kvm.  Userspace defines the translation between guest addresses and user

addresses (gpa->hva); note that two gpas may alias to the same gva, but not

vice versa.

These gvas may be backed using any method available to the host: anonymous

memory, file backed memory, and device memory.  Memory might be paged by the

host at any time.

Events

======

The mmu is driven by events, some from the guest, some from the host.

Guest generated events:

- writes to control registers (especially cr3)

- invlpg/invlpga instruction execution

- access to missing or protected translations

Host generated events:

- changes in the gpa->hpa translation (either through gpa->hva changes or

  through hva->hpa changes)

- memory pressure (the shrinker)

Shadow pages

============

The principal data structure is the shadow page, 'struct kvm_mmu_page'.  A

shadow page contains 512 sptes, which can be either leaf or nonleaf sptes.  A

shadow page may contain a mix of leaf and nonleaf sptes.

A nonleaf spte allows the hardware mmu to reach the leaf pages and

is not related to a translation directly.  It points to other shadow pages.

A leaf spte corresponds to either one or two translations encoded into

one paging structure entry.  These are always the lowest level of the

translation stack, with optional higher level translations left to NPT/EPT.

Leaf ptes point at guest pages.

The following table shows translations encoded by leaf ptes, with higher-level

translations in parentheses:

 Non-nested guests:

  nonpaging:     gpa->hpa

  paging:        gva->gpa->hpa

  paging, tdp:   (gva->)gpa->hpa

 Nested guests:

  non-tdp:       ngva->gpa->hpa  (*)

  tdp:           (ngva->)ngpa->gpa->hpa

(*) the guest hypervisor will encode the ngva->gpa translation into its page

    tables if npt is not present

Shadow pages contain the following information:

  role.level:

    The level in the shadow paging hierarchy that this shadow page belongs to.

    1=4k sptes, 2=2M sptes, 3=1G sptes, etc.

  role.direct:

    If set, leaf sptes reachable from this page are for a linear range.

    Examples include real mode translation, large guest pages backed by small

    host pages, and gpa->hpa translations when NPT or EPT is active.

    The linear range starts at (gfn << PAGE_SHIFT) and its size is determined

    by role.level (2MB for first level, 1GB for second level, 0.5TB for third

    level, 256TB for fourth level)

    If clear, this page corresponds to a guest page table denoted by the gfn

    field.

  role.quadrant:

    When role.cr4_pae=0, the guest uses 32-bit gptes while the host uses 64-bit

    sptes.  That means a guest page table contains more ptes than the host,

    so multiple shadow pages are needed to shadow one guest page.

    For first-level shadow pages, role.quadrant can be 0 or 1 and denotes the

    first or second 512-gpte block in the guest page table.  For second-level

    page tables, each 32-bit gpte is converted to two 64-bit sptes

    (since each first-level guest page is shadowed by two first-level

    shadow pages) so role.quadrant takes values in the range 0..3.  Each

    quadrant maps 1GB virtual address space.

  role.access:

    Inherited guest access permissions in the form uwx.  Note execute

    permission is positive, not negative.

  role.invalid:

    The page is invalid and should not be used.  It is a root page that is

    currently pinned (by a cpu hardware register pointing to it); once it is

    unpinned it will be destroyed.

  role.cr4_pae:

    Contains the value of cr4.pae for which the page is valid (e.g. whether

    32-bit or 64-bit gptes are in use).

  role.cr4_nxe:

    Contains the value of efer.nxe for which the page is valid.

  role.cr0_wp:

    Contains the value of cr0.wp for which the page is valid.

  gfn:

    Either the guest page table containing the translations shadowed by this

    page, or the base page frame for linear translations.  See role.direct.

  spt:

    A pageful of 64-bit sptes containing the translations for this page.

    Accessed by both kvm and hardware.

    The page pointed to by spt will have its page->private pointing back

    at the shadow page structure.

    sptes in spt point either at guest pages, or at lower-level shadow pages.

    Specifically, if sp1 and sp2 are shadow pages, then sp1->spt[n] may point

    at __pa(sp2->spt).  sp2 will point back at sp1 through parent_pte.

    The spt array forms a DAG structure with the shadow page as a node, and

    guest pages as leaves.

  gfns:

    An array of 512 guest frame numbers, one for each present pte.  Used to

    perform a reverse map from a pte to a gfn.

  slot_bitmap:

    A bitmap containing one bit per memory slot.  If the page contains a pte

    mapping a page from memory slot n, then bit n of slot_bitmap will be set

    (if a page is aliased among several slots, then it is not guaranteed that

    all slots will be marked).

    Used during dirty logging to avoid scanning a shadow page if none if its

    pages need tracking.

  root_count:

    A counter keeping track of how many hardware registers (guest cr3 or

    pdptrs) are now pointing at the page.  While this counter is nonzero, the

    page cannot be destroyed.  See role.invalid.

  multimapped:

    Whether there exist multiple sptes pointing at this page.

  parent_pte/parent_ptes:

    If multimapped is zero, parent_pte points at the single spte that points at

    this page's spt.  Otherwise, parent_ptes points at a data structure

    with a list of parent_ptes.

  unsync:

    If true, then the translations in this page may not match the guest's

    translation.  This is equivalent to the state of the tlb when a pte is

    changed but before the tlb entry is flushed.  Accordingly, unsync ptes

    are synchronized when the guest executes invlpg or flushes its tlb by

    other means.  Valid for leaf pages.

  unsync_children:

    How many sptes in the page point at pages that are unsync (or have

    unsynchronized children).

  unsync_child_bitmap:

    A bitmap indicating which sptes in spt point (directly or indirectly) at

    pages that may be unsynchronized.  Used to quickly locate all unsychronized

    pages reachable from a given page.

Reverse map

===========

The mmu maintains a reverse mapping whereby all ptes mapping a page can be

reached given its gfn.  This is used, for example, when swapping out a page.

Synchronized and unsynchronized pages

=====================================

The guest uses two events to synchronize its tlb and page tables: tlb flushes

and page invalidations (invlpg).

A tlb flush means that we need to synchronize all sptes reachable from the

guest's cr3.  This is expensive, so we keep all guest page tables write

protected, and synchronize sptes to gptes when a gpte is written.

A special case is when a guest page table is reachable from the current

guest cr3.  In this case, the guest is obliged to issue an invlpg instruction

before using the translation.  We take advantage of that by removing write

protection from the guest page, and allowing the guest to modify it freely.

We synchronize modified gptes when the guest invokes invlpg.  This reduces

the amount of emulation we have to do when the guest modifies multiple gptes,

or when the a guest page is no longer used as a page table and is used for

random guest data.

As a side effect we have to resynchronize all reachable unsynchronized shadow

pages on a tlb flush.

Reaction to events

==================

- guest page fault (or npt page fault, or ept violation)

This is the most complicated event.  The cause of a page fault can be:

  - a true guest fault (the guest translation won't allow the access) (*)

  - access to a missing translation

  - access to a protected translation

    - when logging dirty pages, memory is write protected

    - synchronized shadow pages are write protected (*)

  - access to untranslatable memory (mmio)

  (*) not applicable in direct mode

Handling a page fault is performed as follows:

 - if needed, walk the guest page tables to determine the guest translation

   (gva->gpa or ngpa->gpa)

   - if permissions are insufficient, reflect the fault back to the guest

 - determine the host page

   - if this is an mmio request, there is no host page; call the emulator

     to emulate the instruction instead

 - walk the shadow page table to find the spte for the translation,

   instantiating missing intermediate page tables as necessary

 - try to unsynchronize the page

   - if successful, we can let the guest continue and modify the gpte

 - emulate the instruction

   - if failed, unshadow the page and let the guest continue

 - update any translations that were modified by the instruction

invlpg handling:

  - walk the shadow page hierarchy and drop affected translations

  - try to reinstantiate the indicated translation in the hope that the

    guest will use it in the near future

Guest control register updates:

- mov to cr3

  - look up new shadow roots

  - synchronize newly reachable shadow pages

- mov to cr0/cr4/efer

  - set up mmu context for new paging mode

  - look up new shadow roots

  - synchronize newly reachable shadow pages

Host translation updates:

  - mmu notifier called with updated hva

  - look up affected sptes through reverse map

  - drop (or update) translations

Further reading

===============

- NPT presentation from KVM Forum 2008

  http://www.linux-kvm.org/wiki/images/c/c8/KvmForum2008%24kdf2008_21.pdf

		r = -EFAULT;

		if (copy_from_user(&irq_event, argp, sizeof irq_event))

			goto out;

		r = -ENXIO;

		if (irqchip_in_kernel(kvm)) {

			__s32 status;

			status = kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID,

				    irq_event.irq, irq_event.level);

			if (ioctl == KVM_IRQ_LINE_STATUS) {

				r = -EFAULT;

				irq_event.status = status;

				if (copy_to_user(argp, &irq_event,

							sizeof irq_event))

	int i, j;

	unsigned long base_gfn;

	slots = rcu_dereference(kvm->memslots);

	slots = kvm_memslots(kvm);

	for (i = 0; i < slots->nmemslots; i++) {

		memslot = &slots->memslots[i];

		base_gfn = memslot->base_gfn;

			goto out;

		if (copy_to_user(user_stack, stack,

				 sizeof(struct kvm_ia64_vcpu_stack)))

				 sizeof(struct kvm_ia64_vcpu_stack))) {

			r = -EFAULT;

			goto out;

		}

		break;

	}

	vmm_fpswa_interface = fpswa_interface;

	/*Register vmm data to kvm side*/

	return kvm_init(&vmm_info, 1024, THIS_MODULE);

	return kvm_init(&vmm_info, 1024, 0, THIS_MODULE);

}

static void __exit kvm_vmm_exit(void)