3 files changed, 38 insertions, 24 deletions

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 03497909539e..31575e220f3b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -556,3 +556,35 @@ Why:	udev fully replaces this special file system that only contains CAPI
         NCCI TTY device nodes. User space (pppdcapiplugin) works without
         noticing the difference.
 Who:    Jan Kiszka <jan.kiszka@web.de>
+
+----------------------------
+
+What:   KVM memory aliases support
+When:   July 2010
+Why:    Memory aliasing support is used for speeding up guest vga access
+        through the vga windows.
+
+        Modern userspace no longer uses this feature, so it's just bitrotted
+        code and can be removed with no impact.
+Who:    Avi Kivity <avi@redhat.com>
+
+----------------------------
+
+What:   KVM kernel-allocated memory slots
+When:   July 2010
+Why:    Since 2.6.25, kvm supports user-allocated memory slots, which are
+        much more flexible than kernel-allocated slots.  All current userspace
+        supports the newer interface and this code can be removed with no
+        impact.
+Who:    Avi Kivity <avi@redhat.com>
+
+----------------------------
+
+What:   KVM paravirt mmu host support
+When:   January 2011
+Why:    The paravirt mmu host support is slower than non-paravirt mmu, both
+        on newer and older hardware.  It is already not exposed to the guest,
+        and kept only for live migration purposes.
+Who:    Avi Kivity <avi@redhat.com>
+
+----------------------------
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 18b9d0ca0630..06bbbed71206 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -460,13 +460,6 @@ in sys_read() and friends.
 
 --------------------------- dquot_operations -------------------------------
 prototypes:
-        int (*initialize) (struct inode *, int);
-        int (*drop) (struct inode *);
-        int (*alloc_space) (struct inode *, qsize_t, int);
-        int (*alloc_inode) (const struct inode *, unsigned long);
-        int (*free_space) (struct inode *, qsize_t);
-        int (*free_inode) (const struct inode *, unsigned long);
-        int (*transfer) (struct inode *, struct iattr *);
         int (*write_dquot) (struct dquot *);
         int (*acquire_dquot) (struct dquot *);
         int (*release_dquot) (struct dquot *);
@@ -479,13 +472,6 @@ a proper locking wrt the filesystem and call the generic quota operations.
 What filesystem should expect from the generic quota functions:
 
                 FS recursion    Held locks when called
-initialize:     yes             maybe dqonoff_sem
-drop:           yes             -
-alloc_space:    ->mark_dirty()  -
-alloc_inode:    ->mark_dirty()  -
-free_space:     ->mark_dirty()  -
-free_inode:     ->mark_dirty()  -
-transfer:       yes             -
 write_dquot:    yes             dqonoff_sem or dqptr_sem
 acquire_dquot:  yes             dqonoff_sem or dqptr_sem
 release_dquot:  yes             dqonoff_sem or dqptr_sem
@@ -495,10 +481,6 @@ write_info:	yes		dqonoff_sem
 FS recursion means calling ->quota_read() and ->quota_write() from superblock
 operations.
 
-->alloc_space(), ->alloc_inode(), ->free_space(), ->free_inode() are called
-only directly by the filesystem and do not call any fs functions only
-the ->mark_dirty() operation.
-
 More details about quota locking can be found in fs/dquot.c.
 
 --------------------------- vm_operations_struct -----------------------------
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 2811e452f756..c6416a398163 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -23,12 +23,12 @@ of a virtual machine.  The ioctls belong to three classes
    Only run vcpu ioctls from the same thread that was used to create the
    vcpu.
 
-2. File descritpors
+2. File descriptors
 
 The kvm API is centered around file descriptors.  An initial
 open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
 can be used to issue system ioctls.  A KVM_CREATE_VM ioctl on this
-handle will create a VM file descripror which can be used to issue VM
+handle will create a VM file descriptor which can be used to issue VM
 ioctls.  A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
 and return a file descriptor pointing to it.  Finally, ioctls on a vcpu
 fd can be used to control the vcpu, including the important task of
@@ -643,7 +643,7 @@ Type: vm ioctl
 Parameters: struct kvm_clock_data (in)
 Returns: 0 on success, -1 on error
 
-Sets the current timestamp of kvmclock to the valued specific in its parameter.
+Sets the current timestamp of kvmclock to the value specified in its parameter.
 In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
 such as migration.
 
@@ -795,11 +795,11 @@ Unused.
                         __u64 data_offset; /* relative to kvm_run start */
                 } io;
 
-If exit_reason is KVM_EXIT_IO_IN or KVM_EXIT_IO_OUT, then the vcpu has
+If exit_reason is KVM_EXIT_IO, then the vcpu has
 executed a port I/O instruction which could not be satisfied by kvm.
 data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
 where kvm expects application code to place the data for the next
-KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a patcked array.
+KVM_RUN invocation (KVM_EXIT_IO_IN).  Data format is a packed array.
 
                 struct {
                         struct kvm_debug_exit_arch arch;
@@ -815,7 +815,7 @@ Unused.
                         __u8  is_write;
                 } mmio;
 
-If exit_reason is KVM_EXIT_MMIO or KVM_EXIT_IO_OUT, then the vcpu has
+If exit_reason is KVM_EXIT_MMIO, then the vcpu has
 executed a memory-mapped I/O instruction which could not be satisfied
 by kvm.  The 'data' member contains the written data if 'is_write' is
 true, and should be filled by application code otherwise.