[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [xen master] x86/hvm: treat non-instruction fetch nested page faults also as read violations



commit 401d5c5cc5a780cad160aa0e3c282c11ac11dd0c
Author:     Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
AuthorDate: Thu Aug 28 16:03:26 2014 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Thu Aug 28 16:03:26 2014 +0200

    x86/hvm: treat non-instruction fetch nested page faults also as read 
violations
    
    As pointed out by Jan Beulich in
    http://lists.xen.org/archives/html/xen-devel/2014-08/msg01269.html:
    "Read-modify-write instructions absolutely need to be treated as read
    accesses, yet hardware doesn't guarantee to tell us so (they may
    surface as just write accesses)." This patch addresses the issue in
    both the VMX and the SVM side.
    
    VMX: Treat all write data access violations also as read violations (in
         addition to those that were already reported as read violations).
    SVM: Refine the meaning of read data access violations to distinguish
         between read/write and instruction fetch access violations.
    
    With this patch both VMX and SVM specific nested page fault handling code 
reports violations the same way, thus abstracting the hardware specific 
behaviour from the layers above.
    
    Suggested-by: Jan Beulich <JBeulich@xxxxxxxx>
    Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
---
 xen/arch/x86/hvm/svm/svm.c |    7 ++++++-
 xen/arch/x86/hvm/vmx/vmx.c |   15 ++++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b49a7d7..d29caa1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1403,8 +1403,13 @@ static void svm_do_nested_pgfault(struct vcpu *v,
     p2m_access_t p2ma;
     struct p2m_domain *p2m = NULL;
 
+    /*
+     * Since HW doesn't explicitly provide a read access bit and we need to
+     * somehow describe read-modify-write instructions we will conservatively
+     * set read_access for all memory accesses that are not instruction 
fetches.
+     */
     struct npfec npfec = {
-        .read_access = 1, /* All NPFs count as reads */
+        .read_access = !(pfec & PFEC_insn_fetch),
         .write_access = !!(pfec & PFEC_write_access),
         .insn_fetch = !!(pfec & PFEC_insn_fetch)
     };
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5e8e45e..d8e1475 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2352,8 +2352,21 @@ static void ept_handle_violation(unsigned long 
qualification, paddr_t gpa)
     p2m_type_t p2mt;
     int ret;
     struct domain *d = current->domain;
+
+    /*
+     * We treat all write violations also as read violations.
+     * The reason why this is required is the following warning:
+     * "An EPT violation that occurs during as a result of execution of a
+     * read-modify-write operation sets bit 1 (data write). Whether it also
+     * sets bit 0 (data read) is implementation-specific and, for a given
+     * implementation, may differ for different kinds of read-modify-write
+     * operations."
+     * - Intel(R) 64 and IA-32 Architectures Software Developer's Manual
+     *   Volume 3C: System Programming Guide, Part 3
+     */
     struct npfec npfec = {
-        .read_access = !!(qualification & EPT_READ_VIOLATION),
+        .read_access = !!(qualification & EPT_READ_VIOLATION) ||
+                       !!(qualification & EPT_WRITE_VIOLATION),
         .write_access = !!(qualification & EPT_WRITE_VIOLATION),
         .insn_fetch = !!(qualification & EPT_EXEC_VIOLATION)
     };
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.