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

[Xen-devel] SVM MSRs issue


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.


Xen-devel mailing list



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