[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
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |