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

Re: [Xen-devel] [PATCH RFC 2/9] xen: Optimize introspection access to guest state


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Thu, 03 Jul 2014 11:12:20 +0300
  • Cc: tim@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Thu, 03 Jul 2014 08:11:51 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=FBtKT/u8omusqKn/RGI19ujxStjjAitV1JvTaSZlFDK+WqY3+OQwLuia9NZR3qQBioaYKZ1XGq8l6LqjgWFsoVtxHHG45Vopx2xQ7/nqWLnX8s9g6WxTN57Nt23iUl5rlIOJcQ0xr2iBd1nJTu+ZogNMuUKdybNPlNdQyaQpeTmZ+00G01iLJFJOmyRL3AgGhQg5q0W8XUbvKd/dy8XwU0Tj+8l7G1/p8+LDWYWnle7RQjV8ZM7UqJEv/3UOh1mWbofM29jlbLVCGrDByo2YwxFlicrH/5a/yIavMp0Fk9stOd6gDYpUdfsVOpkk97hxeUcSfqeF57vqzwkcrIKR3A==; h=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/02/2014 06:37 PM, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -6016,6 +6016,38 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
>>      return rc;
>>  }
>>  
>> +static inline void hvm_mem_event_fill_regs(mem_event_request_t *req)
>> +{
>> +    struct cpu_user_regs *regs = guest_cpu_user_regs();
>> +    struct vcpu *v = current;
>> +
>> +    req->regs.rax = regs->eax;
>> +    req->regs.rcx = regs->ecx;
>> +    req->regs.rdx = regs->edx;
>> +    req->regs.rbx = regs->ebx;
>> +    req->regs.rsp = regs->esp;
>> +    req->regs.rbp = regs->ebp;
>> +    req->regs.rsi = regs->esi;
>> +    req->regs.rdi = regs->edi;
>> +
>> +    req->regs.r8  = regs->r8;
>> +    req->regs.r9  = regs->r9;
>> +    req->regs.r10 = regs->r10;
>> +    req->regs.r11 = regs->r11;
>> +    req->regs.r12 = regs->r12;
>> +    req->regs.r13 = regs->r13;
>> +    req->regs.r14 = regs->r14;
>> +    req->regs.r15 = regs->r15;
>> +
>> +    req->regs.rflags = regs->eflags;
>> +    req->regs.rip    = regs->eip;
>> +
>> +    req->regs.msr_efer = v->arch.hvm_vcpu.guest_efer;
>> +    req->regs.cr0 = v->arch.hvm_vcpu.guest_cr[0];
>> +    req->regs.cr3 = v->arch.hvm_vcpu.guest_cr[3];
>> +    req->regs.cr4 = v->arch.hvm_vcpu.guest_cr[4];
>> +}
> 
> This fills far not as many fields as the p2m function further down.
> Why?

That is because hvm_mem_event_fill_regs() is used for events such as CR3
changes or MSR access, and p2m_mem_event_fill_regs() is used for EPT
events, and our application needs full information while handling EPT
callbacks, and not as much for the other events.

Hence I've tried to avoid the unnecessary overhead in that case,
thinking that if somebody needed those values, they would be added then.

>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -425,6 +425,7 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
>> hvm_hw_cpu *c)
>>      c->cr4 = v->arch.hvm_vcpu.guest_cr[4];
>>  
>>      c->msr_efer = v->arch.hvm_vcpu.guest_efer;
>> +    c->guest_x86_mode = vmx_guest_x86_mode(v);
> 
> This seems unrelated and/or lacking an SVM counterpart.

Yes, it does lack a SVM counterpart. Is SVM support required for acceptance?

It is, however, not unrelated. Our application required that
information, and it is cached in the mem_event (or am I missing something?).


Thanks,
Razvan Cojocaru

_______________________________________________
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®.