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

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


  • To: "Steven Hand" <Steven.Hand@xxxxxxxxxxxx>
  • From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
  • Date: Thu, 28 Sep 2006 17:33:01 +0800
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 28 Sep 2006 02:33:46 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbiX/dCl47hhqk4QlmBoVzG91vWrQAgKhIA
  • Thread-topic: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616

 >
>Hmm.
>
>So this seems to be a compiler/linker issue - any chance you can post 
>a URL for the xen-syms for a 'broken' case? 
>
>(i.e. a non-debug build built using gcc 4.0.0 or 4.1.0 or similar)


The gcc bug happnes in long_mode_do_msr_read, Xiaohui told me the regs
value (eax = 0x00101901, edx = 0x20100800) long_mode_do_msr_write was
trying to wirte to EFER seems like the result from cpuid instruction, so
I suspect after long_mode_do_msr_read, eax and edx are not correctly
updated.

And after checking the assembly code, it shows that,
long_mode_do_msr_read stores the result of EFER in ecx, but it doesn't
use it to update guest regs.

Now, how can we fix it?

Code rearrangement may fix it, but we don't know when it will come back
again :-(

-Xin

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


 


Rackspace

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