From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: x86/AMD: Nested hvm crashes in 4.3 Date: Thu, 27 Jun 2013 05:24:44 -0500 Message-ID: <51CC12EC.7050608@amd.com> References: <51CB863B.6020405@amd.com> <51CC125E02000078000E10CE@nat28.tlf.novell.com> <51CC03C9.60800@amd.com> <51CC2B2702000078000E1178@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51CC2B2702000078000E1178@nat28.tlf.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: Keir Fraser , xen-devel , Jacob Shin , Sherry Hurwitz List-Id: xen-devel@lists.xenproject.org On 6/27/2013 5:08 AM, Jan Beulich wrote: >>>> On 27.06.13 at 11:20, Suravee Suthikulpanit wrote: >> On 6/27/2013 3:22 AM, Jan Beulich wrote: >>>>>> On 27.06.13 at 02:24, Suravee Suthikulanit wrote: >>>> I have found an issue in where the system crash right when I start >>>> another HVM guest inside an HVM guest. I have traced back to the patch >>>> which the issue started. >>>> >>>> commit f1bde87fc08ce8c818a1640a8fe4765d48923091 >>>> Author: Jan Beulich >>>> Date: Fri Feb 8 11:06:04 2013 +0100 >>>> >>>> x86: debugging code for testing 16Tb support on smaller memory systems >>>> >>>> Signed-off-by: Jan Beulich >>>> Acked-by: Keir Fraser >>> We had issues exposed by this patch before, but any such issue >>> would just have been masked before that patch (and would >>> surface on a system with more than 5Tb of memory anyway). >> The system I am having the issue has 48GB of memory. > Which is why you're seeing the problem only with the debugging > code enabled. Is the "debugging" enabled by default? I didn't specify any debug when building. How can I check and disable debugging? > (And of course I didn't really expect you to have > tried this on a huge memory system - they're just too rare still > for this to be likely.) > >>> So it is very unlikely for the patch itself to be at fault. >> I have traced the issue and found that the system crashing starts from this >> commit id and onward. >> (i.e. The system does not crash with commit id >> ed759d20249197cf87b338ff0ed328052ca3b8e7) >> So, I am still believe that this patch has somehow triggered the issue. > As said - I'm pretty certain this merely unmasked an already > lurking issue. I'm not quite sure what you meant here. Are you saying that this "crashing" is a known issue? > And that's what the purpose of that patch is. This patch is crashing the system. What do you mean by "And that's what the purpose of that patch is"? Suravee > > Jan > >