From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: PVH update.... Date: Thu, 10 Jan 2013 17:11:55 -0800 Message-ID: <20130110171155.1cf7febe@mantra.us.oracle.com> References: <20130109182059.159ddd03@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On Thu, 10 Jan 2013 07:34:27 +0000 Keir Fraser wrote: > On 10/01/2013 02:20, "Mukesh Rathor" wrote: > > This one's not rocket science, Mukesh. The hypervisor stack is 8kB, > and construct_dom0() is trying to allocate a stack frame bigger than > 8kB. Debug builds enforce the 8kB limit with guard pages. You will > actually be crashing on the first stack writing instruction after the > subq, but double fault is imprecise (in fact reported cs:eip is > undefined for a double fault). Thanks Keir. Of course that was my first thought, and I tried confirming it with debug code in PF handler. When I noticed PF was not happening, I started to think it must be something else combined with the fact that the subq man page doesnt' say anything about RSP special case, and it's just decrementing it, and not accessing it. Anyways, the whole x86 is a rocket to me :)... > You're allocating a ridiculously big local variable on > construct_dom0's stack. So just don't do that. Yup, I accidentally was allocating a large char array on stack. Fixed. Thanks, Mukesh