nestedhvm: xentrace support
PATCH 1/1 nestedhvm: xentrace support
Tracing facility for nested virtualization
Signature · 6 lines
---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632
Tracing facility for nested virtualization
tools/xentrace/formats +4 -1
@@ -35,9 +35,12 @@ 0x0002800d CPU%(cpu)d %(tsc)d (+%(relt 0x0002800e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) switch_infprev [ old_domid = 0x%(1)08x, runtime = %(2)d ] 0x0002800f CPU%(cpu)d %(tsc)d (+%(reltsc)8d) switch_infnext [ new_domid = 0x%(1)08x, time = %(2)d, r_time = %(3)d ] -0x00081001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMENTRY +0x00081001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMENTRY [ rIP = 0x%(1)08x ] 0x00081002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMEXIT [ exitcode = 0x%(1)08x, rIP = 0x%(2)08x ] 0x00081102 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) VMEXIT [ exitcode = 0x%(1)08x, rIP = 0x%(3)08x%(2)08x ] +0x00081401 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) nVMENTRY [ rIP = 0x%(1)08x ] +0x00081402 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) nVMEXIT [ exitcode = 0x%(1)08x, rIP = 0x%(2)08x ] +0x00081502 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) nVMEXIT [ exitcode = 0x%(1)08x, rIP = 0x%(3)08x%(2)08x ] 0x00082001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) PF_XEN [ errorcode = 0x%(2)02x, virt = 0x%(1)08x ] 0x00082101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) PF_XEN [ errorcode = 0x%(3)02x, virt = 0x%(2)08x%(1)08x ] 0x00082002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) PF_INJECT [ errorcode = 0x%(1)02x, virt = 0x%(2)08x ]
xen/arch/x86/hvm/svm/entry.S +1 -1
@@ -178,7 +178,7 @@ svm_stgi_label: jmp svm_asm_do_resume .Lsvm_trace: - call svm_trace_vmentry + call_with_regs(svm_trace_vmentry) jmp .Lsvm_trace_done .Lsvm_nsvm_no_p2m:
xen/arch/x86/hvm/svm/svm.c +19 -11
@@ -1679,6 +1679,20 @@ asmlinkage void svm_vmexit_handler(struc exit_reason = vmcb->exitcode; +if ( tb_init_done ) { +if (hvm_long_mode_enabled (v) ) { +HVMTRACE_ND (VMEXIT64 | (TRC_HVM_NESTEDFLAG * vcpu_guestmode), +1 /*cycles*/ ,3 , exit_reason, + (uint32_t )regs->eip, (uint32_t )((uint64_t )regs->eip >>32 ), +0 ,0 ,0 ); + }else { +HVMTRACE_ND (VMEXIT | (TRC_HVM_NESTEDFLAG * vcpu_guestmode), +1 /*cycles*/ ,2 , exit_reason, + (uint32_t )regs->eip, +0 ,0 ,0 ,0 ); + } + } +if ( vcpu_guestmode ) {enum nestedhvm_vmexits nsret;struct nestedvcpu *nv = &vcpu_nestedhvm (v);
@@ -1739,15 +1753,6 @@ asmlinkage void svm_vmexit_handler(struc } } -if (hvm_long_mode_enabled (v) ) -HVMTRACE_ND (VMEXIT64 ,1 /*cycles*/ ,3 , exit_reason, - (uint32_t )regs->eip, (uint32_t )((uint64_t )regs->eip >>32 ), -0 ,0 ,0 ); -else -HVMTRACE_ND (VMEXIT ,1 /*cycles*/ ,2 , exit_reason, - (uint32_t )regs->eip, -0 ,0 ,0 ,0 ); -if (unlikely (exit_reason ==VMEXIT_INVALID ) ) {svm_vmcb_dump (__func__, vmcb);
@@ -2025,9 +2030,12 @@ asmlinkage void svm_vmexit_handler(strucvmcb_set_vintr (vmcb, intr); } -asmlinkage void svm_trace_vmentry(void) +asmlinkage void svm_trace_vmentry(struct cpu_user_regs *regs) { -HVMTRACE_ND (VMENTRY ,1 /*cycles*/ ,0 ,0 ,0 ,0 ,0 ,0 ,0 ); +struct vcpu *v = current; +HVMTRACE_ND (VMENTRY | (TRC_HVM_NESTEDFLAG * !!(nestedhvm_vcpu_in_guestmode (v))), +1 /*cycles*/ ,1 , regs->rip, +0 ,0 ,0 ,0 ,0 ); }/*
xen/include/public/trace.h +1 -0
@@ -123,6 +123,7 @@#define TRC_SHADOW_RESYNC_ONLY (TRC_SHADOW + 15)/* trace events per subclass */ +#define TRC_HVM_NESTEDFLAG (0x400)#define TRC_HVM_VMENTRY (TRC_HVM_ENTRYEXIT + 0x01)#define TRC_HVM_VMEXIT (TRC_HVM_ENTRYEXIT + 0x02)#define TRC_HVM_VMEXIT64 (TRC_HVM_ENTRYEXIT + TRC_64_FLAG + 0x02)
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines · Christoph Egger
Tracing facility for nested virtualization
Signed-off-by Christoph Egger <[email protected]>
I fixed this, by adding an extra argument to HVMTRACE_ND() -- it wasn't really valid to make the first argument be an arbitarry C expression, due to argument concatenation that then went on in the macro body.
I also discarded the change to the VMENTRY record to add the guest EIP. Firstly, it was incomplete, because it did not handle 64-bit RIP. Secondly, it does not logically belong in this patch. Finally, George may have a reason for not including RIP in VMENTRY records (e.g., not that useful compared with the extra space taken up in trace records). So you'd need to submit a new patch and get an Ack from George (who is currently on holiday).
-- Keir
Quoted 10 lines · Keir Fraser
Quoted 4 lines · Christoph Egger
Tracing facility for nested virtualization
Signed-off-by Christoph Egger<[email protected]>I fixed this, by adding an extra argument to
HVMTRACE_ND()-- it wasn't really valid to make the first argument be an arbitarry C expression, due to argument concatenation that then went on in the macro body.
Thanks for your effort.
Quoted 6 lines
I also discarded the change to the VMENTRY record to add the guest EIP. Firstly, it was incomplete, because it did not handle 64-bit RIP. Secondly, it does not logically belong in this patch. Finally, George may have a reason for not including RIP in VMENTRY records (e.g., not that useful compared with the extra space taken up in trace records). So you'd need to submit a new patch and get an Ack from George (who is currently on holiday).
Ok. If he has one I would like to know it.
For nested virtualization it is at least good debugging information to see if the l2 guest loops somewhere or not.
Christoph
Signature · 6 lines
---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632
Quoted 10 lines · Christoph Egger
Quoted 6 lines
I also discarded the change to the VMENTRY record to add the guest EIP. Firstly, it was incomplete, because it did not handle 64-bit RIP. Secondly, it does not logically belong in this patch. Finally, George may have a reason for not including RIP in VMENTRY records (e.g., not that useful compared with the extra space taken up in trace records). So you'd need to submit a new patch and get an Ack from George (who is currently on holiday).
Ok. If he has one I would like to know it.
For nested virtualization it is at least good debugging information to see if the l2 guest loops somewhere or not.
He might at least agree to it in the L2 case only. Anyhow, that's his call not mine.
-- Keir
Quoted 5 lines · Christoph Egger
Quoted 5 lines
Finally, George may have a
reason for not including RIP in VMENTRY records (e.g., not that useful compared with the extra space taken up in trace records). So you'd need to submit a new patch and get an Ack from George (who is currently on holiday).
Yeah, the general principle is just to not log duplicate information, or information which can be inferred. VMENTRY logs happen a *lot*, and so a small change has a non-negligible impact on trace size. To this point, I haven't needed the RIP on VMENTRY, since having it on VMEXIT is generally sufficient.
Quoted 3 lines
Ok. If he has one I would like to know it.
For nested virtualization it is at least good debugging information to see if the l2 guest loops somewhere or not.
Can't you get this information from looking at the RIP on the corresponding VMEXIT?
-George