summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorJan Kiszka <jan.kiszka@siemens.com>2012-09-07 11:17:47 (GMT)
committerAvi Kivity <avi@redhat.com>2012-09-09 13:39:17 (GMT)
commit7efd8fa145c340a68a9cd758012b6e0ae4883c93 (patch)
treee906e7755298d21bd95b9a700bc70a63a5ea2f1f /Documentation
parenta50abc3b2b469ee80bc0f9ef5b6d457ef72659a9 (diff)
downloadlinux-7efd8fa145c340a68a9cd758012b6e0ae4883c93.tar.xz
KVM: Improve wording of KVM_SET_USER_MEMORY_REGION documentation
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/virtual/kvm/api.txt22
1 files changed, 11 insertions, 11 deletions
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index b91bfd4..36befa7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -874,17 +874,17 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
be identical. This allows large pages in the guest to be backed by large
pages in the host.
-The flags field supports two flag, KVM_MEM_LOG_DIRTY_PAGES, which
-instructs kvm to keep track of writes to memory within the slot. See
-the KVM_GET_DIRTY_LOG ioctl. Another flag is KVM_MEM_READONLY when the
-KVM_CAP_READONLY_MEM capability, it indicates the guest memory is read-only,
-that means, guest is only allowed to read it. Writes will be posted to
-userspace as KVM_EXIT_MMIO exits.
-
-When the KVM_CAP_SYNC_MMU capability, changes in the backing of the memory
-region are automatically reflected into the guest. For example, an mmap()
-that affects the region will be made visible immediately. Another example
-is madvise(MADV_DROP).
+The flags field supports two flag, KVM_MEM_LOG_DIRTY_PAGES, which instructs
+kvm to keep track of writes to memory within the slot. See KVM_GET_DIRTY_LOG
+ioctl. The KVM_CAP_READONLY_MEM capability indicates the availability of the
+KVM_MEM_READONLY flag. When this flag is set for a memory region, KVM only
+allows read accesses. Writes will be posted to userspace as KVM_EXIT_MMIO
+exits.
+
+When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
+the memory region are automatically reflected into the guest. For example, an
+mmap() that affects the region will be made visible immediately. Another
+example is madvise(MADV_DROP).
It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
The KVM_SET_MEMORY_REGION does not allow fine grained control over memory