[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] x86/AMD: Nested hvm crashes in 4.3

On Thu, Jun 27, 2013 at 11:24 AM, Suravee Suthikulpanit
<suravee.suthikulpanit@xxxxxxx> wrote:
> On 6/27/2013 5:08 AM, Jan Beulich wrote:
>>>>> On 27.06.13 at 11:20, Suravee Suthikulpanit
>>>>> <suravee.suthikulpanit@xxxxxxx> wrote:
>>> On 6/27/2013 3:22 AM, Jan Beulich wrote:
>>>>>>> On 27.06.13 at 02:24, Suravee Suthikulanit
>>>>>>> <suravee.suthikulpanit@xxxxxxx> 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 <jbeulich@xxxxxxxx>
>>>>> 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 <jbeulich@xxxxxxxx>
>>>>>        Acked-by: Keir Fraser <keir@xxxxxxx>
>>>> 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"?

*If* you had had >5TiB, then you would have crashed even without this patch.

The purpose of the patch is to make it so that if there is a bug that
will crash for >5TiB, then it will *also* crash for <5TiB.  Since the
vast majority of people have <5TiB of RAM, this results in better
testing coverage for those with >5TiB of RAM.

On production systems, we want it to work as often as possible, so
this test is disabled when debug=n, which is the default for released
versions of Xen.  But the development branch we very much want to find
bugs, so during development, we set debug=y by default.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.