From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: Re: [PATCH 05/10] kexec: extend hypercall with improved load/unload ops Date: Tue, 25 Jun 2013 20:52:19 +0200 Message-ID: <20130625185219.GA10322@debian70-amd64.local.net-space.pl> References: <1372095741-27012-1-git-send-email-david.vrabel@citrix.com> <1372095741-27012-6-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1372095741-27012-6-git-send-email-david.vrabel@citrix.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: David Vrabel Cc: Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Mon, Jun 24, 2013 at 06:42:16PM +0100, David Vrabel wrote: > From: David Vrabel > > In the existing kexec hypercall, the load and unload ops depend on > internals of the Linux kernel (the page list and code page provided by > the kernel). The code page is used to transition between Xen context > and the image so using kernel code doesn't make sense and will not > work for PVH guests. > > Add replacement KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload ops > that no longer require a code page to be provided by the guest -- Xen > now provides the code for calling the image directly. > > The new load op looks similar to the Linux kexec_load system call and > allows the guest to provide the image data to be loaded. The guest > specifies the architecture of the image which may be a 32-bit subarch > of the hypervisor's architecture (i.e., an EM_386 image on an > EM_X86_64 hypervisor). > > The toolstack can now load images without kernel involvement. This is > required for supporting kexec when using a dom0 with an upstream > kernel. > > Crash images are copied directly into the crash region on load. > Default images are copied into domheap pages and a list of source and > destination machine addresses is created. This is list is used in > kexec_reloc() to relocate the image to its destination. > > The old load and unload sub-ops are still available (as > KEXEC_CMD_load_v1 and KEXEC_CMD_unload_v1) and are implemented on top > of the new infrastructure. > > Signed-off-by: David Vrabel > Reviewed-by: Daniel Kiper > Tested-by: Daniel Kiper [...] > diff --git a/xen/arch/x86/x86_64/kexec_reloc.S b/xen/arch/x86/x86_64/kexec_reloc.S > new file mode 100644 > index 0000000..135cbcd > --- /dev/null > +++ b/xen/arch/x86/x86_64/kexec_reloc.S [...] > + .globl __kexec_reloc_size > + .set __kexec_reloc_size, . - kexec_reloc > + .globl kexec_reloc_size > +kexec_reloc_size: > + .quad __kexec_reloc_size Why do you define two variables to store the same value? Why quad not long? I think that you could do that: .globl kexec_reloc_size /* Personaly I prefer do this at the beginning of S file. */ kexec_reloc_size: .long . - xen_relocate_kernel It should work for C files and linker script. Daniel