Xen devel - Sep 2006 - RE: Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616

>
>>> 11626 has a possible fix for this and at least will print out
>>> some more info
>>> (even on production builds ;-) if the MSR_EFER write fails.
>>> 
>> 
>> Can''t understand your patch, can you explain more?
>> And why it''s a possible fix?
>
>long_mode_do_msr_write() was not taking just the low 32 bits 
>of EAX to form
>the 64-bit MSR value. If the high 32 bits of RAX had garbage 
>then this would
>lead to garbage in the MSR value.
>
My log shows that even in the lower 32 bit of eax, there is still some
garbage value, eax is 0000000000101901, 901 is what we need, but 101 is
garbage, also edx is garbage, should be all 0.

(XEN) trying to set reserved bit in EFER
(XEN) domain_crash_sync called from vmx.c:2268
(XEN) Domain 10 (vcpu#0) crashed on cpu#2:
(XEN) ----[ Xen-3.0-unstable  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    2
(XEN) RIP:    0010:[<000000000010005e>]
(XEN) RFLAGS: 0000000000010046   CONTEXT: hvm
(XEN) rax: 0000000000101901   rbx: 0000000000000000   rcx:
00000000c0000080
(XEN) rdx: 0000000020100800   rsi: 0000000000090000   rdi:
0000000020100800
(XEN) rbp: 0000000000000000   rsp: 00000000001010c0   r8:
0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11:
0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14:
0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000050031   cr4:
00000000000000a0
(XEN) cr3: 00000000001a17a0   cr2: 0000000000000000
(XEN) ds: 0018   es: 0018   fs: 0018   gs: 0018   ss: 0018   cs: 0010

I suspect it''s a gcc version related issue, when using gcc 3.4.3,
it''s
OK, while gcc 4.1.0, we got the error.

-Xin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 27/9/06 14:09, "Li, Xin B" <xin.b.li@intel.com> wrote:
> My log shows that even in the lower 32 bit of eax, there is still some
> garbage value, eax is 0000000000101901, 901 is what we need, but 101 is
> garbage, also edx is garbage, should be all 0.
Since this happens early in HVM guest boot, I suggest adding tracing to
vmx_vmexit_handler() to dump registers on every MSR write. Something like
this early on in the function:
 if ( reason == EXIT_REASON_MSR_WRITE ) {
     printk("regs==%p, guest_regs==%p\n", &regs,
guest_cpu_user_regs());
     show_registers(&regs);
 }

This will let us see if the EAX/EDX are garbage on entry to C code
immediately after VMEXIT.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel