From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953Ab2GJTIb (ORCPT ); Tue, 10 Jul 2012 15:08:31 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:54325 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042Ab2GJTIa (ORCPT ); Tue, 10 Jul 2012 15:08:30 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 10 Jul 2012 20:08:15 +0100 Subject: Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot From: Keir Fraser To: Olaf Hering , Konrad Rzeszutek Wilk CC: Jan Beulich , , , , Daniel Kiper Message-ID: Thread-Topic: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot Thread-Index: Ac1ez1uAufzi7sIrtEiO9chG7TXVoQ== In-Reply-To: <20120710180953.GB20075@aepfle.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/2012 19:09, "Olaf Hering" wrote: >>> Are there more shared areas or is it just the shared info page? >>> >>>> And I am kind of worried that moving it to the .data section won't >>>> be completly safe - as the decompressor might blow away that part too. >>> >>> The decompressor may just clear the area, but since there is no way to >>> tell where the shared pages are its always a risk to allocate them at >>> compile time. >> >> Yeah, and with the hypervisor potentially still updating the "old" >> MFN before the new kernel has registered the new MFN, we can end up >> corrupting the new kernel. Ouch. >> >> Would all of these issues disappear if the hypervisor had a hypercall >> that would stop updating the shared info? or just deregister the MFN? >> What if you ripped the GMFN out using 'decrease_reservation' hypercall? >> Would that eliminate the pesky GMFN? > > I'm not sure, most likely the gfn will just disappear from the guest, > like a ballooned page disappears. Accessing it will likely cause a > crash. Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. If you do map it over the top of an existing RAM page, you will have to repopulate that RAM page before kexec, using populate_physmap hypercall. The good news is that the populate_physmap hypercall will have the side effect of unmapping the shared-info page, reayd to be mapped wherever the new kernel would like it to reside :) Hope this clears up some of the confusion. ;) -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot Date: Tue, 10 Jul 2012 20:08:15 +0100 Message-ID: References: <20120710180953.GB20075@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120710180953.GB20075@aepfle.de> Sender: linux-kernel-owner@vger.kernel.org To: Olaf Hering , Konrad Rzeszutek Wilk Cc: Jan Beulich , xen-devel@lists.xensource.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Kiper List-Id: xen-devel@lists.xenproject.org On 10/07/2012 19:09, "Olaf Hering" wrote: >>> Are there more shared areas or is it just the shared info page? >>> >>>> And I am kind of worried that moving it to the .data section won't >>>> be completly safe - as the decompressor might blow away that part too. >>> >>> The decompressor may just clear the area, but since there is no way to >>> tell where the shared pages are its always a risk to allocate them at >>> compile time. >> >> Yeah, and with the hypervisor potentially still updating the "old" >> MFN before the new kernel has registered the new MFN, we can end up >> corrupting the new kernel. Ouch. >> >> Would all of these issues disappear if the hypervisor had a hypercall >> that would stop updating the shared info? or just deregister the MFN? >> What if you ripped the GMFN out using 'decrease_reservation' hypercall? >> Would that eliminate the pesky GMFN? > > I'm not sure, most likely the gfn will just disappear from the guest, > like a ballooned page disappears. Accessing it will likely cause a > crash. Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. If you do map it over the top of an existing RAM page, you will have to repopulate that RAM page before kexec, using populate_physmap hypercall. The good news is that the populate_physmap hypercall will have the side effect of unmapping the shared-info page, reayd to be mapped wherever the new kernel would like it to reside :) Hope this clears up some of the confusion. ;) -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-we0-f177.google.com ([74.125.82.177]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1Sofnf-0001eE-6E for kexec@lists.infradead.org; Tue, 10 Jul 2012 19:08:44 +0000 Received: by weyr3 with SMTP id r3so248623wey.36 for ; Tue, 10 Jul 2012 12:08:29 -0700 (PDT) Date: Tue, 10 Jul 2012 20:08:15 +0100 Subject: Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot From: Keir Fraser Message-ID: In-Reply-To: <20120710180953.GB20075@aepfle.de> Mime-version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Olaf Hering , Konrad Rzeszutek Wilk Cc: Daniel Kiper , xen-devel@lists.xensource.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Jan Beulich On 10/07/2012 19:09, "Olaf Hering" wrote: >>> Are there more shared areas or is it just the shared info page? >>> >>>> And I am kind of worried that moving it to the .data section won't >>>> be completly safe - as the decompressor might blow away that part too. >>> >>> The decompressor may just clear the area, but since there is no way to >>> tell where the shared pages are its always a risk to allocate them at >>> compile time. >> >> Yeah, and with the hypervisor potentially still updating the "old" >> MFN before the new kernel has registered the new MFN, we can end up >> corrupting the new kernel. Ouch. >> >> Would all of these issues disappear if the hypervisor had a hypercall >> that would stop updating the shared info? or just deregister the MFN? >> What if you ripped the GMFN out using 'decrease_reservation' hypercall? >> Would that eliminate the pesky GMFN? > > I'm not sure, most likely the gfn will just disappear from the guest, > like a ballooned page disappears. Accessing it will likely cause a > crash. Best thing to do, is possible, is map the shared-info page in the xen-platform pci device's BAR memory range. Then it will not conflict with any RAM. If you do map it over the top of an existing RAM page, you will have to repopulate that RAM page before kexec, using populate_physmap hypercall. The good news is that the populate_physmap hypercall will have the side effect of unmapping the shared-info page, reayd to be mapped wherever the new kernel would like it to reside :) Hope this clears up some of the confusion. ;) -- Keir _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec