From 9a6671591dca68bf2f3ed6658ad43ff757411c1e Mon Sep 17 00:00:00 2001
From: Avi Kivity <avi@redhat.com>
Date: Thu, 27 May 2010 14:46:04 +0300
Subject: [PATCH] --- yaml --- r: 202307 b: refs/heads/master c:
 ec87fe2afcbcc4f430554980ec3e408bae34229d h: refs/heads/master i:   202305:
 32568f6da63eb147734cbeb91b4c868b57a1e1ab   202303:
 8dc147cba84aff842a57a79d9fbd4ae25df57618 v: v3

---
 [refs]                          |  2 +-
 trunk/Documentation/kvm/mmu.txt | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/[refs] b/[refs]
index 1806773bd6d9..27d918aa5130 100644
--- a/[refs]
+++ b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 8184dd38e22fcaec664c2b98c382b85c26780e26
+refs/heads/master: ec87fe2afcbcc4f430554980ec3e408bae34229d
diff --git a/trunk/Documentation/kvm/mmu.txt b/trunk/Documentation/kvm/mmu.txt
index 2201dcba92a1..1e7ecdd15bba 100644
--- a/trunk/Documentation/kvm/mmu.txt
+++ b/trunk/Documentation/kvm/mmu.txt
@@ -298,6 +298,25 @@ Host translation updates:
   - look up affected sptes through reverse map
   - drop (or update) translations
 
+Emulating cr0.wp
+================
+
+If tdp is not enabled, the host must keep cr0.wp=1 so page write protection
+works for the guest kernel, not guest guest userspace.  When the guest
+cr0.wp=1, this does not present a problem.  However when the guest cr0.wp=0,
+we cannot map the permissions for gpte.u=1, gpte.w=0 to any spte (the
+semantics require allowing any guest kernel access plus user read access).
+
+We handle this by mapping the permissions to two possible sptes, depending
+on fault type:
+
+- kernel write fault: spte.u=0, spte.w=1 (allows full kernel access,
+  disallows user access)
+- read fault: spte.u=1, spte.w=0 (allows full read access, disallows kernel
+  write access)
+
+(user write faults generate a #PF)
+
 Further reading
 ===============