This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Li, Xin B" <xin.b.li@xxxxxxxxx>, Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 28 Sep 2006 10:45:12 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Sep 2006 02:44:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <B30DA1341B0CFA4893EF8A36B40B5C5D302031@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbiX/dCl47hhqk4QlmBoVzG91vWrQAgKhIAAACK0s4=
Thread-topic: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616
User-agent: Microsoft-Entourage/
This is probably because vmx_vmexit_handler() takes its regs argument 'by
value'. I expect the compiler has therefore decided it can optimise away
some writes to that argument because the result of the write is not used
inside vmx_vmexit_handler and it assumes the caller will discard the
argument on return. Hence why this went away with a debug build -- we
optimise less aggressively.

Either the writeback needs to happen explicitly via
guest_cpu_user_regs()-returned pointer. Or, more simply, we change the
vmx_vmexit_handler interface. It'll have negligible cost to pass a pointer.

 -- Keir

On 28/9/06 10:33, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:

> 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 :-(

Xen-devel mailing list