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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel