[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 17 Mar 2015 15:50:52 +0200
  • Cc: mdontu@xxxxxxxxxxxxxxx, tim@xxxxxxx, JBeulich@xxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 17 Mar 2015 13:49:34 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=0hUKAZZ3KMNQ6KIhcc73LGKh5yK3v2C69jBSaWxzqVDhcK3vWnxaCzoTLtplTISDzss1Q2IxwPyAeZjIoWeOqmtJ4PCLRzpFOuql/xYzkUPBZCcNuPPY5GMFqayXHlvLhmsG9fWb9LYhwHFTWzD4l/KYxUA3pmXYTP7rLgzd5GvjsSEANsCQOoebBTyur/0yRHwq448qnzhTFZZz8Jc/jA9GMj2DUZJ+NYZIThJRm0tNW+YRLIO4iTdL+N5Lx5IHffxg91hZC2foDd+LB7oDPQ+39H0eXpoeFwHm9a12grY+3hSQXZZfBaZFjOB2oOFeAhCLI3Eyz9gf/R5SQz5/LA==; h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 07/11/2014 08:23 PM, Andrew Cooper wrote:
> On 11/07/14 16:43, Razvan Cojocaru wrote:
>> Added support for VMCALL events (the memory introspection library
>> will have the guest trigger VMCALLs, which will then be sent along
>> via the mem_event mechanism).
>>
>> Changes since V1:
>>  - Added a #define and an comment explaining a previous magic
>>    constant.
>>  - Had MEM_EVENT_REASON_VMCALL explicitly not honour
>>    HVMPME_onchangeonly.
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>> ---
>>  xen/arch/x86/hvm/hvm.c          |    9 +++++++++
>>  xen/arch/x86/hvm/vmx/vmx.c      |   18 +++++++++++++++++-
>>  xen/include/asm-x86/hvm/hvm.h   |    1 +
>>  xen/include/public/hvm/params.h |    4 +++-
>>  xen/include/public/mem_event.h  |    5 +++++
>>  5 files changed, 35 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 89a0382..6e86d7c 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -5564,6 +5564,7 @@ long do_hvm_op(unsigned long op, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>              case HVM_PARAM_MEMORY_EVENT_INT3:
>>              case HVM_PARAM_MEMORY_EVENT_SINGLE_STEP:
>>              case HVM_PARAM_MEMORY_EVENT_MSR:
>> +            case HVM_PARAM_MEMORY_EVENT_VMCALL:
>>                  if ( d == current->domain )
>>                  {
>>                      rc = -EPERM;
>> @@ -6199,6 +6200,14 @@ void hvm_memory_event_msr(unsigned long msr, unsigned 
>> long value)
>>                             value, ~value, 1, msr);
>>  }
>>  
>> +void hvm_memory_event_vmcall(unsigned long rip, unsigned long eax)
>> +{
>> +    hvm_memory_event_traps(current->domain->arch.hvm_domain
>> +                             .params[HVM_PARAM_MEMORY_EVENT_VMCALL],
>> +                           MEM_EVENT_REASON_VMCALL,
>> +                           rip, ~rip, 1, eax);
>> +}
>> +
>>  int hvm_memory_event_int3(unsigned long gla) 
>>  {
>>      uint32_t pfec = PFEC_page_present;
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 2caa04a..6c63225 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2879,8 +2879,24 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>      case EXIT_REASON_VMCALL:
>>      {
>>          int rc;
>> +        unsigned long eax = regs->eax;
>> +
>>          HVMTRACE_1D(VMMCALL, regs->eax);
>> -        rc = hvm_do_hypercall(regs);
>> +
>> +        /* Don't send a VMCALL mem_event unless something
>> +         * caused the guests's eax register to contain the
>> +         * VMCALL_EVENT_REQUEST constant. */
>> +        if ( regs->eax != VMCALL_EVENT_REQUEST )
>> +        {
>> +            rc = hvm_do_hypercall(regs);
>> +        }
>> +        else
>> +        {
>> +            hvm_memory_event_vmcall(guest_cpu_user_regs()->eip, eax);
>> +            update_guest_eip();
>> +            break;
>> +        }
> 
> Thinking more about this, it is really a hypercall pretending not to
> be.  It would be better to introduce a real HVMOP_send_mem_event.
> 
> From the point of view of your in-guest agent, it would be a vmcall with
> rax = 34 (hvmop) rdi = $N (send_mem_event subop) rsi = data or pointer
> to struct containing data, depending on how exactly you implement the
> hypercall.
> 
> You would have the bonus of being able to detect errors, e.g. -ENOENT
> for "mem_event not active", get SVM support for free, and not need magic
> numbers, or vendor specific terms like "vmcall" finding their way into
> the Xen public API.

Actually, this only seems to be the case where mode == 8 in
hvm_do_hypercall() (xen/arch/x86/hvm/hvm.c):

4987                      : hvm_hypercall64_table)[eax](rdi, rsi, rdx,
r10, r8, r9);

Otherwise (and this seems to be the case with my Xen build), ebx seems
to be used for the subop:

5033         regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi,
edi, ebp);

So, ebx needs to be $N (send_mem_event subop), not rdi. Is this intended
(rdi in one case and ebx in the other)?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.