All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	eddie.dong@intel.com, xen-devel@lists.xen.org,
	jun.nakajima@intel.com, ian.jackson@eu.citrix.com
Subject: Re: [PATCH RFC V4 5/5] xen: Handle resumed instruction based on previous mem_event reply
Date: Wed, 06 Aug 2014 17:00:49 +0300	[thread overview]
Message-ID: <53E23511.1060606@bitdefender.com> (raw)
In-Reply-To: <53DFB5F1020000780002917C@mail.emea.novell.com>

On 08/04/2014 05:33 PM, Jan Beulich wrote:
>>>> On 04.08.14 at 13:30, <rcojocaru@bitdefender.com> wrote:
>> In a scenario where a page fault that triggered a mem_event occured,
>> p2m_mem_access_check() will now be able to either 1) emulate the
>> current instruction, or 2) emulate it, but don't allow it to perform
>> any writes.
>>
>> Changes since V1:
>>  - Removed the 'skip' code which required computing the current
>>    instruction length.
>>  - Removed the set_ad_bits() code that attempted to modify the
>>    'accessed' and 'dirty' bits for instructions that the emulator
>>    can't handle at the moment.
>>
>> Changes since V2:
>>  - Moved the __vmread(EXIT_QUALIFICATION, &exit_qualification); code
>>    in vmx.c, accessible via hvm_funcs.
>>  - Incorporated changes by Andrew Cooper ("[PATCH 1/2] Xen/mem_event:
>>    Validate the response vcpu_id before acting on it."
>>
>> Changes since V3:
>>  - Collapsed verbose lines into a single "else if()".
>>  - Changed an int to bool_t.
>>  - Fixed a minor coding style issue.
>>  - Now computing the first parameter to hvm_emulate_one_full()
>>    (replaced an "if" with a single call).
>>  - Added code comments about eip and gla reset (clarity issue).
>>  - Removed duplicate code by Andrew Cooper (introduced in V2,
>>    since committed).
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> ---
>>  xen/arch/x86/domain.c          |    3 ++
>>  xen/arch/x86/hvm/vmx/vmx.c     |   13 ++++++
>>  xen/arch/x86/mm/p2m.c          |   85 
>> ++++++++++++++++++++++++++++++++++++++++
>>  xen/include/asm-x86/domain.h   |    9 +++++
>>  xen/include/asm-x86/hvm/hvm.h  |    2 +
>>  xen/include/public/mem_event.h |   12 +++---
>>  6 files changed, 119 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index e896210..af9b213 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -407,6 +407,9 @@ int vcpu_initialise(struct vcpu *v)
>>  
>>      v->arch.flags = TF_kernel_mode;
>>  
>> +    /* By default, do not emulate */
>> +    v->arch.mem_event.emulate_flags = 0;
>> +
>>      rc = mapcache_vcpu_init(v);
>>      if ( rc )
>>          return rc;
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index c0e3d73..150fe9f 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1698,6 +1698,18 @@ static void vmx_enable_intro_msr_interception(struct 
>> domain *d)
>>      }
>>  }
>>  
>> +static bool_t vmx_exited_by_pagefault(void)
>> +{
>> +    unsigned long exit_qualification;
>> +
>> +    __vmread(EXIT_QUALIFICATION, &exit_qualification);
>> +
>> +    if ( (exit_qualification & EPT_GLA_FAULT) == 0 )
>> +        return 0;
>> +
>> +    return 1;
>> +}
>> +
>>  static struct hvm_function_table __initdata vmx_function_table = {
>>      .name                 = "VMX",
>>      .cpu_up_prepare       = vmx_cpu_up_prepare,
>> @@ -1757,6 +1769,7 @@ static struct hvm_function_table __initdata 
>> vmx_function_table = {
>>      .nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
>>      .hypervisor_cpuid_leaf = vmx_hypervisor_cpuid_leaf,
>>      .enable_intro_msr_interception = vmx_enable_intro_msr_interception,
>> +    .exited_by_pagefault  = vmx_exited_by_pagefault,
>>  };
>>  
>>  const struct hvm_function_table * __init start_vmx(void)
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 069e869..da1bc2d 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1391,6 +1391,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, bool_t 
>> gla_valid, unsigned long gla,
>>      p2m_access_t p2ma;
>>      mem_event_request_t *req;
>>      int rc;
>> +    unsigned long eip = guest_cpu_user_regs()->eip;
>>  
>>      /* First, handle rx2rw conversion automatically.
>>       * These calls to p2m->set_entry() must succeed: we have the gfn
>> @@ -1443,6 +1444,36 @@ bool_t p2m_mem_access_check(paddr_t gpa, bool_t 
>> gla_valid, unsigned long gla,
>>              return 1;
>>          }
>>      }
>> +    else if ( hvm_funcs.exited_by_pagefault && !hvm_funcs.exited_by_pagefault() ) /* don't send a mem_event */
> 
> DYM
> 
>     else if ( !hvm_funcs.exited_by_pagefault || !hvm_funcs.exited_by_pagefault() )

Well, no. That would mean that if hvm_funcs.exited_by_pagefault == 0
(which is the SVM case now), no mem_event will be sent (we'll just
emulate the current instruction). That would mean that in the SVM case
no mem_event will ever be sent and everything will be emulated.

With the original code, if hvm_funcs.exited_by_pagefault is not set,
i.e. in the SVM case, _all_ mem_events are being sent out (even those
that happened when exiting by nested pagefault). I'm not sure what the
status of SVM mem_event is at the moment, but it seemed the safer choice.

Sorry for the late reply, I've lost track of this question while
answering others.


Thanks,
Razvan Cojocaru

  reply	other threads:[~2014-08-06 14:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04 11:30 [PATCH RFC V4 1/5] xen: Emulate with no writes Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 2/5] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-08-04 14:16   ` Jan Beulich
2014-08-04 14:43     ` Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 3/5] xen: Force-enable relevant MSR events; optimize the number of sent MSR events Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 4/5] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-08-04 11:51   ` Ian Campbell
2014-08-04 14:26   ` Jan Beulich
2014-08-04 15:00     ` Razvan Cojocaru
2014-08-04 15:20       ` Jan Beulich
2014-08-05  8:09         ` Razvan Cojocaru
2014-08-05  8:39           ` Jan Beulich
2014-08-05  8:48             ` Razvan Cojocaru
2014-08-05  9:59             ` Razvan Cojocaru
2014-08-04 15:11     ` Razvan Cojocaru
2014-08-04 15:21       ` Jan Beulich
     [not found]         ` <53DFA537.70105@bitdefender.com>
2014-08-04 15:23           ` Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 5/5] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-08-04 14:33   ` Jan Beulich
2014-08-06 14:00     ` Razvan Cojocaru [this message]
2014-08-04 14:09 ` [PATCH RFC V4 1/5] xen: Emulate with no writes Jan Beulich
2014-08-04 14:25   ` Razvan Cojocaru
2014-08-04 14:42     ` Jan Beulich
2014-08-05 15:16   ` Razvan Cojocaru
2014-08-05 15:27     ` Razvan Cojocaru
2014-08-05 15:43     ` Jan Beulich
2014-08-06  8:42       ` Razvan Cojocaru
2014-08-06  8:50         ` Jan Beulich
2014-08-28 11:53           ` Tim Deegan

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=53E23511.1060606@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.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=xen-devel@lists.xen.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.