>>> On 21.01.16 at 16:14, wrote: > On Wed, 2016-01-20 at 03:06 -0700, Jan Beulich wrote: >> > > > On 19.01.16 at 20:55, wrote: >> > >> > $ 'addr2line -e xen-syms ffff82d0801c1cce' returns >> > 'xen/xen/arch/x86/xstate.c:387' which again points to >> > xsave. Also, adding 'xsave=0' makes it boot just fine. >> >> Ah, I think I see the issue: We're zeroing the entire save area in >> the fixup code, which will make XRSTORS fault unconditionally. >> Shuai, would you please look into possible ways of fixing this? >> Just setting the compressed flag may not be enough, and falling >> back to plain XRSTOR doesn't seem to be an option either - I'm in >> particular worried that the current model of zeroing everything >> is bogus with the growing number of different components which >> get loaded here. >> >> But of course another question then is why the XRSTORS faults >> in the first place. I guess we'll need a debugging patch to dump >> the full state to understand that. >> > If someone can produce and send such patch, I'm sure Harmandeep will be > happy to give it a try on her hardware. So here you go. Instead of a debugging one, I hope I have at once fixed the issue in a suitable way. Whether we'd like to keep the debugging output we can decide later on. Both patches need to be applied; while the order shouldn't matter, the alignment one is a prereq to the actual change. Jan