From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 0/3] Early use of boot service memory Date: Fri, 15 Nov 2013 11:16:25 -0800 Message-ID: <52867309.4040406@zytor.com> References: <20131114180455.GA32212@anatevka.fc.hp.com> <20131115005049.GJ5116@anatevka.fc.hp.com> <20131115062417.GB9237@gmail.com> <5285C639.5040203@zytor.com> <20131115140738.GB6637@redhat.com> <52865CA1.5020309@zytor.com> <20131115183002.GE6637@redhat.com> <52866C0D.3050006@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52866C0D.3050006@zytor.com> Sender: owner-linux-mm@kvack.org To: Vivek Goyal Cc: Yinghai Lu , Ingo Molnar , jerry.hoemann@hp.com, Pekka Enberg , Rob Landley , Thomas Gleixner , Ingo Molnar , x86 maintainers , Matt Fleming , Andrew Morton , "list@ebiederm.org:DOCUMENTATION" , "list@ebiederm.org:MEMORY MANAGEMENT" , linux-efi@vger.kernel.org, LKML List-Id: linux-efi@vger.kernel.org On 11/15/2013 10:46 AM, H. Peter Anvin wrote: > On 11/15/2013 10:30 AM, Vivek Goyal wrote: >> >> I agree taking assistance of hypervisor should be useful. >> >> One reason we use kdump for VM too because it makes life simple. There >> is no difference in how we configure, start and manage crash dumps >> in baremetal or inside VM. And in practice have not heard of lot of >> failures of kdump in VM environment. >> >> So while reliability remains a theoritical concern, in practice it >> has not been a real concern and that's one reason I think we have >> not seen a major push for alternative method in VM environment. >> > > Another reason, again, is that it doesn't sit on all that memory. > This led me to a potentially interesting idea. If we can tell the hypervisor about which memory blocks belong to kdump, we can still use kdump in its current form with only a few hypervisor calls thrown in. One set of calls would mark memory ranges as belonging to kdump. This would (a) make them protected, and (b) tell the hypervisor that these memory ranges will not be accessed and don't need to occupy physical RAM. On a crash, we would them execute another hypercall to reanimate the kdump areas. Since this is a once-in-a-lifetime (literally) event, this can be arbitrarily slow. This would only require a small number of hypercalls inserted into already existing code paths, and provide most of the benefit of hypervisor-assisted crash dumping. -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753292Ab3KOTQ6 (ORCPT ); Fri, 15 Nov 2013 14:16:58 -0500 Received: from terminus.zytor.com ([198.137.202.10]:57947 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751566Ab3KOTQv (ORCPT ); Fri, 15 Nov 2013 14:16:51 -0500 Message-ID: <52867309.4040406@zytor.com> Date: Fri, 15 Nov 2013 11:16:25 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Vivek Goyal CC: Yinghai Lu , Ingo Molnar , jerry.hoemann@hp.com, Pekka Enberg , Rob Landley , Thomas Gleixner , Ingo Molnar , x86 maintainers , Matt Fleming , Andrew Morton , "list@ebiederm.org:DOCUMENTATION" , "list@ebiederm.org:MEMORY MANAGEMENT" , linux-efi@vger.kernel.org, LKML Subject: Re: [PATCH 0/3] Early use of boot service memory References: <20131114180455.GA32212@anatevka.fc.hp.com> <20131115005049.GJ5116@anatevka.fc.hp.com> <20131115062417.GB9237@gmail.com> <5285C639.5040203@zytor.com> <20131115140738.GB6637@redhat.com> <52865CA1.5020309@zytor.com> <20131115183002.GE6637@redhat.com> <52866C0D.3050006@zytor.com> In-Reply-To: <52866C0D.3050006@zytor.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/2013 10:46 AM, H. Peter Anvin wrote: > On 11/15/2013 10:30 AM, Vivek Goyal wrote: >> >> I agree taking assistance of hypervisor should be useful. >> >> One reason we use kdump for VM too because it makes life simple. There >> is no difference in how we configure, start and manage crash dumps >> in baremetal or inside VM. And in practice have not heard of lot of >> failures of kdump in VM environment. >> >> So while reliability remains a theoritical concern, in practice it >> has not been a real concern and that's one reason I think we have >> not seen a major push for alternative method in VM environment. >> > > Another reason, again, is that it doesn't sit on all that memory. > This led me to a potentially interesting idea. If we can tell the hypervisor about which memory blocks belong to kdump, we can still use kdump in its current form with only a few hypervisor calls thrown in. One set of calls would mark memory ranges as belonging to kdump. This would (a) make them protected, and (b) tell the hypervisor that these memory ranges will not be accessed and don't need to occupy physical RAM. On a crash, we would them execute another hypercall to reanimate the kdump areas. Since this is a once-in-a-lifetime (literally) event, this can be arbitrarily slow. This would only require a small number of hypercalls inserted into already existing code paths, and provide most of the benefit of hypervisor-assisted crash dumping. -hpa