From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, jun.nakajima@intel.com,
eddie.dong@intel.com, ian.jackson@eu.citrix.com,
Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com,
xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v3 1/2] x86/mem_event: Deliver gla fault EPT violation information
Date: Fri, 08 Aug 2014 09:04:38 +0100 [thread overview]
Message-ID: <53E48496.503@citrix.com> (raw)
In-Reply-To: <53E4919B020000780002A504@mail.emea.novell.com>
On 08/08/2014 08:00, Jan Beulich wrote:
>>>> On 08.08.14 at 01:12, <tamas.lengyel@zentific.com> wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2725,6 +2725,8 @@ void hvm_inject_page_fault(int errcode, unsigned long cr2)
>> int hvm_hap_nested_page_fault(paddr_t gpa,
>> bool_t gla_valid,
>> unsigned long gla,
>> + bool_t fault_in_gpt,
>> + bool_t fault_gla,
>> bool_t access_r,
>> bool_t access_w,
>> bool_t access_x)
> Afaic it is out of question to have a function with _six_ boolean
> parameters. This needs to be consolidated into a single flags field. I
> have actually done that already, in a patch serving a different
> purpose (see attached), as discussed recently on this list. I would
> very much appreciate if you either re-based yours on top of that or
> modified it along those lines.
>
>> @@ -2371,11 +2372,19 @@ static void ept_handle_violation(unsigned long qualification, paddr_t gpa)
>> }
>>
>> if ( qualification & EPT_GLA_VALID )
>> + {
>> __vmread(GUEST_LINEAR_ADDRESS, &gla);
>> + fault_gla = !!(qualification & EPT_GLA_FAULT);
>> + fault_in_gpt = !fault_gla;
> I am actually not agreeing with Andrew regarding the need for two
> flags here, if we already know that SVM also properly expresses the
> distinction between faults on page table accesses and faults on the
> actual translation. The attached patch is also coded in this way, and
> I agree with your earlier arguing for just a single flag.
I also agree. My suggestion for two flags was on the (wrong) assumption
that AMD didn't currently support providing this information (although I
should have picked up on this and retracted my suggestion).
~Andrew
next prev parent reply other threads:[~2014-08-08 8:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 23:12 [PATCH v3 1/2] x86/mem_event: Deliver gla fault EPT violation information Tamas K Lengyel
2014-08-07 23:12 ` [PATCH v3 2/2] tools/xen-access: Print gla valid/fault information Tamas K Lengyel
2014-08-08 8:07 ` Andrew Cooper
2014-08-07 23:33 ` [PATCH v3 1/2] x86/mem_event: Deliver gla fault EPT violation information Tian, Kevin
2014-08-08 7:00 ` Jan Beulich
2014-08-08 8:04 ` Andrew Cooper [this message]
2014-08-08 8:36 ` Tamas Lengyel
2014-08-08 8:57 ` Jan Beulich
2014-08-08 9:02 ` Andrew Cooper
2014-08-08 9:17 ` Tamas Lengyel
2014-08-08 8:48 ` Tamas Lengyel
2014-08-08 10:28 ` Tamas Lengyel
2014-08-08 10:34 ` Jan Beulich
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=53E48496.503@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=JBeulich@suse.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.