From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 4/4] kexec/xen: directly load images images into Xen Date: Sun, 6 Oct 2013 15:55:58 +0100 Message-ID: <525179FE.9030202@citrix.com> References: <1379682998-14279-1-git-send-email-david.vrabel@citrix.com> <1379682998-14279-5-git-send-email-david.vrabel@citrix.com> <20131004213341.GI3626@debian70-amd64.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131004213341.GI3626@debian70-amd64.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: kexec@list.infradead.org, Simon Horman , David Vrabel , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/10/2013 22:33, Daniel Kiper wrote: > > + xch = xc_interface_open(NULL, NULL, 0); > + if (!xch) > + return -1; > + > + type = kexec_flags & KEXEC_TYPE_CRASH; > Why? Could not we unload normal kexec images? type is 0 for normal images and 1 for crash images. This line does not prevent unloading of normal images in the slightest. > >> + ret = xc_kexec_unload(xch, type); >> + >> + xc_interface_close(xch); >> + >> + return ret; >> +} >> + >> @@ -823,7 +830,10 @@ static int my_shutdown(void) >> */ >> static int my_exec(void) >> { >> - reboot(LINUX_REBOOT_CMD_KEXEC); >> + if (xen_present()) >> + xen_kexec_exec(); >> + else >> + reboot(LINUX_REBOOT_CMD_KEXEC); >> /* I have failed if I make it here */ >> fprintf(stderr, "kexec failed: %s\n", >> strerror(errno)); >> @@ -928,6 +938,10 @@ static int kexec_loaded(void) >> char *p; >> char line[3]; >> >> + /* No way to tell if an image is loaded under Xen, assume it is. */ >> + if (xen_present()) >> + return 1; >> + > Why? I think that we should have relevant machanism to do that. > > Please take into account Konrad's comments too > (http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg02364.html). > > Daniel Here I would agree. As we are redefining all the hypercalls, a KEXEC_loaded_status hypercall (or equiv) would certainly not go amis. ~Andrew