From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>,
xen-devel@lists.xenproject.org
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, eddie.dong@intel.com,
ian.jackson@eu.citrix.com, Aravind.Gopalakrishnan@amd.com,
jun.nakajima@intel.com, boris.ostrovsky@oracle.com,
suravee.suthikulpanit@amd.com
Subject: Re: [PATCH 1/2] x86/mem_event: Deliver gla fault EPT violation information
Date: Thu, 7 Aug 2014 17:50:05 +0100 [thread overview]
Message-ID: <53E3AE3D.5040706@citrix.com> (raw)
In-Reply-To: <1407429823-3722-1-git-send-email-tamas.lengyel@zentific.com>
On 07/08/14 17:43, Tamas K Lengyel wrote:
> On Intel EPT the exit qualification generated by a violation also includes a bit (EPT_GLA_FAULT) which describes the following information:
> Set if the access causing the EPT violation is to a guest-physical address that is the translation of a linear address. Clear if the access causing the EPT violation is to a paging-structure entry as part of a page walk or the update of an accessed or dirty bit.
>
> For more information see Table 27-7 in the Intel SDM.
>
> This patch extends the mem_event system to deliver this extra information, which could be useful for determining the cause of a violation.
>
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
> ---
> xen/arch/x86/hvm/hvm.c | 6 ++++--
> xen/arch/x86/hvm/svm/svm.c | 2 +-
> xen/arch/x86/hvm/vmx/vmx.c | 4 +++-
> xen/arch/x86/mm/p2m.c | 7 ++++---
> xen/include/asm-x86/hvm/hvm.h | 4 +++-
> xen/include/asm-x86/p2m.h | 6 +++---
> xen/include/public/mem_event.h | 3 ++-
> 7 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e834406..b09a905 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2724,6 +2724,7 @@ void hvm_inject_page_fault(int errcode, unsigned long cr2)
>
> int hvm_hap_nested_page_fault(paddr_t gpa,
> bool_t gla_valid,
> + bool_t gla_fault,
> unsigned long gla,
> bool_t access_r,
> bool_t access_w,
> @@ -2832,8 +2833,9 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>
> if ( violation )
> {
> - if ( p2m_mem_access_check(gpa, gla_valid, gla, access_r,
> - access_w, access_x, &req_ptr) )
> + if ( p2m_mem_access_check(gpa, gla_valid, gla_fault, gla,
> + access_r, access_w, access_x,
> + &req_ptr) )
> {
> fall_through = 1;
> } else {
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 76616ac..1dbb12f 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1403,7 +1403,7 @@ static void svm_do_nested_pgfault(struct vcpu *v,
> p2m_access_t p2ma;
> struct p2m_domain *p2m = NULL;
>
> - ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul,
> + ret = hvm_hap_nested_page_fault(gpa, 0, 0, ~0ul,
How do you expect this to work? You don't know whether it was a linear
fault or a paging-structure fault for the NPT case, so presenting it is
a paging-structure fault is certainly wrong.
~Andrew
> 1, /* All NPFs count as reads */
> npfec & PFEC_write_access,
> npfec & PFEC_insn_fetch);
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2caa04a..0bd77b3 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2375,7 +2375,9 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
> else
> gla = ~0ull;
> ret = hvm_hap_nested_page_fault(gpa,
> - !!(qualification & EPT_GLA_VALID), gla,
> + !!(qualification & EPT_GLA_VALID),
> + !!(qualification & EPT_GLA_FAULT),
> + gla,
> !!(qualification & EPT_READ_VIOLATION),
> !!(qualification & EPT_WRITE_VIOLATION),
> !!(qualification & EPT_EXEC_VIOLATION));
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index bca9f0f..303dc2b 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1323,9 +1323,9 @@ void p2m_mem_paging_resume(struct domain *d)
> }
> }
>
> -bool_t p2m_mem_access_check(paddr_t gpa, bool_t gla_valid, unsigned long gla,
> - bool_t access_r, bool_t access_w, bool_t access_x,
> - mem_event_request_t **req_ptr)
> +bool_t p2m_mem_access_check(paddr_t gpa, bool_t gla_valid, bool_t gla_fault,
> + unsigned long gla, bool_t access_r, bool_t access_w,
> + bool_t access_x, mem_event_request_t **req_ptr)
> {
> struct vcpu *v = current;
> unsigned long gfn = gpa >> PAGE_SHIFT;
> @@ -1404,6 +1404,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, bool_t gla_valid, unsigned long gla,
> req->gfn = gfn;
> req->offset = gpa & ((1 << PAGE_SHIFT) - 1);
> req->gla_valid = gla_valid;
> + req->gla_fault = gla_fault;
> req->gla = gla;
> req->access_r = access_r;
> req->access_w = access_w;
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 0ebd478..38562ff 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -456,7 +456,9 @@ static inline void hvm_invalidate_regs_fields(struct cpu_user_regs *regs)
> }
>
> int hvm_hap_nested_page_fault(paddr_t gpa,
> - bool_t gla_valid, unsigned long gla,
> + bool_t gla_valid,
> + bool_t gla_fault,
> + unsigned long gla,
> bool_t access_r,
> bool_t access_w,
> bool_t access_x);
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 0ddbadb..8616fda 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -597,9 +597,9 @@ void p2m_mem_paging_resume(struct domain *d);
> * been promoted with no underlying vcpu pause. If the req_ptr has been populated,
> * then the caller must put the event in the ring (once having released get_gfn*
> * locks -- caller must also xfree the request. */
> -bool_t p2m_mem_access_check(paddr_t gpa, bool_t gla_valid, unsigned long gla,
> - bool_t access_r, bool_t access_w, bool_t access_x,
> - mem_event_request_t **req_ptr);
> +bool_t p2m_mem_access_check(paddr_t gpa, bool_t gla_valid, bool_t gla_fault,
> + unsigned long gla, bool_t access_r, bool_t access_w,
> + bool_t access_x, mem_event_request_t **req_ptr);
> /* Resumes the running of the VCPU, restarting the last instruction */
> void p2m_mem_access_resume(struct domain *d);
>
> diff --git a/xen/include/public/mem_event.h b/xen/include/public/mem_event.h
> index 3831b41..5785ff9 100644
> --- a/xen/include/public/mem_event.h
> +++ b/xen/include/public/mem_event.h
> @@ -62,7 +62,8 @@ typedef struct mem_event_st {
> uint16_t access_w:1;
> uint16_t access_x:1;
> uint16_t gla_valid:1;
> - uint16_t available:12;
> + uint16_t gla_fault:1;
> + uint16_t available:11;
>
> uint16_t reason;
> } mem_event_request_t, mem_event_response_t;
next prev parent reply other threads:[~2014-08-07 16:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 16:43 [PATCH 1/2] x86/mem_event: Deliver gla fault EPT violation information Tamas K Lengyel
2014-08-07 16:43 ` [PATCH 2/2] tools/xen-access: Print gla valid/fault information Tamas K Lengyel
2014-08-07 16:50 ` Andrew Cooper [this message]
2014-08-07 17:14 ` [PATCH 1/2] x86/mem_event: Deliver gla fault EPT violation information Tamas Lengyel
2014-08-07 17:34 ` Andrew Cooper
2014-08-07 17:56 ` Tamas Lengyel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E3AE3D.5040706@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=boris.ostrovsky@oracle.com \
--cc=eddie.dong@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tamas.lengyel@zentific.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.