[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] SVM MSRs issue
Hello, While testing MSR vm_events, we've come accross some puzzling behaviour while trying to follow the guest's MSR_LSTAR: it starts out as zero, then it changes value before the first MSR write event, without going through svm_msr_write_intercept(). The culprit seems to be a svm_vmsave_pa() call, coming though this callstack: (XEN) Xen call trace: (XEN) [<ffff82d080310578>] svm.c#svm_sync_vmcb+0xa5/0xb4 (XEN) [<ffff82d0803105f1>] svm.c#svm_get_segment_register+0x6a/0x12b (XEN) [<ffff82d0802f550c>] hvm_get_segment_register+0x19/0xed (XEN) [<ffff82d0802f57f8>] hvm.c#hvm_save_cpu_ctxt+0x218/0x4ef (XEN) [<ffff82d080302603>] hvm_save_one+0xcb/0x249 (XEN) [<ffff82d080272f84>] arch_do_domctl+0x89f/0x26c7 (XEN) [<ffff82d080206c9e>] do_domctl+0x17c0/0x1be4 (XEN) [<ffff82d08036f371>] pv_hypercall+0x1f4/0x440 (XEN) [<ffff82d080375855>] x86_64/entry.S#test_all_events+0/0x30 From what I can tell, this is effectively a plain VMSAVE: 36 static inline void svm_vmsave_pa(paddr_t vmcb) 37 { 38 asm volatile ( 39 ".byte 0x0f,0x01,0xdb" /* vmsave */ 40 : : "a" (vmcb) : "memory" ); 41 } and using GNU Linux' rdmsr, it would appear that the rogue value is a _host_ MSR_LSTAR value. So at least sometimes, the above callstack overwrites v->vmcb values - specifically when we're in the host's context. We're trying to understand what the best fix would be here. Suggestions from the SVM maintainers are appreciated. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |