From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harmandeep Kaur Subject: Re: Error booting Xen Date: Tue, 26 Jan 2016 18:21:25 +0530 Message-ID: References: <569D2A49.1090409@citrix.com> <1453141749.11427.92.camel@citrix.com> <569E4A0102000078000C8917@prv-mh.provo.novell.com> <1453215095.11427.144.camel@citrix.com> <569E5118.4030704@citrix.com> <569E76B102000078000C8C14@prv-mh.provo.novell.com> <569E6C36.3070402@citrix.com> <1453223282.11427.149.camel@citrix.com> <569F6A2102000078000C8F20@prv-mh.provo.novell.com> <1453389242.3116.106.camel@citrix.com> <56A6344C02000078000CAA56@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A6344C02000078000CAA56@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Dario Faggioli , xen-devel@lists.xen.org, Shuai Ruan List-Id: xen-devel@lists.xenproject.org Hi guys, I tried the patch and I am very happy to inform you all that the patch has solved my problem. Now I am able to boot Xen without disabling XSAVE. I have full log of boot at http://paste2.org/gVW0Z9nm (if any one is interested. also "XXX Hello, this is my first mod :)" is printed by my mod, so ignore that one). Thank you guys for your help. Regards, Harman On Mon, Jan 25, 2016 at 7:12 PM, Jan Beulich wrote: >>>> 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 >