Re: [Xen-devel] lastest xen unstable crash

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.04.12 at 14:23, Francisco Rocha <f.e.liberal-rocha@xxxxxxxxxxxxxxx> 
>>> wrote:
> I have added some prints in the functions you mentioned. Is this what you 
> need? 

Yes.

> These are the new lines in the dmesg, the attached file contains the rest.
> 
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> 
> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 
> guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> 
> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 
> guest_cr4: 00002660 return: 00002660
> (XEN) domain.c:691:d0 @pv_guest_cr4_fixup-start: id=0 hv_cr4: 00002660 -> 
> guest_cr4:00002660
> (XEN) domain.c:707:d0 @pv_guest_cr4_fixup-end: id=0 hv_cr4: 00002660 
> guest_cr4: 00002660 return: 00002660
> (XEN) traps.c:2243:d0 @XSETBV: new_xfeature: 0000000000000007
> (XEN) traps.c:2246:d0 @XSETBV: (v->arch.pv_vcpu.ctrlreg[4] & 
> X86_CR4_OSXSAVE): 0000000000000000

So as far as Xen is concerned, there's not even an attempt from the
Dom0 kernel to set bit 18. That's rather odd given that the only
instance of XSETBV should sit right ahead of the CR4 write. You
may want to verify that this is the case in the kernel binary, and if
so you may need to also add tracing at the kernel side (e.g. in
set_in_cr4()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel