|
[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 |