Li, Xin B
2006-Sep-28 09:33 UTC
RE: [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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Sep-28 09:45 UTC
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@intel.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Sep-28 10:31 UTC
Re: [Xen-devel] Testing status of HVM (Intel VT) on 64bit XENunstable c/s 11616
> 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 :-(Should be properly fixed by -unstable changeset 1637:88418d7f22f. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel