KVM - User contributions [en]

TODO

2012-07-11T14:51:18Z

AviKivity:

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement ACPI memory hotplug
* Improve ballooning to try to use 2MB pages when possible ( in progress - kern.devel@gmail.com )

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* Simpler variant: don't drop large ptes when write protecting; just write protect them. When taking a write fault, either drop the large pte, or convert it to small ptes and write protect those (like O(1) write protection).
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* On-demand register access, really, copying all registers all the time is gross.
** Can be done by adding 'available' and 'dirty' bitmasks
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga (partially done)
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* convert more instructions to direct dispatch (function pointer in decode table)
* move init_emulate_ctxt() into x86_decode_insn() and other emulator entry points

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS
* USB 2.0 (EHCI) support

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== Random improvements ====
* Utilize the SVM interrupt queue to avoid extra exits when guest interrupts are disabled

==== For the adventurous: ====
* Emulate the VMX instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Add [http://lagarcavilla.org/vmgl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.
* Keep this TODO up to date

==== Nested VMX ====
* Implement performance features such as EPT and VPID

== KVM Safe Mode ==

An ioctl() from userspace that tells KVM to disable one or more of the following features:

* shadow paging (force direct mapping)
* instruction emulation (require virtio or mmio hypercall)
* task switches
* mode switches (long mode / legacy mode / real mode)
* IDT/GDT/LDT changes
* IDT/GDT/LDT write protect
* write protect important MSRs (*STAR etc)

The idea is both to protect the guest from attacks, and to protect the host from the guest.

__NOTOC__

TODO

2012-07-11T14:50:28Z

AviKivity: Clean up completed tasks

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement ACPI memory hotplug
* Improve ballooning to try to use 2MB pages when possible ( in progress - kern.devel@gmail.com )

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* Simpler variant: don't drop large ptes when write protecting; just write protect them. When taking a write fault, either drop the large pte, or convert it to small ptes and write protect those (like O(1) write protection).
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* On-demand register access, really, copying all registers all the time is gross.
** Can be done by adding 'available' and 'dirty' bitmasks
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga (partially done)
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* convert more instructions to direct dispatch (function pointer in decode table)
* move init_emulate_ctxt() into x86_decode_insn() and other emulator entry points

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS
* USB 2.0 (EHCI) support

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== Random improvements ====
* Utilize the SVM interrupt queue to avoid extra exits when guest interrupts are disabled

==== For the adventurous: ====
* Emulate the VMX instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Add [http://lagarcavilla.org/vmgl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.
* Keep this TODO up to date

==== Nested VMX ====
* Implement performance features such as EPT and VPID

== KVM Safe Mode ==

An ioctl() from userspace that tells KVM to disable one or more of the following features:

- shadow paging (force direct mapping)
- instruction emulation (require virtio or mmio hypercall)
- task switches
- mode switches (long mode / legacy mode / real mode)
- IDT/GDT/LDT changes
- IDT/GDT/LDT write protect
- write protect important MSRs (*STAR etc)

The idea is both to protect the guest from attacks, and to protect the host from the guest.

__NOTOC__

TODO

2012-04-16T12:45:33Z

AviKivity:

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement ACPI memory hotplug
* Improve ballooning to try to use 2MB pages when possible ( in progress - kern.devel@gmail.com )
* [[Guest PMU]] support

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Reduce qemu memory footprint when using kvm
** this involves dropping the PhysPageDesc array in favour of a memslot-like approach
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* Simpler variant: don't drop large ptes when write protecting; just write protect them. When taking a write fault, either drop the large pte, or convert it to small ptes and write protect those (like O(1) write protection).
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Same for ordinary registers, really, copying all registers all the time is gross.
** Can be done by adding 'available' and 'dirty' bitmasks
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga (partially done)
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* convert more instructions to direct dispatch (function pointer in decode table)
* fold 'struct decode_cache' into 'struct x88_emulate_context'; reducing a lot of pointless temporary variables.
* move init_emulate_ctxt() into x86_decode_insn() and other emulator entry points

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS
* USB 2.0 (EHCI) support

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== Random improvements ====
* Utilize the SVM interrupt queue to avoid extra exits when guest interrupts are disabled

==== For the adventurous: ====
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Add [http://lagarcavilla.org/vmgl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.
* Keep this TODO up to date

==== Nested VMX ====
* Implement performance features such as EPT and VPID

== KVM Safe Mode ==

An ioctl() from userspace that tells KVM to disable one or more of the following features:

- shadow paging (force direct mapping)
- instruction emulation (require virtio or mmio hypercall)
- task switches
- mode switches (long mode / legacy mode / real mode)
- IDT/GDT/LDT changes
- IDT/GDT/LDT write protect
- write protect important MSRs (*STAR etc)

The idea is both to protect the guest from attacks, and to protect the host from the guest.

__NOTOC__

TODO

2012-03-29T13:16:19Z

AviKivity:

Guest PMU

2011-09-06T06:41:21Z

AviKivity:

Guest PMU (Performance Monitoring Unit) currently exists in the form of an out-of-tree patchset.

See the [http://www.linux-kvm.org/wiki/images/6/6d/Kvm-forum-2011-performance-monitoring.pdf|KVM Forum 2011 presentation] about the state as of August 2011.

= Current status =

Version 1 Architectural PMU on Intel and AMD hosts is implemented and works.

= TODO =

== Guest visible features ==
* Implement Version 2 Architectural PMU - allows faster switch times using PERF_GLOBAL_ENABLE MSR
* Implement Version 3 Architectural PMU
* Model specific PMU - allows access to more events and support for more tools; but restricts live migration capabilities
** Need per-event validation to avoid leaking socket-wide or core-wide information
* PEBS - Preceise Event Based Sampling - allows examining program state
* BTS - Branch Trace Store - allows tracing program execution accurately

== Accuracy ==

* Update Joerg Roedel's exclude_guest/exclude_host patchset to support Intel hosts, using vmx's ability to load PERF_GLOBAL_ENABLE on vmentry/vmexit

== Performance ==

* Investigate reports that enabling the guest PMU reduces performance
* Update the perf_event subsystem to make use of the PERF_GLOBAL_ENABLE MSR to speed up context switching, on both guest and host
* Check whether perf_event does unnecessary RMW operations on MSRs, which are significantly slow in a guest
* Add a paravirt batch MSR read/write facility, update perf to use it when available
* Change perf to use an ordinary interrupt instead of NMI when profiling only user space, or only a guest (reduces work in NMI context)

= Git repositories =

Guest PMU: git://github.com/avikivity/kvm.git pmu

exclude_host: git://github.com/avikivity/kvm.git perf-guest-counting

Guest PMU

2011-09-06T06:40:16Z

AviKivity:

Guest PMU (Performance Monitoring Unit) currently exists in the form of an out-of-tree patchset.

See the [http://www.linux-kvm.org/wiki/images/6/6d/Kvm-forum-2011-performance-monitoring.pdf|KVM Forum 2011 presentation] about the state as of August 2011.

= Current status =

Version 1 Architectural PMU on Intel and AMD hosts is implemented and works.

= TODO =

== Guest visible features ==
* Implement Version 2 Architectural PMU - allows faster switch times using PERF_GLOBAL_ENABLE MSR
* Implement Version 3 Architectural PMU
* Model specific PMU - allows access to more events and support for more tools; but restricts live migration capabilities
** Need per-event validation to avoid leaking socket-wide or core-wide information
* PEBS - Preceise Event Based Sampling - allows examining program state
* BTS - Branch Trace Store - allows tracing program execution accurately

== Accuracy ==

* Update Joerg Roedel's exclude_guest/exclude_host patchset to support Intel hosts, using vmx's ability to load PERF_GLOBAL_ENABLE on vmentry/vmexit

== Performance ==

* Investigate reports that enabling the guest PMU reduces performance
* Update the perf_event subsystem to make use of the PERF_GLOBAL_ENABLE MSR to speed up context switching, on both guest and host
* Check whether perf_event does unnecessary RMW operations on MSRs, which are significantly slow in a guest
* Add a paravirt batch MSR read/write facility, update perf to use it when available
* Change perf to use an ordinary interrupt instead of NMI when profiling only user space (reduces work in NMI context)

= Git repositories =

Guest PMU: git://github.com/avikivity/kvm.git pmu

exclude_host: git://github.com/avikivity/kvm.git perf-guest-counting

Guest PMU

2011-09-05T14:37:42Z

AviKivity:

Guest PMU (Performance Monitoring Unit) currently exists in the form of an out-of-tree patchset.

See the [http://www.linux-kvm.org/wiki/images/6/6d/Kvm-forum-2011-performance-monitoring.pdf|KVM Forum 2011 presentation] about the state as of August 2011.

= Current status =

Version 1 Architectural PMU on Intel and AMD hosts is implemented and works.

= TODO =

== Guest visible features ==
* Implement Version 2 Architectural PMU - allows faster switch times using PERF_GLOBAL_ENABLE MSR
* Implement Version 3 Architectural PMU
* Model specific PMU - allows access to more events and support for more tools; but restricts live migration capabilities
** Need per-event validation to avoid leaking socket-wide or core-wide information
* PEBS - Preceise Event Based Sampling - allows examining program state
* BTS - Branch Trace Store - allows tracing program execution accurately

== Accuracy ==

* Update Joerg Roedel's exclude_guest/exclude_host patchset to support Intel hosts, using vmx's ability to load PERF_GLOBAL_ENABLE on vmentry/vmexit

== Performance ==

* Investigate reports that enabling the guest PMU reduces performance
* Update the perf_event subsystem to make use of the PERF_GLOBAL_ENABLE MSR to speed up context switching, on both guest and host
* Check whether perf_event does unnecessary RMW operations on MSRs, which are significantly slow in a guest
* Add a paravirt batch MSR read/write facility, update perf to use it when available

= Git repositories =

Guest PMU: git://github.com/avikivity/kvm.git pmu

exclude_host: git://github.com/avikivity/kvm.git perf-guest-counting

Guest PMU

2011-09-05T14:37:26Z

AviKivity: added git repos

Guest PMU (Performance Monitoring Unit) currently exists in the form of an out-of-tree patchset.

See the [http://www.linux-kvm.org/wiki/images/6/6d/Kvm-forum-2011-performance-monitoring.pdf|KVM Forum 2011 presentation] about the state as of August 2011.

= Current status =

Version 1 Architectural PMU on Intel and AMD hosts is implemented and works.

= TODO =

== Guest visible features ==
* Implement Version 2 Architectural PMU - allows faster switch times using PERF_GLOBAL_ENABLE MSR
* Implement Version 3 Architectural PMU
* Model specific PMU - allows access to more events and support for more tools; but restricts live migration capabilities
** Need per-event validation to avoid leaking socket-wide or core-wide information
* PEBS - Preceise Event Based Sampling - allows examining program state
* BTS - Branch Trace Store - allows tracing program execution accurately

== Accuracy ==

* Update Joerg Roedel's exclude_guest/exclude_host patchset to support Intel hosts, using vmx's ability to load PERF_GLOBAL_ENABLE on vmentry/vmexit

== Performance ==

* Investigate reports that enabling the guest PMU reduces performance
* Update the perf_event subsystem to make use of the PERF_GLOBAL_ENABLE MSR to speed up context switching, on both guest and host
* Check whether perf_event does unnecessary RMW operations on MSRs, which are significantly slow in a guest
* Add a paravirt batch MSR read/write facility, update perf to use it when available

= Git repositories =

Guest PMU: git://github.com/avikivity/kvm.git pmu
exclude_host: git://github.com/avikivity/kvm.git perf-guest-counting

Guest PMU

2011-09-05T08:54:22Z

AviKivity:

Guest PMU

2011-09-05T08:48:05Z

AviKivity:

Guest PMU (Performance Monitoring Unit) currently exists in the form of an out-of-tree patchset.

= Current status =

Version 1 Architectural PMU on Intel and AMD hosts is implemented and works.

= TODO =

== Guest visible features ==
* Implement Version 2 Architectural PMU - allows faster switch times using PERF_GLOBAL_ENABLE MSR
* Implement Version 3 Architectural PMU
* Model specific PMU - allows access to more events and support for more tools; but restricts live migration capabilities
** Need per-event validation to avoid leaking socket-wide or core-wide information
* PEBS - Preceise Event Based Sampling - allows examining program state
* BTS - Branch Trace Store - allows tracing program execution accurately

== Accuracy ==

* Update Joerg Roedel's exclude_guest/exclude_host patchset to support Intel hosts, using vmx's ability to load PERF_GLOBAL_ENABLE on vmentry/vmexit

== Performance ==

* Investigate reports that enabling the guest PMU reduces performance
* Update the perf_event subsystem to make use of the PERF_GLOBAL_ENABLE MSR to speed up context switching, on both guest and host
* Check whether perf_event does unnecessary RMW operations on MSRs, which are significantly slow in a guest
* Add a paravirt batch MSR read/write facility, update perf to use it when available

TODO

2011-09-05T08:36:32Z

AviKivity:

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement ACPI memory hotplug
* Improve ballooning to try to use 2MB pages when possible ( in progress - kern.devel@gmail.com )
* [[Guest PMU]] support

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Reduce qemu memory footprint when using kvm
** this involves dropping the PhysPageDesc array in favour of a memslot-like approach
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Same for ordinary registers, really, copying all registers all the time is gross.
** Can be done by adding 'available' and 'dirty' bitmasks
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga (partially done)
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* convert more instructions to direct dispatch (function pointer in decode table)
* fold 'struct decode_cache' into 'struct x88_emulate_context'; reducing a lot of pointless temporary variables.
* move init_emulate_ctxt() into x86_decode_insn() and other emulator entry points

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS
* USB 2.0 (EHCI) support

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== Random improvements ====
* Utilize the SVM interrupt queue to avoid extra exits when guest interrupts are disabled

==== For the adventurous: ====
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Add [http://lagarcavilla.org/vmgl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.
* Keep this TODO up to date

==== Nested VMX ====
* Implement performance features such as EPT and VPID

__NOTOC__

File:Kvm-forum-2011-performance-monitoring.pdf

2011-08-14T02:57:05Z

AviKivity: Performance Monitoring for KVM Guests

Performance Monitoring for KVM Guests

File:Kvm-forum-2011-performance-monitoring.odp

2011-08-14T02:56:14Z

AviKivity: Performance Monitoring for KVM Guests

Performance Monitoring for KVM Guests

FAQ

2011-07-07T14:15:01Z

AviKivity: Removed rant about "Is KVM Stable?". It is stable. If you have issues, report them to the mailing list.

=FAQ=

== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64bits processors supported under KVM? ===
Yes they are supported and will allow you to run 32bits and 64 bits guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

. egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU.<br /> The Xen hypervisor suppresses these flags in order to prevent hijacking.
* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")
* On some Dell hardware, you also need to disable "Trusted Execution", otherwise VT will not be enabled.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

If your name is Andreas Mohr, you're reporting bugs in the wrong place.
----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://qemu-buch.de/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ] (old vanished link: [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ]).

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might no be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://qemu-buch.de/cgi-bin/moin.cgi/QemuNetwork QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

Guest-side network lockups (fortunately restartable) may be happening due to tun/tap bridging erroneous MAC address reconfiguration on host side, see RHEL bug #571991 and others.

----------

=== I'm experiencing timer drift issues in my VM guests, what to do? ===

Especially in case of networked systems (e.g. via NFS or Samba) it is very important to ensure stable operation of timing (both system timer and RTC).
Tell-tale signs of related trouble in VMs (apparently qemu/KVM/VMWare etc. are all affected) are e.g.
"make[2]: Warning: File `XXXXX/cmakelists_rebuilder.stamp' has modification time 0.37 s in the future"
"Clock skew detected. Your build may be incomplete."

[http://maemovmware.garage.maemo.org/2nd_edition/requirements_documentation.html Maemo docs] state that it's important to disable UTC and set the correct time zone, however I don't really see how that would help in case of diverging host/guest clocks.
IMHO much more useful and important is to configure properly working NTP server (chrony recommended, or ntpd) on both host and guest.
The single most decisive trick IMHO is to specify the '''host''' NTP server as the main entry within guest VM instead of "foreign" NTP servers, to make sure to achieve the most precise coupling between these two related systems (timing drift vs. other systems does not matter nearly as much as a tight time precision for inner host/guest system interaction e.g. in the case of NFS/Samba shares etc.).
For verification, see chronyc "sources -v", "tracking" ("System time" row) commands.

After having applied this very tight NTP coupling, this seems to finally have gotten rid of make's time drift warnings.

Perhaps qemu's -tdf (timing drift fix) option magically manages to help in your case, too.

See also [https://espace.cern.ch/it-faqs/Lists/faqs/DispForm.aspx?ID=368 Faqs: I received a message about "clock skew"].

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
Not officially.

Kazushi Takahashi has been working on an experimental version though, called WinKVM, available [http://github.com/ddk50/winkvm here].

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic memory management for guests supported? ===
This is a broad topic covering a few areas.

A. KVM only allocates memory as the guest tries to use it. Once it's allocated, KVM keeps it. Some guests (namely Microsoft guests) zero all memory at boot time. So they will use all memory.

B. Certain guests (only Linux at the moment) have a balloon driver, so the host can have the guest allocate a certain amount of memory which the guest won't be able to use anymore and it can then be freed on the host. Ballooning is controlled in the host via the [http://www.nongnu.org/qemu/qemu-doc.html#SEC12 balloon monitor command].

C. Some hosts (presently only RHEL5.4 / CentOS 5.4) have a feature called KSM (Kernel Sharedpage Merging), which collapses together identical pages; this requires kernel support on the host, as well as a kvm new enough to opt in to the behavior. As some guest platforms (most notably Windows) zero out free'd memory, such pages are trivially collapsed. The ksmctl command needs to be used to enable KSM; alternately, the ksmtuned service found in Fedora 12 can be run to dynamically adjust KSM's aggressiveness based on the amount of free memory available

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS and not having issues with people violating the GPL you might want to use the driver from the VBEMP x86 project (http://www.bearwindows.boot-land.net/vbemp.htm) which is based on ReactOS code.

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

TODO

2011-05-31T08:34:17Z

AviKivity:

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement ACPI memory hotplug
* Improve ballooning to try to use 2MB pages when possible ( in progress - kern.devel@gmail.com )

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Reduce qemu memory footprint when using kvm
** this involves dropping the PhysPageDesc array in favour of a memslot-like approach
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Same for ordinary registers, really, copying all registers all the time is gross.
** Can be done by adding 'available' and 'dirty' bitmasks
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga (partially done)
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* convert more instructions to direct dispatch (function pointer in decode table)
* fold 'struct decode_cache' into 'struct x88_emulate_context'; reducing a lot of pointless temporary variables.
* move init_emulate_ctxt() into x86_decode_insn() and other emulator entry points

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS
* USB 2.0 (EHCI) support

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== Random improvements ====
* Utilize the SVM interrupt queue to avoid extra exits when guest interrupts are disabled

==== For the adventurous: ====
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Add [http://lagarcavilla.org/vmgl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.
* Keep this TODO up to date

==== Nested VMX ====
* Implement performance features such as EPT and VPID

__NOTOC__

Tracing

2011-03-09T15:38:15Z

AviKivity: trace-cmd instructions

Tracing is done by means of kernel tracepoints, the ftrace infrastructure, and trace-cmd.

= Installing trace-cmd =

# Install the udis86 and udis86-devel packages
# download trace-cmd:
<nowiki>
$ git clone trace-cmd git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
$ cd trace-cmd
</nowiki>
# build and install:
<nowiki>
$ make && sudo make install
</nowiki>

= Tracing =

<nowiki>
# trace-cmd record -b 20000 -e kvm
</nowiki>
(trace-cmd will wait)

run your workload, then stop trace-cmd with ctrl-C. trace-cmd will write a trace.dat file.

= Analyzing the trace =

<nowiki>
trace-cmd report
</nowiki>

will format and display the contents of the trace.

Bugs

2011-03-09T15:28:15Z

AviKivity: add trace link

=Bugs=

Kernel side KVM bugs should be file to the [https://bugzilla.kernel.org/ kernel's bug tracker].

Userspace bugs should be filed to [https://bugs.launchpad.net/qemu Qemu's launchpad tracker]. If you think they are qemu-kvm specific (i.e. upstream qemu is not affected), you should mark them clearly as being qemu-kvm specific.

If in doubt, email (kvm@vger.kernel.org) the mailing list first (no need to register) and you will be directed where to file the bug if necessary.

Historical bug reports can be found in the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker].

== Submitting a bug report ==

When submitting a bug report, make sure to provide the following information:

* What cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210). See /proc/cpuinfo if you're not sure.
* What kvm version you are using. If you're using git directly, provide the output of 'git describe'.

* The host kernel version

* What host kernel arch you are using (i386 or x86_64)

* What guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version

* The qemu command line you are using to start the guest

* Whether the problem goes away if using the <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.

* Whether the problem also appears with the <code>-no-kvm</code> switch.

Please use the latest release version of kvm at the time you submit the bug. Even if you use kvm from a distribution (Ubuntu starting from Feisty or Fedora starting from 7), it is important to use the latest sources.

In case qemu-kvm exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with

(gdb) info threads

And for every thread present do:

(gdb) thread n

(gdb) bt

Attach the output to the bug report.

== Getting a serial console from the guest ==

If a guest crashes on boot, it is sometimes useful to have its console output. This can be done using
qemu's -serial option to emulate a serial port:
qemu-system-x86_64 -serial file:serial.log

Depending on the guest OS you will need to do some additional changes to instruct it to use the serial port as a console as shown below :

=== Linux ===

Change the guest kernel's command line (in the GRUB or LILO menu) to include the string
console=ttyS0,115200

If after a crash, there is still no output in the serial.log file and the guest kernel was configured touse a serial console; chances are that the crash was too early in the process to have the console initialized and then the following kernel command line should be used additionally (only to be used as a last resort as it interacts badly with the console boot parameter)
earlyprintk=serial,ttyS0,115200

=== OpenSolaris ===

Change the guest kernel's entry in the GRUB menu to include the string
-B console=ttya

if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot asthere will be no output in the SDL console and you won't be able to interact with it through the keyboard.

= Tracing =

When debugging kvm, it is often convenient to get a [[Tracing|trace]] of what's going on.

TODO

2010-09-05T10:34:49Z

AviKivity: Update

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Reduce qemu memory footprint when using kvm
** this involves dropping the PhysPageDesc array in favour of a memslot-like approach
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.
* Same for ordinary registers, really, copying all registers all the time is gross.
* Implement mmx and sse memory move instructions; useful for guests that use multimedia extensions for accessing vga
* Implement an operation queue for the emulator. The emulator often calls userspace to perform a read or a write, but due to inversion of control it actually restarts instead of continuing. The queue would allow it to replay all previous operations until it reaches the point it last stopped.
** if this is done, we can retire ->read_std() in favour of ->read_emulated().
* push segment base resolution to the last possible moment, i.e. calling ctxt->ops->read_emulated(); then implement limit checks in that place
* convert more instructions to direct dispatch (function pointer in decode table)

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== For the adventurous: ====
* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm ( working on this - kern.devel@gmail.com ).
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2010-06-06T16:01:37Z

AviKivity: O(1) MMU items

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine. (this is probably a bad idea--see qemu-devel/kvm-devel discussion)
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm. (in progress)
* Reduce qemu memory footprint when using kvm
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests
* O(1) write protection by protecting the PML4Es, then on demand PDPTEs, PDEs, and PTEs
* O(1) mmu invalidation using a generation number

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Implement an external module for the iommus, so that KVM VT-d works on old kernels.
* Implement Linux pci-stub module to “hide” pass-through device from host kernel’s device driver.
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== For the adventurous: ====
* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2010-06-06T16:00:03Z

AviKivity: EFER works on i386

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine. (this is probably a bad idea--see qemu-devel/kvm-devel discussion)
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm. (in progress)
* Reduce qemu memory footprint when using kvm
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Implement an external module for the iommus, so that KVM VT-d works on old kernels.
* Implement Linux pci-stub module to “hide” pass-through device from host kernel’s device driver.
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== For the adventurous: ====
* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2010-06-06T15:59:39Z

AviKivity: Drop outdated items

=ToDo=

The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Bring up Windows 95 and Windows 98 guests
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine. (this is probably a bad idea--see qemu-devel/kvm-devel discussion)
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm. (in progress)
* Reduce qemu memory footprint when using kvm
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

==== MMU related: ====
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests

==== x86 emulator updates: ====
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

==== Interactivity improvements: ====
* If for several frames in a row a large proportion of the framebuffer pages are changing, then for the next few frames don't bother to get the dirty page log from kvm, but instead assume that all pages are dirty. This will reduce page fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when activity dies down, scale it back down (applicable to qemu as well).

==== Pass-through/VT-d related: ====
* Implement an external module for the iommus, so that KVM VT-d works on old kernels.
* Implement Linux pci-stub module to “hide” pass-through device from host kernel’s device driver.
* Enhance KVM QEMU to return error messages if user attempts to pass-through unsupported devices:
** Devices with shared host IOAPIC interrupt
** Conventional PCI devices
** Devices without FLR capability
* QEMU PCI pass-through patch needs to be enhanced to same functionality as corresponding file in Xen
** Remove direct HW access by QEMU for probing PCI BAR size
** PCI handling of various PCI configuration registers
** Other enhancements that was done in Xen
* Host shared interrupt support
* VT-d2 support (WIP in Linux Kernel)
** Queued invalidation
** Interrupt remapping
** ATS

==== Bug fixes: ====
* Less sexy but ever important, fixing bugs is one of the most important contributions

==== For the adventurous: ====
* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

Getting the kvm kernel modules

2009-10-26T08:56:42Z

AviKivity: Add summary table

There are a variety of sources of kvm kernel modules. Which ones to use depend on whether you are interested in using, testing, or developing kvm.

As of now, all major community and enterprise distributions contain kvm kernel modules and userspace; these are either installed by default or require installing a kvm package. For someone looking for stability, these are the best choice. No effort is needed to build or install the modules, support is provided by the distribution, and the distribution/module combination is well tested.

For those stuck on an older kernel, but wishing to run a modern, stable kvm release the kvm maintainers provide an external module kit that can run a modern kvm on an older kernel. These packages are named kvm-kmod-2.6.x.y (or kvm-kmod-2.6.x), and correspond to the kvm code contained in Linux 2.6.x.y. They can generally be run on any Linux kernel older than 2.6.x.

If you wish to help testing the kvm component of the next Linux release, but without running a -rc kernel from kernel.org, you may use kvm-kmod-2.6.x-rcy, containing the code from Linux 2.6.x-rcy backported to run on older kernels. Feedback from running this release will help improve the kvm in the next kernel release.

For testing development snapshots, the kvm-kmod-devel-xx releases are provided. These don't correspond exactly to any Linux release, but instead contain code from the kvm.git (the kvm development repository) at the point of their release. These are generally the most up-to-date modules.

In summary:

{|
! Release type
! Suitable for
|-
| Distribution provided
| Mainstream use; supported by distribution
|-
| kvm-kmod-2.6.x.y
| Running modern, stable kvm releases on older kernels
|-
| kvm-kmod-2.6.x-rcy
| Testing the next kvm-kmod-2.6.x.y release
|-
| kvm-kmod-devel-xx
| Testing bleeding-edge development code
|}

Getting the kvm kernel modules

2009-10-26T08:50:32Z

AviKivity:

FAQ

2009-10-26T08:39:31Z

AviKivity: Add link to "Getting the kvm kernel modules" page

=FAQ=

== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64bits processors supported under KVM? ===
Yes they are supported and will allow you to run 32bits and 64 bits guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== Where do I get my kvm kernel modules from? ===

See the [[Getting the kvm kernel modules]] page.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

. egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ].

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might no be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This happens because of a VNC protocol flaw on the way on-the-fly pixel format changes are handled (more info at [http://www.mail-archive.com/qemu-devel@nongnu.org/msg04879.html this thread]). If you are using TigerVNC, you can avoid this problem by disabling on-the-fly selection of pixel encoding, using the <tt>-AutoSelect=0</tt> command-line option of vncviewer. You may also want to check the encoding options on the vncviewer man page, as this will disable automatic selection of encoding based on connection speed.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://kidsquid.com/cgi-bin/moin.cgi/QemuNetwork QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
No.

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic use of RAM for guest operating system supported? ===
Yes. If you set -m 6144, guest can get a maximum of 6GB of RAM, but doesn't necessarily uses all. Please note however that the usual platform limits will apply so you won't be able to see more than 4GB of RAM on a 32 bits guest unless you use PAE.

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS you might want to use the driver from the VBEMP x86 project (http://www.geocities.com/bearwindows/vbemp.htm).

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

Tuning KVM

2009-09-29T17:23:25Z

AviKivity: cpu, networking, storage tuning tips

== CPU Performance ==

Modern processors come with a wide variety of performance enhancing features such as streaming instructions sets (sse) and other performance-enhancing instructions. These features vary from processor to processor.

QEMU and KVM default to a compatible subset of cpu features, so that if you change your host processor, or perform a live migration, the guest will see its cpu features unchanged. This is great for compatibility but comes at a performance cost.

To pass all available host processor features to the guest, use the command line switch

qemu '''-cpu host'''

if you wish to retain compatibility, you can expose selected features to your guest. If all your hosts have these features, compatibility is retained:

qemu '''-cpu qemu64,+ssse3,+sse4.1,+sse4.2,+x2apic'''

== Networking ==

QEMU defaults to user-mode networking (slirp), which is available without prior setup and without administrative privileges on the host. It is also unfortunately very slow. To get high performance networking, switch to a bridged setup via the -net tap command line switches.

qemu -net nic,model=virtio,mac=... '''-net tap,ifname=...'''

QEMU also defaults to the RTL8139 network interface card (NIC) model. Again this card is compatible with most guests, but does not offer the best performance. If your guest supports it, switch to the virtio model:

qemu -net nic,'''model=virtio''',mac=... -net tap,ifname=...

== Storage ==

QEMU supports a wide variety for storage formats and back-ends. Easiest to use are the raw and qcow2 formats, but for the best performance it is best to use a raw partition. You can create either a logical volume or a partition and assign it to the guest:

qemu -drive '''file=/dev/mapper/ImagesVolumeGroup-Guest1''',cache=none,if=virtio

QEMU also supports a wide variety of caching modes. Writeback is useful for testing but does not offer storage guarantees. Writethrough (the default) is safer, and relies on the host cache. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic:

qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,'''cache=none''',if=virtio

As with networking, QEMU supports several storage interfaces. The default, IDE, is highly supported by guests but may be slow, especially with disk arrays. If your guest supports it, use the virtio interface:

qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,'''if=virtio'''

FAQ

2009-09-29T17:01:24Z

AviKivity: Added tuning link

=FAQ=

== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64bits processors supported under KVM? ===
Yes they are supported and will allow you to run 32bits and 64 bits guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

. egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== How can I get the most performance out of KVM? ===

See the [[Tuning KVM]] page.

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ].

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might no be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This might happen, when a VNC Client (for example RealVNC / xvnc4viewer) chooses ZRLE Encoding. Simple choose Hextile Encoding in the options of your VNC Client, and the Problem should be resolved.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://kidsquid.com/cgi-bin/moin.cgi/QemuNetwork QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
No.

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic use of RAM for guest operating system supported? ===
Yes. If you set -m 6144, guest can get a maximum of 6GB of RAM, but doesn't necessarily uses all. Please note however that the usual platform limits will apply so you won't be able to see more than 4GB of RAM on a 32 bits guest unless you use PAE.

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS you might want to use the driver from the VBEMP x86 project (http://www.geocities.com/bearwindows/vbemp.htm).

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

FAQ

2009-09-06T09:04:41Z

AviKivity: General update

=FAQ=

== Preparing to use KVM ==
=== What do I need to use KVM? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors. For Intel processors, see also [http://ark.intel.com/VTList.aspx the Intel® Virtualization Technology List].

----------
=== Are 64bits processors supported under KVM? ===
Yes they are supported and will allow you to run 32bits and 64 bits guests.

See also '''Can KVM run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

. egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Note:

* On some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualization in the BIOS.
* Enabling some BIOS features may break VT support on some hardware (e-g Enabling Intel AMT on a Thinkpad T500 will prevent kvm-intel from loading with "disabled by bios")

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does KVM use? ===
KVM uses a slightly modified [http://www.nongnu.org/qemu QEMU] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can KVM use? ===
KVM inherits a wealth of disk formats support from QEMU; it supports raw images, the native QEMU format (qcow2), VMware format, and many more.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using KVM ==
=== How can I use KVM with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== Is KVM stable? ===
KVM is stable and used in production. As with most open source projects, development snapshots are less stable than the stable release series.

----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the KVM modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the QEMU documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://www.nongnu.org/qemu/user-doc.html documentation]. There is also an extensive [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ].

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to QEMU with no hardware acceleration? ===

If you think that you might no be using the hardware acceleration provided by the KVM module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the QEMU monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the KVM module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This might happen, when a VNC Client (for example RealVNC / xvnc4viewer) chooses ZRLE Encoding. Simple choose Hextile Encoding in the options of your VNC Client, and the Problem should be resolved.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
KVM uses QEMU for its device emulation. Consult the [http://kidsquid.com/cgi-bin/moin.cgi/QemuNetwork QEMU network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/KVM screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General KVM information ==
=== What is the difference between KVM and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, KVM is part of Linux and uses the regular Linux scheduler and memory management. This means that KVM is much smaller and simpler to use; it is also more featureful; for example KVM can swap guests to disk in order to free RAM.

KVM only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualization. KVM does not support paravirtualization for CPU but may support paravirtualization for device drivers to improve I/O performance.

----------

=== What is the difference between KVM and VMware? ===
VMware is a proprietary product. KVM is Free Software released under the GPL.

----------

=== What is the difference between KVM and QEMU? ===
QEMU uses emulation; KVM uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of KVM for Windows? ===
No.

----------

=== What kernel version does it work with? ===
It depends on what version of KVM you are using. The last release of KVM should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic use of RAM for guest operating system supported? ===
Yes. If you set -m 6144, guest can get a maximum of 6GB of RAM, but doesn't necessarily uses all. Please note however that the usual platform limits will apply so you won't be able to see more than 4GB of RAM on a 32 bits guest unless you use PAE.

----------

=== What OSs can I run inside KVM VM? ===
Several. See the [[Guest Support Status]] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splash screens in grub.

----------

=== Does KVM support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does KVM support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.
If one of your hosts does not support NX, you may consider disabling NX when starting the guest on a NX-capable system. You can do it by passing "-cpu qemu64,-nx" parameter to the guest.

----------

=== Can KVM run a 32-bit guest on a 64-bit host? What about PAE? ===
KVM supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with QEMU, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in KVM? ===
Use the -vga std parameter while starting the VM to allow high resolution and widescreen displays.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the KVM mailing list if you are not able to patch the source yourself.

When using Windows as guest OS you might want to use the driver from the VBEMP x86 project (http://www.geocities.com/bearwindows/vbemp.htm).

----------

=== Does KVM support SMP hosts? ===
Yes.

----------

=== Does KVM support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'KVM' trademarked? ===
No.

----------

Code

2009-06-28T13:59:11Z

AviKivity: Use new location for kvm.git

=Code=

[[Category:Architechture]]

== kernel git tree ==

The kvm kernel code is available through a git tree (like the kernel itself). To create a repository using git, type

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

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/kvm.git;a=summary]

For subsequent upgrades use the command

git pull

in the git working directory.

== userspace git tree ==

The kvm userspace code (libkvm and qemu) is available through a git tree. To create a repository using git, type

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

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary]

== building an external module with older kernels ==

'''This only works for the x86 architecture.'''

1. If you wish to use a distribution kernel (or just some random kernel you like) with kvm,
you can use the external module kit. You will need the kvm-kmod repository:

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
cd kvm-kmod
git submodule update --init
./configure [--kerneldir=/path/to/kernel/dir]
make sync
make

=== Tip about building against Red Hat Enterprise Linux kernels ===

<code>kvm-userspace/kernel</code> has some compat code to allow it to compile against older kernels, and also some code specific to features that are normally not present on older kernels but are present on RHEL kernels.

So, when building against a RHEL kernel tree, check if the <code>RHEL_*</code> macros at <code>${kerneldir}/include/linux/version.h</code> are defined correctly, corresponding to the RHEL version where the kernel source comes from. If those macros aren't defined correctly, the compat code that allows compilation against RHEL kernels will break and you will get build errors.

== release tags ==

kvm stable releases (based off of Qemu's stable branch) are tagged with <code>kvm-qemu-0.NN.N</code> where ''N'' equates to the upstream Qemu branch versions. Note that kvm has them tagged not branched.

kvm development releases are tagged with <code>kvm-nn</code> where ''nn'' is the release number.

== Binary Packages ==

=== CentOS / RHEL ===

Unofficial packages of latest releases can be found at:
<code>http://www.lfarkas.org/linux/packages/centos/5/</code>

=== Debian Lenny ===

There are some updated packages for debian lenny available at:
<code>http://www.corpit.ru/debian/tls/kvm/</code>

== nightly snapshots ==

Nightly snapshots, for those who are uncomfortable with git, are [http://people.qumranet.com/avi/snapshots available]. When reporting a problem with a snapshot, please quote the snapshot name (which includes the date) and the contents of the SOURCES file in the snapshot tarball.

Code

2009-05-20T09:26:04Z

AviKivity: Update kvm-kmod instructions

=Code=

[[Category:Architechture]]
== kernel git tree ==
The kvm kernel code is available through a git tree. To create a repository using git, type

git clone git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=linux/kernel/git/avi/kvm.git;a=summary]

For subsequent upgrades use the command

git-pull
in the git working dir.

== userspace git tree ==
The kvm userspace code (libkvm and qemu) is available through a git tree. To create a repository using git, type

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

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary]

== building an external module with older kernels ==

'''This only works for the x86 architecture.'''

1. If you wish to use a distribution kernel (or just some random kernel you like) with kvm,
you can use the external module kit. You will need the kvm-kmod repository:

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
cd kvm-kmod
git submodule update --init
./configure [--kerneldir=/path/to/kernel/dir]
make sync
make

=== Tip about building against Red Hat Enterprise Linux kernels ===

<code>kvm-userspace/kernel</code> has some compat code to allow it to compile against older kernels, and also some code specific to features that are normally not present on older kernels but are present on RHEL kernels.

So, when building against a RHEL kernel tree, check if the <code>RHEL_*</code> macros at <code>${kerneldir}/include/linux/version.h</code> are defined correctly, corresponding to the RHEL version where the kernel source comes from. If those macros aren't defined correctly, the compat code that allows compilation against RHEL kernels will break and you will get build errors.

== release tags ==

kvm releases are tagged with <code>kvm-nn</code> where ''nn'' is the release number.

== Binary Packages ==
=== CentOS / RHEL ===

Unofficial packages of latest releases can be found at
http://www.lfarkas.org/linux/packages/centos/5/

== nightly snapshots ==

Nightly snapshots, for those who are uncomfortable with git, are [http://people.qumranet.com/avi/snapshots available]. When reporting a problem with a snapshot, please quote the snapshot name (which includes the date) and the contents of the SOURCES file in the snapshot tarball.

Code

2009-05-20T09:19:59Z

AviKivity: Drop the Linux driver kit -- obsolete

=Code=

[[Category:Architechture]]
== kernel git tree ==
The kvm kernel code is available through a git tree. To create a repository using git, type

git clone git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=linux/kernel/git/avi/kvm.git;a=summary]

For subsequent upgrades use the command

git-pull
in the git working dir.

== userspace git tree ==
The kvm userspace code (libkvm and qemu) is available through a git tree. To create a repository using git, type

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

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary]

== building an external module with older kernels ==

'''This only works for the x86 architecture.'''

1. If you wish to use a distribution kernel (or just some random kernel you like) with kvm,
you can get both the userspace and kernel (via git). In the userspace
toplevel directory, type:

./configure [--kerneldir=/path/to/kernel/dir]

2. If you are using a released kvm-XX.tar.gz, skip to step 3. If you got the source from git, you need to run the following commands:

cd kernel
make sync LINUX=/path/to/kvm/git/tree
cd ..

3. Finally, build KVM and the KVM modules:

make

There are three important directories in this scenario:
{|border=1
! kvm-userspace
| Contains a <code>kernel</code> subdirectory. If you got the source from git, it needs to be populated with files from the kvm.git repository (using <code>make sync</code>).
|-
! host kernel tree
| Older kernel you want to use newer KVM modules with. Refer to it with <code>configure --kerneldir</code>.
You need to point to a '''configured''' kernel source tree corresponding to the kernel you are building modules for. The default is to look for the sources of the running kernel at <code>/lib/modules/`uname -r`/build</code>.
|-
! kvm kernel tree (from git)
| A clone of the kvm.git repository. Used as the source of the KVM modules. Refer to it with <code>LINUX=path</code> in <code>make sync</code>.
|}

=== Tip about building against Red Hat Enterprise Linux kernels ===

<code>kvm-userspace/kernel</code> has some compat code to allow it to compile against older kernels, and also some code specific to features that are normally not present on older kernels but are present on RHEL kernels.

So, when building against a RHEL kernel tree, check if the <code>RHEL_*</code> macros at <code>${kerneldir}/include/linux/version.h</code> are defined correctly, corresponding to the RHEL version where the kernel source comes from. If those macros aren't defined correctly, the compat code that allows compilation against RHEL kernels will break and you will get build errors.

== release tags ==

kvm releases are tagged with <code>kvm-nn</code> where ''nn'' is the release number.

== Binary Packages ==
=== CentOS / RHEL ===

Unofficial packages of latest releases can be found at
http://www.lfarkas.org/linux/packages/centos/5/

== nightly snapshots ==

Nightly snapshots, for those who are uncomfortable with git, are [http://people.qumranet.com/avi/snapshots available]. When reporting a problem with a snapshot, please quote the snapshot name (which includes the date) and the contents of the SOURCES file in the snapshot tarball.

FAQ

2009-02-05T12:27:24Z

AviKivity: update guest smp support

__TOC__
== Preparing to use kvm ==
=== What do I need to use kvm? ===
You will need an x86 machine running a recent Linux kernel on an Intel processor with VT (virtualization technology) extensions, or an AMD processor with SVM extensions (also called AMD-V). Xen has a [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors complete list] of compatible processors.

----------
=== Are 64bits processors supported under kvm? ===
Yes they are supported and will allow you to run 32bits and 64 bits clients.

See also '''Can kvm run a 32-bit guest on a 64-bit host? What about PAE?''' below.

----------

=== What is Intel VT / AMD-V / hvm? ===
[http://www.intel.com/technology/itj/2006/v10i3/1-hardware/6-vt-x-vt-i-solutions.htm Intel VT] and [http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_14287,00.html AMD's AMD-V] are instruction set extensions that provide hardware assistance to virtual machine monitors. They enable running fully isolated virtual machines at native hardware speeds, for some workloads.

HVM (for Hardware Virtual Machine) is a vendor-neutral term often used to designate the x86 instruction set extensions.

----------

=== How can I tell if I have Intel VT or AMD-V? ===
With a recent enough Linux kernel, run the command:

. egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.
* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.
In case of doubt, contact your hardware vendor.

----------

=== "KVM: disabled by BIOS" error ===
Check if there is an option to enable it in the BIOS. If not, look for a more recent BIOS on the vendor's web site.

Also, on some hardware (e-g HP nx6320), you need to power-off/power-on the machine after enabling virtualisation in the BIOS.

----------

=== How can I use AMD-V extension? ===
modprobe kvm-amd

----------

=== What user space tools does kvm use? ===
kvm uses a slightly modified [http://www.qemu.com/ qemu] program to instantiate the virtual machine. Once running, a virtual machine is just a regular process. You can use `top(1), kill(1), taskset(1)` and similar tools to manage virtual machines.

----------

=== What virtual disk formats can kvm use? ===
kvm inherits a wealth of disk formats support from qemu; it supports raw images, the native qemu format (qcow), VMware format, and many more.

----------

=== Are there management tools available to help me manage my virtual machines? ===
Yes. Please see the [[Management Tools]] page for some links.

----------

== Using kvm ==
=== How can I use kvm with a non-privileged user? ===
The cleanest way is probably to create a group, say ''kvm'', and add the user(s) to that group. Then you will need change /dev/kvm to owned by group ''kvm''.

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to ''/etc/udev/rules.d/40-permissions.rules'').

KERNEL=="kvm", GROUP="kvm"

----------

=== Is KVM stable? ===
The good news is that more and more developers and testers use KVM each passing day and for the most part, it works. KVM is a very young project and constantly evolving to add new features and more hardware support. Given the fervent pace of development, it's very likely that we're introducing new bugs at a fast pace as well, however small they might be. We would encourage our users to report any bug(s) they encounter so that we can continue making KVM better and stabler with each commit.

----------

=== That's alright, but can I really use it for my daily use? ===
Sure. We continuously run the most often-used OSes and configurations and if anything breaks for the developers, it's fixed as soon as it was broken. See the [[Guest Support Status]] and [[Host Support Status]] pages to find out more. Please update them with success stories so that new users would benefit from the experience of the community.

----------

=== How about production use? ===
For production use, it's recommended you use the kvm modules shipped by the distribution you're using to ensure stability. As mentioned above, it's tempting to use new features, but you never know of (unwanted) surprises hidden away. It'll be best if you can run the development snapshots with non-critical production load, so that the latest releases are stable for you when you decide to deploy them.

----------

=== What happens if I kill -9 a VM process? ===
From the guest's perspective, it is as if you yanked the power cord out. From the host's perspective, the process is killed and all resources it uses are reclaimed.

----------

=== I need help to setup the network for my guest ===
You can have a look to the [[Networking]] page of this wiki for informations on the most classical networking setup for the guests. You can also refer to the Qemu documentation.

----------

=== Where can I find more documention... ===
Most usability issues are covered in the QEMU [http://bellard.org/qemu/user-doc.html documentation]. There is also an extensive [http://kidsquid.com/cgi-bin/moin.cgi/FrequentlyAskedQuestions FAQ].

----------

== Troubleshooting ==
=== How can I check that I'm not falling back to qemu with no hardware acceleration? ===

If you think that you might no be using the hardware acceleration provided by the kvm module, here are a few steps to help you check this.

First of all, check that you don't have messages such as:

qemu-system-x86_64 -hda myvm.qcow2
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

In that case, you can check that:
* the modules are correctly loaded <code>lsmod|grep kvm
* you don't have a "KVM: disabled by BIOS" line in the output of dmesg
* /dev/kvm exists and you have the correct rights to use it

Other ways to do the diagnostic:
* if you have access to the qemu monitor (Ctrl-Alt-2, use Ctrl-Alt-1 to get back to the VM display), enter the "info kvm" command and it should respond with "KVM support: enabled"
* the right-end columns of the output from <code>lsmod|grep kvm</code> on the host system, once the VM is started should show only non zero values. The value on the line corresponding to the architecture specific module (e-g kvm_intel, kvm_amd) show the number of VM using the module. For instance, if I have 2 VM running using the kvm module on a machine with vt, it will report:

lsmod|grep kvm
kvm_intel 44896 2
kvm 159656 1 kvm_intel

=== "rect too big" Message when using VNC Display ===
When connection to a VNC Terminal, a "rect too big" message appears, and the VNC Session disconnects.

This might happen, when a VNC Client (for example RealVNC / xvnc4viewer) chooses ZRLE Encoding. Simple choose Hextile Encoding in the options of your VNC Client, and the Problem should be resolved.

----------
'''How do I set up the network such that my guest is accessible from other machines?''' or

=== My guest network is stuck what should I do? ===
kvm uses qemu for its device emulation. Consult the [http://kidsquid.com/cgi-bin/moin.cgi/QemuNetwork qemu network wiki page] for detailed network setup instructions.

One would probably be interested in the Root Networking Mode page and the Network Bridge page.

----------

=== Windows boots and runs very slowly? ===
See the [[Windows ACPI Workaround]] page.

----------

=== I get an "Exception 13" or "Exception 12" message while booting a guest OS on my Intel host ===
See the [[Intel Real Mode Emulation Problems]] page.

----------
=== I get "rtc interrupts lost" messages, and the guest is very slow? ===
Try setting <code>CONFIG_HPET_EMULATE_RTC=y</code> in your host <code>.config</code>.

----------

=== I have VMware/Parallels/VirtualBox installed and when I modprobe KVM, my system deadlocks. ===
Neither Intel VT nor AMD-V provide a mechanism to determine whether software is currently using the hardware virtualization extensions. This means that if you have two kernel modules loaded attempting to use hardware virtualization extensions, very bad things will happen. If you are using another type of virtualization software and experience any sort of weirdness with KVM, make sure you can reproduce the problem without the kernel modules for that software loaded before you report a bug in KVM.

----------

=== There's nothing on QEMU/kvm screen, but it's not hanged! I'm trying to install Kubuntu. ===
Try to run kvm with -std-vga option. It helps if guest operating system uses framebuffer mode like Kubuntu/Ubuntu.

----------

=== When I click the guest operating system window, mouse is grabbed. How can I get mouse to not to do that? OR Mouse doesn't show up / doesn't work in the guest. What do I do? ===
From #qemu wiki, try to run kvm/qemu with

-usb -usbdevice tablet
If that doesn't work, try this:

$ export SDL_VIDEO_X11_DGAMOUSE=0
(from http://wiki.clug.org.za/wiki/QEMU_mouse_not_working )

----------

== General kvm information ==
=== What is the difference between kvm and Xen? ===
Xen is an external hypervisor; it assumes control of the machine and divides resources among guests. On the other hand, kvm is part of Linux and uses the regular Linux scheduler and memory management. This means that kvm is much smaller and simpler to use.

kvm only run on processors that supports x86 hvm (vt/svm instructions set) whereas Xen also allows running modified operating systems on non-hvm x86 processors using a technique called paravirtualisation. kvm does not support paravirtualization for cpu but may support paravirtualization for device drivers to improve I/O performances.

----------

=== What is the difference between kvm and VMWare? ===
VMware is a proprietary product. kvm is Free Software released under the GPL.

----------

=== What is the difference between kvm and QEMU? ===
Qemu uses emulation; kvm uses processor extensions (HVM) for virtualization.

----------

=== Do you have a port of kvm for Windows? ===
Not in this release.

----------

=== What kernel version does it work with? ===
It depends on what version of kvm you are using. The last release of kvm should work with any recent kernel (2.6.17 and above), older releases even older kernels.

----------

=== How much RAM do I need? ===
You will need enough memory to let the guest run comfortably while keeping enough for the host. 1GB is probably a minimum configuration for the host OS.

----------

=== Is dynamic use of RAM for guest operating system supported? ===
Yes. If you set -m 6144, guest can get a maximum of 6GB of RAM, but doesn't necessarily uses all. PLease note however that the usual platform limits will apply so you won't be able to see more than 4GB of RAM on a 32 bits guest unless you use PAE.

----------

=== What OSs can I run inside kvm VM? ===
Several. See the [:Guest Support Status:Guest_Support_Status] page for details. Note that several Linux flavors are known to hang on Intel processors during startup. Workaround is to disable splashscreens in grub.

----------

=== Does kvm support a live migration feature to move virtual machines from one host to another without downtime? ===
Yes. See the [[Migration]] page for details.

----------

=== Does kvm support live migration from an AMD host to an Intel host and back? ===
Yes. There may be issues on 32-bit Intel hosts which don't support NX (or XD), but for 64-bit hosts back and forth migration should work well. Migration of 32-bit guests should work between 32-bit hosts and 64-bit hosts.

----------

=== Can kvm run a 32-bit guest on a 64-bit host? What about PAE? ===
kvm supports 32-bit guests on 64-bit hosts, and any combination of PAE and non-PAE guests and hosts. The only unsupported combination is a 64-bit guest on a 32-bit host.

If you are running a Windows Virtual Machine and have problems enabling PAE in your guest see the [[Windows PAE Workaround]] page.

----------

=== Is it possible to use USB devices with a guest OS? ===
Yes, look up how to do it with qemu, it's the same way.

----------

=== Can I have higher or widescreen resolutions (eg 1680 x 1050) in kvm? ===
Support for higher resolutions was added in kvm-59, but some bugs were left until the release of kvm-62. Use the -std-vga parameter while starting the VM.

If the resolution you want to use is not available, you can patch the corresponding source files (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557 as a reference), or send a mail to the kvm mailing list if you are not able to patch the source yourself.

When using Windows as guest OS you might want to use the driver from the VBEMP x86 project (http://www.geocities.com/bearwindows/vbemp.htm).

----------

=== Does kvm support SMP hosts? ===
Yes.

----------

=== Does kvm support SMP guests? ===
Yes. Up to 16 CPUs can be specified using the -smp option.

----------

=== Is the name 'kvm' trademarked? ===
No.

----------

=== What is Qumranet's product? ===
Qumranet is a startup company financed by [http://www.sequoiacap.com/ Sequoia Capital] and [http://www.nvp.com/ Norwest Venture Partners (NVP)].

On the 24th of September 2007, Qumranet announced their first product, Solid ICE, a virtual Desktop Infrastructure solution based on KVM (http://web1.qumranet.com/art_images/files/10/Qumranet_Launch_Release.pdf)

----------

Ia64 list

2008-01-27T17:27:54Z

AviKivity:

The kvm ia64 port development list can be found in

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

----
[[Category ia64]]

__NOTOC__

Ia64 list

2008-01-27T17:27:54Z

AviKivity:

The kvm ia64 port development list can be found in

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

----
[[Category ia64]]

__NOTOC__

TODO

2008-01-24T14:26:16Z

AviKivity: mprotect() for read-only memory

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it
* Add HPET support to qemu and kvm

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
** possible using mprotect()?
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy but ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2008-01-24T14:23:28Z

AviKivity: mmio scaling

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it
* Add HPET support to qemu and kvm

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm
* Avoid taking kvm->lock when issuing mmio. Need to check lapic and ioapic accesses for correctness.

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy but ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

ChangeLog

2008-01-23T14:19:13Z

AviKivity: 03 jan -> 3 jan

= kvm-60 [23 jan 2008] =

* fix compilation with older kernels (Andi Kleen)
* virtio host support (Anthony Liguori, Dor Laor)
** includes block and network devices
* fix power management timer overflow handling
* fix qemu running with older kernels
* boot from scsi/virtio (Anthony Liguori)
* add 1280x800 resolution to -std-vga
* fix acpi sci interrupt generation
* compile fixes (Carlo Marcelo Arenas Belon)
* update ide cdrom to match qemu (Carlo Marcelo Arenas Belon)
* fix extboot on older gcc (Christian Ehrhardt)
* powerpc dcr tests (Christian Ehrhardt)
* rtl8139 is now the default nic type (Guido Guenther)
* acpi power button support (Guido Guenther)
* powerpc testsuite harness (Hollis Blanchard)
* powerpc libkvm support (Jerone Young)
* bump piix4 to rev 3 to avoid slowdown reading pm timer (Marcelo Tosatti)
* migration updates (Uri Lublin)
* ia64 smp support in qemu (Xiantao Zhang)
* fix acpi vapic page on save/restore
* move x86 fpu to x86 specific header (Christian Ehrhardt)
* minor shadow code simplification(Eddie Dong)
* optimize pae pte updates (Eddie Dong, Eric Liu)
* simplify shadow hash table indexing (Eddie Dong)
* kvm_para.h compile fix (Glauber de Oliveira Costa)
* dirty page tracking fix (Izik Eidus)
* fix svm lazy fpu switching (Joerg Roedel)
** fixes Vista x64 on AMD
* only allow vmcall/vmmcall on #UD traps (Sheng Yang)

= kvm-59 [3 jan 2008] =

* merge qemu-cvs
** -drive cache=[on|off] option
** adds scsi passthrough
* ide lba48 support for 120GB+ disk images
* widescreen resolutions for -std-vga
* libkvm compile fixes (Carlo Marcelo Arenas Belon)
* mmu scaling (Marcelo Tosatti, Avi Kivity)

= kvm-58 [27 dec 2007] =

* add mmu statistics
* log data on write to unimplemented msr
* fix memory corruption (mapcount error) after host fork() (Izik Eidus)
* improve preempt notifier emulation on older kernels (Andrea Arcangeli)
* refactor IDE CHS guessing (Anthony Liguori)
* testsuite improvements
* apic tpr acceleration for Windows guests
** disabled on smp for now
* fix warnings due to qemu merge (Carlo Marcelo Arenas Belon)
* improve support for older kernels (Carlo Marcelo Arenas Belon)
* icache sync in qemu after dma for more archs (Christian Ehrhardt)
* simplify mmio callback (Christian Ehrhardt)
* align gdbstub with qemu-cvs (Jan Kiszka)
* fix compile if kernel/include/asm/ preexists (Sheng Yang)
* fix migration on i386 hosts (Uri Lublin)
* qemu ia64 adjustments (Zhang Xiantao)

= kvm-57 [18 dec 2007] =

* warn when emulating preempt notifiers
* add pio port 0x80 access test to testsuite
* merge qemu-cvs
* add rtc emulation for ia64 (Xiantao Zhang)
* fix qemu memory allocation off-by-one
* new kernel source layout (virt/kvm/, arch/x86/kvm/)
* coalesce remote tlb flushes when write-protecting guest pages (Eddie Dong)
* lapic debug compile fix (Joerg Roedel)
* fix smp mmu shadow instantiation race (Marcelo Tosatti)
* atomic cmpxchg8b on i386 (Marcelo Tosatti)
* throttle vmx_intr_assist() printk (Ryan Harper)
* portability (Xiantao Zhang)

= kvm-56 [14 dec 2007] =

* Generalize exception handling mechanism
* fix x86 emulator eflags handling
* avoid exit to userspace on cr8 write if using kernel lapic on Intel
* fix stack instructions emulation in 64-bit mode
** fixes Vista x86
*** except on Woodcrests
* trap cr8 access on amd
* mmu simplification
* fix setting nx bit on shadow pte
* fix inherited mmu permissions
* more portability work (Hollis Blanchard, Xiantao Zhang)
* add cr8 to 'mov cr' instruction emulation (Joerg Roedel)
* exit to userspace on cr8 write if not kernel apic on amd (Joerg Roedel)
* atomically set accessed and dirty bit on guest ptes (Marcelo Tosatti)
* use ->fault() vma op instead of ->nopage()
* remove abi 10 libkvm compatibility
* add some x86 emulator tests
* add many mmu access tests
* fix rpm build on Fedora 8 (Dan Kenigsberg)
* fix 'make sync' on debian and derivatives (Ryan Harper)
* fix live migration (Uri Lublin, Izik Eidus)
* initial ia64 userspace (Xiantao Zhang)

= kvm-55 [4 dec 2007] =

* remove old hypercall driver (Anthony Liguori)
* disable dirty page logging for main memory (Izik Eidus)
* fix incorrect page count calculation for dirty logging (Izik Eidus)
* improve testsuite 'make clean' (Neo Jia)
* compile fix (Sheng Yang)
* reorganize x86 emulator main switch
* don't bypass mmu on pae cr3 reload if pdptrs changed
** fixes Solaris x86
* use common defines for EFER (Carlo Marcelo Arenas Belon)
* portability (Xiantao Zhang)
* fix kvm_init() error path (Xiantao Zhang)
* ia64 iosapic support (Xiantao Zhang)

= kvm-54 [27 nov 2007] =

* fix fpu leak on AMD (Amit Shah)
** (on kvm-53, lazy fpu was disabled, so this just improves performance)
* prefetch instruction bytes when emulating
* implement guest page fault bypass on nonpae
** should speed up some 32-bit guests
* add a bunch of statistics
* avoid unnecessary remote tlb flushes
** improves guest smp scaling
* avoid mmu reloads on guest tlb flushes
* mmu code simplification
* disallow using kvm after fork()
* fix failures while injecting external interrupts in real mode
** fixes Mandrake 9 regression
* fix multiple address- and operand- size override prefix emulation
* infrastructure for using host cpu features on guest (Dan Kenigsberg)
** not used yet by qemu
* cmps instruction emulation (Guillaume Thouvenin)
** allows OpenBSD to boot
* cleanups (Hollis Blanchard)
* fix potential memory leak in real-mode smp (Izik Eidus)
* reduce unnecessary dirtying of pages (Izik Eidus)
* mark guest pages as accessed with the Linux lru (Izik Eidus)
* more portability work (Jerone Young, Xiantao Zhang)
* allow new vmx features even if not using in-kernel apic (Sheng Yang)
* refactor shadow mmu size calculation (Xiantao Zhang)
* improve testsuite
* beginning of x86 emulator unit test
* fix compile warnings (Carlo Marcelo Arenas Belon)
* log module version in dmesg on load

= kvm-53 [20 nov 2007] =

* testsuite: exit on end of test
* batch mode for kvm_stat script
* compile fixes (Carlo Marcelo Arenas Belon, Joe Perches)
* portability (Jerone Young, Zhang Xiantao)
* disable lazy fpu on AMD (Amit Shah)
** should fix instability on AMD
** will cause performance regression, fix in progress
* x86 emulator: fix 'push r/m' emulation (Amit Shah)
* register use reduction in vmx guest entry
* infrastructure for per-vm stats
** extends existing per-vcpu stats
* add mmu, state switch, emulation statistics
* use copy_{to,from}_user to access guest memory (Izik Eidus)
* simplify access to guest page tables (Izik Eidus)
* fix entry to real mode with segment bases beyond 1MB (Jan Kiszka)
* finally kill last use of cr2 in emulator (Sheng Yang)

= kvm-52 [12 nov 2007] =

* fix efer reload host crash on T2600 and similar processors
* revert sleepy interrupt injection
** fixes "Fault when IDT_Vectoring"
* atomically inject real-mode interrupts
* wbinvd exiting on newer Intel processors (Eddie Dong)
** fixes real-time issues
* fix call/jmp instruction emulation (Izik Eidus)
** fixes Vista x64 installation
* fix save/restore/migrate with multiple nics
* fix build on i386 uniprocessor w/ no ioapic hosts
* fix smp_call_function_single() emulation on older hosts
** fixes smp guests not booting on RHEL 5 hosts
* make qemu/kvm memory allocation match plain qemu more closely (Izik Eidus)
** fixes issues with large memory guests
* libkvm compile fixes (Carlo Marcelo Arenas Belon, Jerone Young)

= kvm-51 [7 nov 2007] =

* fix some x86 emulator one-byte insns (fixes W2K3 installer again)
* fix host hangs with NMI watchdog on AMD
* fix guest SMP on AMD
* fix dirty page tracking when clearing a guest page (Dor Laor)
* more portability work (Hollis Blanchard, Jerone Young)
* fix [[FlexPriority]] with guest smp (Sheng Yang)
* improve rpm specfile (Akio Takebe, Avi Kivity)
* fix external module vs portability work (Andrea Arcangeli)
* remove elpin bios due to license violation
* testsuite shutdown pio port
* don't advertise svm on the guest
* fix reset with kernel apic (Markus Rechberger)

= kvm-50 [2 nov 2007] =

* fix smp_call_function_mask() emulation on preemptible kernels
* move libkvm into own directory (Hollis Blanchard)
* fix save/restore/migrate for new memory slot management (Uri Lublin)
* compile fixes (Uri Lublin, Avi Kivity)
* fix recursive locking on mmap() (Anthony Liguori)
* remove some cr2 dependencies from x86 emulator
* further simplify x86 emulator
* more portability work (Carsten Otte, Hollis Blanchard)
* Intel [[FlexPriority]] support (Sheng Yang)
* fix dirty page tracking on aliased pages (Uri Lublin)

= kvm-49 [29 oct 2007] =

* Fix PIT time-drift-fix (only with -no-kvm-irqchip) (Dan Kenigsberg)
* Fix vnc auth error with clients <= 3.7 protocol (Dan Kenigsberg)
* Don't spin on hlt with interrupts disabled (Dor Laor)
* Fix pxe boot (Izik Eidus)
* Hide the Intel real-mode tss from userspace (Izik Eidus)
* Automatic memory slot management for libkvm (Izik Eidus)
* Fix problem with std-vga and 4GB guests (Izik Eidus)
* External module compat for smp_call_function_mask() (Laurent Vivier)
* More portability work (Jerone Young, Christian Borntraeger, Zhang Xiantao)
* Fix sleep-in-atomic-context during vcpu init
* Fix 'push imm8' emulation (fixes W2K3 installer)
* Intercept invd and wbinvd on AMD
* Reduce emulator dependency on cr2 (mov abs insns)
* Move page fault processing to common code
* Fix rmap memory consumption oops due to increased rmap usage with swap
* Fix potential memory leak with kernel-allocated memslots (Izik Eidus)
* Export memory slot allocation mechanism (Izik Eidus)
* Add kernel-private memslots (Izik Eidus)
* Fix local apic divide-by-zero (Kevin Pedretti)
* Improve local apic timer wraparound handling (Kevin Pedretti)
* Use newly available smp_call_function_mask() (Laurent Vivier)
* Micro-optimize register usage on vmentry/vmexit (Laurent Vivier)
* Cleanups, compilation fixes (Akio Takebe, Anthony Liguori, Avi Kivity)

= kvm-48 [18 oct 2007] =

* use precise cpu accounting on ppc and s390 (Christian Borntraeger)
* make guest time accounting actually work (Laurent Vivier)
* fix host memory corruption when setting the guest dirty bit
* allow swapping with older userspace (Anthony Liguori)
* allow custom memory setup using libkvm (Gerd Hoffmann)

= kvm-47 [18 oct 2007] =

* Reset fixes (Eddie Dong, Avi Kivity)
* Portability work (Carsten Otte)
* Cleanups (Anthony Liguori, Laurent Vivier)
* Simplify guest pagetable dirty bit management
* Fix nx bit for huge pages
* Fix write access to clean large pages (fixes rmap leak)
* Support for Linux 2.6.16 guests (movnti instruction) (Sheng Yang)
* Simplify apic timer backlog processing
* Move interrupt injection out of critical section
* x86 emulator work (Nitin A Kamble)
* restore freebsd support on AMD (fix smsw and lmsw) (Aurelien Jarno)
* Simplify guest page table walker
* Partial guest swapping (Izik Eidus)
* kvmctl improvements (Anthony Liguori)
* libkvm, qemu compilation against older kernels
* guest time accounting (Laurent Vivier)
* configure improvements (Carlo Marcelo Arenas Belon)
* fix 4GB+ configurations (Izik Eidus)
* cross compilation support (Jerone Young)

= kvm-46 [10 oct 2007] =

* fix host oops on bad guest ioapic accesses
* handle NMIs before enabling host interrupts
* add general guest memory accessors (Izik Eidus)
* allow user control over shadow cache size (Izik Eidus)
* auto tune shadow cache size with guest memory (Izik Eidus)
* allocate guest memory in userspace instead of in kernel (Izik Eidus)
* code style fixes (Mike Day, Anthony Liguori)
* lapic cleanups (Rusty Russell)
* fix acpi interrupt reporting for FreeBSD
* fix color problems on certain displays
* Red Hat 7.1 support
* vmmouse support (Dan Kenigsberg)
* fix sdl window caption when keyboard is captured (Dan Kenigsberg)
* improve libkvm configure script (Jerone Young)
* improve bios compilation support on x86_64 hosts (Laurent Vivier)
* fix acpi processor reporting for Windows 2000 with the ACPI HAL (Sheng Yang)

= kvm-45 [2 oct 2007] =

* don't use page->private for guest pages (Izik Eidus)
* x86 emulator cleanups, simplifications, and fixes (Laurent Vivier, Qing He)
* apic round robin delivery mode cleanup (Qing He)
* merge qemu-cvs
* fix compilation on older kernels (Rusty Russell, Avi Kivity)
* reduce tap networking latency
* fix FC6 x86_64 booting with -no-kvm
* fix code dump on exception

= kvm-44 [23 sep 2007] =
* fix smp guest boot
* fix IDE emulation bug with newer guest kernels (S.Çağlar Onur)
* support VMware server as guest (Ryan Harper)
* fix smp race in shadow code (Izik Eidus)
* allow guest page faults to bypass kvm on Intel (performance boost)

= kvm-43 [21 sep 2007] =

* fix ioapic edge-triggered interrupt handling

= kvm-42 [20 sep 2007] =

* important host oops fix
* document -no-kvm-irqchip option in qemu help message (Carlo Marcelo Arenas Belon)
* acpi bios: export pci irqs as active high
* avoid redelivery of edge-triggered ioapic interrupts if already in service
* implement ioapic polarity
* fix x86 emulator merge problems (Nitin A Kamble, Laurent Vivier)
* fix x86 repne decoding (fixes OpenBSD boot regression) (Laurent Vivier)
* install kvm_para.h (Gerd Hoffman)

= kvm-41 [19 sep 2007] =

* refactor hypercall infrastructure for simplicity and better smp support (Anthony Liguori)
* fix ioapic level triggered interrupt redelivers (solves networking stalls)
* reduce efer reloads with 32-bit guests; minor performance improvement
* split x86 emulator decode and execute stages (Laurent Vivier)
* fix pic interrupt delivery (solves time going double speed on x86_64 Linux guests) (Qing He)
* adaptive live migration bandwidth limits (Uri Lublin)

= kvm-40 [16 sep 2007] =

* fix guest reboot (most scenarios)
* further x86 emulator work (Nitin A Kamble)
* compile fixes for older kernels
* make the external module work again

= kvm-39 [12 sep 2007] =

* provide div64_64() for older kernels
* improve emulation failure reporting
* more x86 emulator work (push imm8, pushf, call near) (Nitin A Kamble)
* don't use TPR shadow on i386 (Sheng Yang)

= kvm-38 [12 sep 2007] =

* fix fpu indication for Solaris (Amit Shah)
* Avoid GFP_NOWAIT allocation in mmu
* Fix runtime smp_processor_id() warning in lapic
* Move vcpu loop into subarch independent loop
* Rename kvm_arch_ops to kvm_x86_ops (Christian Ehrhardt)
* Fix missing "genapic" on i386 (Eddie Dong)
* Fix lapic hrtimer migration (Qing He)
* Fix lapic 64-bit division on i386 (Jindrich Makovicka)
* Simplify memory allocation ioctl (Laurent vivier)
* Keep control register shadows in sync (Rusty Russell)
* Retire invlpg (Rusty Russell)
* Expose get_cs_db_l_bits for kvm-lite (Rusty Russell)
* Fix network boot (Anthony Liguori)
* Round up memory in libkvm (Anthony Liguori)
* Fix option ROM loading (Anthony Liguori)
* Revert FACP ACPI change for Vista
* Fix segfault with -no-kvm
* lapic hrtimer external module compatibility (Qing He, Avi Kivity)
* improved (still imprefect) reboot
* better bios smp detection

= kvm-37 [9 sep 2007] =

* in-kernel lapic, ioapic, and pic (Eddie Dong, Qing He, Sheng Yang, Gregory Haskins, Dor Laor, Avi Kivity)
* split segment reload (vmx microoptimization) (Laurent Vivier)
* fix vga redraw regression (Izik Eidus)
* fix testsuite compilation with older assemblers (H. Peter Anvin)

= kvm-36 [22 aug 2007] =

* support guests with more than 2GB of RAM on 64-bit hosts (Izik Eidus)
* fix rare host oops on guest context switch
* avoid smp_call_function_single() warning on suspend/resume
* more real mode emulator work (Nitin A Kamble)
* Windows x64 support (Sheng Yang)
* close minor signal handling race
* carry bios in kvm source tree for easier maintenance
* fix -std-vga (Uri Lublin)
* advertise kvm in vnc window title (Matthew Kent)
* fix Windows SMP guests consuming cpu time when idle (Igor Lvovsky)

= kvm-35 [15 aug 2007] =

* fix kvm refusing to load on Core processors (Glauber de Oliveira Costa)
* improve qemu monitor handling CR/LF sequences (Jim Paris)
* fix compile warning in qemu (Luca Tettamanti)

= kvm-34 [13 aug 2007] =

* make kvm preemptible
* allow calling sleeping functions in the kvm exit handlers (Shaohua Li)
* this is a first step in getting guest swapping
* fix running kvm on nx-incapable host kernel on nx-capable hardware
* fix more fallback from the x86 emulator writeback changes (Aurelien Jarno, Avi Kivity)
* remove vmx specific code from subarch independent code (Gregory Haskins)
* allocate vcpus as needed (Rusty Russell)
* consolidate x86 emulator guest read/write code (Laurent Vivier)
* cleanup string pio instruction emulation (Laurent Vivier)
* ensure all cpus have the same vmx features (Sheng Yang)
* version string for external module
* disable long mode capability bit on 32-bit kernels
* fix qemu -isapc (Uri Lublin)
* fixes for smp live migration
** this is still raw
* fix unhandled wrmsr MSR_CSTAR on i386 (Luca Tettamanti)
* some migration fixes (Jim Paris)
* the usual cleanups and minor fixes (various but mostly Rusty)

= kvm-33 [23 jul 2007] =

* fix massive performance regression

= kvm-32 [23 jul 2007] =

* fix oops with the slub allocator (CONFIG_SLUB)
* fix cmov instruction emulation, trashed by the mmio rmw fix
* fix rare, silent data corruption on writes that cross a page boundary and touch a page table (Aurelien Jarno, Avi Kivity)
* fix race between vm creation and vcpu hotunplug (Rusty Russell)
* fix guest turning on pae with invalid pdptres (Rusty Russell)
* adapt external module to changed kmem_cache_create() api
* allow external module on 2.6.22 i386 nonpae
* fix regression in network throughput caused by guest smp changes (Aurelien Jarno, Avi Kivity)
* live migration updates (Uri Lublin)
* minor cleanups (Nguyen Anh Quynh, Avi Kivity)

= kvm-31 [19 jul 2007] =

* a few cleanups that somehow evaded kvm-30 (Jeff Dike, Rusty Russell)
* allow the external module to compile on older kernels.

= kvm-30 [19 jul 2007] =

* minor fixes and cleanups (Jeff Dike, Rusty Russell, Avi Kivity)
* kernel pio string write (Eddie Dong)
* guest smp kernel fixes
* rdmsr and wrmsr real mode emulation
* fix real mode shadow pages aliasing nx large page shadows
* enable guest smp in qemu
* fix external module installer
* revert ide enable changes that caused an I/O regression

= kvm-29 [12 jul 2007] =

* live migration from 32-bit hosts to 64-bit hosts (Uri Lublin)
* monotonic timestamp counter on Intel
* more real mode support (Nitin A Kamble)
* infrastructure for in-kernel PIC and APIC (Gregory Haskins, Eddie Dong)
* fix read-modify-write to mmio (fixes F7 installer) (Luca Tettamanti)
* fix rebooting a long-running guest
* reliably detect if svm was disabled by bios (Joerg Roedel)
* suspend/resumes fixes (will not work with older kernels)
* fix nx confusion with large pages and real mode
* remove dependency on libuuid
* fix registers access in monitor/gdbstub (Anthony Liguori)
* minor fixes and cleanups (various)

= kvm-28 [10 jun 2007] =

* fix host oops on guest context switch
* many code cleanups (Nguyen Anh Quynh, others)
* prepare kernel for guest smp
* update libkvm for guest smp
* update testsuite for guest smp
* emulate hlt in real mode (avoids crash when booting from unformatted disk)
* initialize ata ports for Fedora 7 guests (Luca Tettamanti)

= kvm-27 [3 jun 2007] =

* use slab cache for mmu shadow pages
* make shadow pte updates atomic (for guest smp)
* general mmu cleanups

= kvm-26 [27 may 2007] =

* implement wbinvd emulation, triggered by Windows Vista
* compile fixes (Markus Rechberger, Avi Kivity)

= kvm-25 [24 may 2007] =

* massive performance increase (Eddie Dong)
* regenerate bios from latest bochs sources, hopefully fixing a regression with some guests
* some testsuite work (Anthony Lihuori, Eddie Dong, Avi Kivity)
* minor fixes (various)

= kvm-24 [8 may 2007] =

* fix oops loading kvm-intel module on i386 with highmem

= kvm-23 [7 may 2007] =

* OpenBSD 4.1 i386 support (Matthew Gregan)
* Fix host and guest crashes on reboot

= kvm-22 [6 may 2007] =

* Significant performance improvements (Anthony Liguori, Eddie Dong, Qing He, Avi Kivity)
* Fix longstanding bug: time runs at double speed on x86_64 Linux (Qing He)
* Windows Vista 32-bit support (Qing He, Jun Nakajima)
* Support for kvm abi 10 modules
* Minor updates

= kvm-21 [27 apr 2007] =

* fix regression on Core (not Core 2) processors
* performance improvements (Eddie Dong, Anthony Liguori)
* minor fixes

= kvm-20 [24 apr 2007] =

* Windows 2000 support
* performance enhancements
* patch against latest kernel tree included in tarball
* fix oops with 32-bit nonpae guests

= kvm-19 [16 apr 2007] =

* bug fixes
* memory aliasing api

= kvm-18 [26 mar 2007] =

* merged new userspace API
* revert the optimization which killed some 32-bit Linux guests
* reboot support on Intel hosts (AMD are already supported)
* better timekeeping under load (Uri Lublin)
* other minor fixes and cleanups

= kvm-17 [25 mar 2007] =

* live migration enhancements (Uri Lublin)
* better/working acpi support
* revert to unhacked qemu bios
* fix some 32-bit nonpae guests (*BSD)
* initial ballooning support
* random fixes

= kvm-16 [7 mar 2007] =

* bug fixes (including a nasty one on module load)
* use lanana assigned minor device number for /dev/kvm

= kvm-15 [26 feb 2007] =

* live migration with kvm (Uri Lublin)
* based on Anthony Liguori's qemu patches
* new userspace interface (work in progress)
* the usual random fixes

= kvm-14 [19 feb 2007] =

* qemu 0.9.0
* too many goodies to list
* kvm can no longer share qemu's bios on Intel hosts due to real mode trouble. use the supplied bios.
* migration now based on Anthony Liguori's live migration patches (Uri Lublin)
** currently, only non-live migration is supported under kvm
* handle smi on host on AMD hosts (Joerg Roedel)
* random fixes

= kvm-13 [8 feb 2007] =

* add dirty page tracking in some corner cases for live migration
* fix lockups on nx-challenged hosts
* host suspend/resume
** nobody's testing this, so it's probably broken
* host cpu hotplug support
* beginning of paravirt support (Ingo Molnar)
* guest reboot support (Markus Rechberger, Joerg Roedel)
* pio latency reduction (Anthony Liguori)
* stone age kernel compatibility (Markus Rechberger)
* the usual cleanups and stability fixes

= kvm-12 [23 jan 2007] =

* More migration work (Uri Lublin)
* savevm/loadvm (and migration) work on AMD (Leonard Norrgard)
* More guest support
* mmu testsuite and fixes
* Windows ACPI install/run support (Dor Laor)
* Fix host reboot on guest reboot on AMD (Joerg Roedel)

= kvm-11 [11 jan 2007] =

* stabilization fixes
* vmexit profiling (Ingo Molnar; requires Linux 2.6.20+)

= kvm-10 [7 jan 2007] =

* more hypercall work
* cleanup irq handling
* shadow page table caching
* migration fixes
* stabilization fixes

= kvm-9 [31 dec 2006] =

* API documentation (James Jacobsson)
* More stabilization fixes (Yoshimi Ichiyanagi, Ingo Molnar, Nguyen Anh Quynh)
* Interactivity improvements (Dor Laor)

= kvm-8 [21 dec 2006] =

* msr fixes (Michael Riepe)
* more guest support (Michael Riepe)
* random fixes
* fpu state corruption fix on AMD hosts

= kvm-7 [12 dec 2006] =

* prevent loading arch module on wrong hardware
* fix for macbooks
* other minor fixes

= kvm-6 [11 dec 2006] =

* AMD 32-bit host support (Anthony Liguori)
* more migration work
* stabilization
* improved performance
* improved guest support on AMD

= kvm-5 [28 nov 2006] =

* AMD SVM support (x86-64 hosts only)
* Preliminary live migration support
* 'make install' also installs kernel modules, if selected
* random fixes

= kvm-4 [21 nov 2006] =

* added the msr work
** suspend/resume should work now
* more vmdk compatibility work
* random build updates

= kvm-3 [15 nov 2006] =

[Avi Kivity retained the natural number versioning after he contemplated the
confusion that can arise from having releases 1, 2, and 0.3]

Kernel module
* make exit reason numbers explicit
* sync kernel module with -mm tree
** asm constraint fixes
** userspace interface blurb
** segment restore across mode switch (fixes etherboot)
** segment asm constraint fix (Bernhard Rosenkraenzer)
** segment access cleanup

libkvm:
* better error reporting (Simon Kagstrom)
* 'make clean'
* attributions and license

kvmctl:
* add option to launch guest in 32-bit mode
* add test programs

qemu/kvm:
* autodetect kvm presence (Simon Kagstrom)

General
* fix host arch detection on debian
* fix ./configure on debian (Gildas)
* toplevel 'make clean'

= ?? [9 nov 2006] =

* much easier to get running, see updated HOWTO
* now just one download, get yours while supplies last
* single qemu binary for kvm and non-kvm runs (Anthony Liguori)
* accompanying external kernel module package has all bugfixes folded in (plus a bit of cosmetics)

= lkml submission v4 [5 nov 2006] =
* [http://lwn.net/Articles/207875/]
* detect msrs on host dynamically. Avoids oopses on non-ia32e capable processors.
* web site: http://kvm.sourceforge.net
* slightly rediffed

= lkml submission v3 [26 oct 2006] =
* [http://uwsg.indiana.edu/hypermail/linux/kernel/0610.3/0747.html]
* mailing list: kvm-devel@public.gmane.org (http://lists.sourceforge.net/lists/listinfo/kvm-devel)
* applied code review comments
* fixed set_sregs() ioctl corrupting guest state if cr0.pe changed (a polite way of saying that loading a saved vm was broken)

= lkml submission v2 [23 oct 2006] =
* [http://lwn.net/Articles/205580/]
* fixed a lockup on i386 with host memory >= 4GB
* finer patch split to conform to vger limits
* minor fixes
* send through script to avoid mailer damage

= lkml submission v1 [19 oct 2006] =

* [http://lkml.org/lkml/2006/10/19/146]

__NOTOC__

TODO

2008-01-21T10:05:34Z

AviKivity: typo

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it
* Add HPET support to qemu and kvm

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy but ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2008-01-21T10:04:39Z

AviKivity: remove completed tasks

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it
* Add HPET support to qemu and kvm

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-12-26T14:12:47Z

AviKivity: HPET

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it
* Add HPET support to qemu and kvm

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help. Maybe use mm->mmap_sem.
* With the above, don't hold kvm->lock during instruction emulation.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.
* Add a String tag to the decoder tables, and use it to eliminate special rep_prefix processing
* Unify the various switch (b) into just two: one for regular insns and one for two byte insns.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-25T09:57:32Z

AviKivity: qemu memory footprint

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests
* Reduce qemu memory footprint when using kvm

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help. Maybe use mm->mmap_sem.
* With the above, don't hold kvm->lock during instruction emulation.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.
* Add a String tag to the decoder tables, and use it to eliminate special rep_prefix processing
* Unify the various switch (b) into just two: one for regular insns and one for two byte insns.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-21T14:25:47Z

AviKivity: more x86 emulator todos

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help. Maybe use mm->mmap_sem.
* With the above, don't hold kvm->lock during instruction emulation.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.
* Add a String tag to the decoder tables, and use it to eliminate special rep_prefix processing
* Unify the various switch (b) into just two: one for regular insns and one for two byte insns.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-20T20:44:30Z

AviKivity: mmu locking

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help. Maybe use mm->mmap_sem.
* With the above, don't hold kvm->lock during instruction emulation.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-20T20:42:57Z

AviKivity: fix large page support entry

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with npt/ept) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-20T17:48:53Z

AviKivity: optimize segment access in emulator

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.
* Change the emulator initialization sequence not to read all segment registers (this is slow), instead read them on demand. On 64-bit, no segments are usually needed while on 32-bit only cs and ds are commenly required.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-19T15:45:38Z

AviKivity: vmgl

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date
* Add [http://www.cs.toronto.edu/~andreslc/xen-gl/ vmgl] support to qemu. Port to virtio. Write a Windows driver.

__NOTOC__

TODO

2007-11-18T10:51:33Z

AviKivity: adjust NonPT task

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag (or maybe its inverse, Paging) to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date

__NOTOC__

TODO

2007-11-18T10:50:43Z

AviKivity: the long journey towards removing cr2 from the emulator has ended.

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Add a NonPT flag to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date

__NOTOC__

TODO

2007-11-18T10:49:08Z

AviKivity: paging_tmpl.h cleanup

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.
* Move set_pte_common(), set_pte(), set_pde(), and fetch() from paging_tmpl.h to mmu.c. These functions depend very little on the current paging mode.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Remove the dependency on cr2 from the emulator (in progress)
* Add a NonPT flag to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date

__NOTOC__

TODO

2007-11-15T14:34:25Z

AviKivity: kvm->lock removal

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)
* Change memory slot locking so that we can read and write guest memory without kvm->lock. RCU or a reader/writer lock may help.

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Remove the dependency on cr2 from the emulator
* Add a NonPT flag to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date

__NOTOC__

TODO

2007-11-15T10:49:33Z

AviKivity: NonPT

= TODO =
------------------------------------
The following items need some love. Please post to the list if you are interested in helping out:

* Real mode support: VT support for real mode is terrible, so we need to do it in software. This means extending the x86 emulator (x86_emulate.c) to handle more instructions, and changing the execution loop to call the emulator for real mode (in progress).
* Emulate the architectural performance monitor counters/msrs, for Linux nmi watchdog support.
* Emulate MSR_IA32_DEBUGCTL for guests which use it
* Emulate x86 hardware task switching
* Bring up Windows 95 and Windows 98 guests
* Support connecting the host's /dev/sg* to qemu's SCSI emulation. This allows controlling tape drives and media changers from qemu. (in progress)
* Batch writes to 4-plane vga memory and other side-effect-free mmio to improve performance
* Implement MSR_EFER on i386, on processors which support it

The following smaller scale tasks can be a nice entry point to someone wishing to get involved:

* Store command line options in an empty snapshot in a qcow2 format image file. This allows an image file to be self contained: <code><nowiki>qemu file.img</nowiki></code> should be enough to launch a fully configured virtual machine.
* Allow all cpuid features supported by kvm to be passed to the guest; add a command line option to specifiy the cpuid explicitly to allow migration in a heterogeneous server farm.
* Add a Unix domain socket device. With this, the guest can talk to a pci device which is connected to a Unix domain socket on the host.
* Add a qemu interface for sharing memory between guests. Using a pci device to expose the shared memory is probably a good starting point.
* Allow userspace to manage which msrs are emulated as no-ops (read zero, write ignored) to hack support for some guests

MMU related:
* Support large pages (in conjunction with the item above) so that if the guest uses a large page mapping and the guest memory is backed by hugetlbfs, a large-page pte is created.
* Improve mmu page eviction algorithm (currently FIFO, change to approximate LRU).
* Add a read-only memory type.
* Implement AM20 for dos and the like.
* Implement direct page tables on paravirt_ops enabled Linux guests (in progress)

x86 emulator updates:
* Trap #UD and emulate sysenter/syscall/sysret/sysexit. These instructions don't exist on all cpus in all modes, so they hinder cross-vendor migration (in progress)
* Remove the dependency on cr2 from the emulator
* Add a NonPT flag to instructions that are never used for page table updates (like add, sub, call). Teach the mmu to unshadow page tables if a NonPT instruction is executed on them.

Interactivity improvements:
* If for several frames in a row a large proportion of the framebuffer pages are
changing, then for the next few frames don't bother to get the dirty page log
from kvm, but instead assume that all pages are dirty. This will reduce page
fault overhead on highly interactive workloads.
* When detecting keyboard/video/mouse activity, scale up the frame rate; when
activity dies down, scale it back down (applicable to qemu as well).

Bug fixes:
* Less sexy bug ever important, fixing bugs is one of the most important contributions

For the adventurous:

* Emulate the VT and SVM instructions, so that kvm can run in a virtual machine. Test by running a VM in a VT guest in an SVM guest on VT hardware, as well as running a VM in an SVM guest in a VT guest on SVM hardware.
* Emulate the VT and SVM instruction sets on qemu. This would be very beneficial to debugging kvm.
* Keep this TODO up to date

__NOTOC__