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 <[email protected]> Signed-off-by: George Dunlap <[email protected]> --- CC: Andrew Cooper <[email protected]> CC: Jan Beulich <[email protected]> CC: Tim Deegan <[email protected]> CC: Tamas K Lengyel <[email protected]> CC: Razvan Cojocaru <[email protected]> --- 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
