The name of the "with_gla" flag is confusing; it has nothing to do
with the existence or lack thereof of a faulting GLA, but rather where
the fault originated. The npfec.kind value is always valid, and
should thus be propagated, regardless of whether gla_valid is set or
not.
In particular, gla_valid will never be set on AMD systems; but
npfec.kind will still be valid and should still be propagated.
Signed-off-by: Alexandru Isaila <aisa...@bitdefender.com>
Signed-off-by: George Dunlap <george.dun...@citrix.com>
---
CC: Andrew Cooper <andrew.coop...@citrix.com>
CC: Jan Beulich <jbeul...@suse.com>
CC: Tim Deegan <t...@xen.org>
CC: Tamas K Lengyel <tamas.leng...@zentific.com>
CC: Razvan Cojocaru <rcojoc...@bitdefender.com>
---
xen/arch/x86/mm/mem_access.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index d9e64fcbb9..699a315076 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -232,12 +232,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
{
req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
req->u.mem_access.gla = gla;
-
- if ( npfec.kind == npfec_kind_with_gla )
- req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
- else if ( npfec.kind == npfec_kind_in_gpt )
- req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
}
+
+ if ( npfec.kind == npfec_kind_with_gla )
+ req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
+ else if ( npfec.kind == npfec_kind_in_gpt )
+ req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
req->u.mem_access.flags |= npfec.read_access ? MEM_ACCESS_R : 0;
req->u.mem_access.flags |= npfec.write_access ? MEM_ACCESS_W : 0;
req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
--
2.19.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
