The mem_access client might want to use hvm_emulate_one_no_write(),
in which case the RAM-to-RAM copy code in hvmemul_rep_movs() would
lead to an unwanted (and unexpected) write operation.
Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com>
---
xen/arch/x86/hvm/emulate.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 40de776..4cc7e01 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -951,6 +951,14 @@ static int hvmemul_rep_movs(
return hvmemul_do_mmio(
dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
+ /*
+ * The mem_access client might want to call hvm_emulate_one_no_write(),
+ * in which case going ahead would lead to an unwanted write.
+ * Fall back to slow emulation instead.
+ */
+ if ( unlikely(current->domain->arch.mem_access_emulate_enabled) )
+ return X86EMUL_UNHANDLEABLE;
+
/* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
bytes = *reps * bytes_per_rep;
--
1.7.9.5
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
