[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: "Li, Xin B" <xin.b.li@xxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 27 Sep 2006 14:56:32 +0100
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 27 Sep 2006 06:55:26 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbiF2MEoV3sok4KEdunpAAX8io7RQAGSdMgAADHB8QAAGcR8AAB3oaU
  • Thread-topic: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616

On 27/9/06 14:09, "Li, Xin B" <xin.b.li@xxxxxxxxx> 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@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®.