From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 4/4] kexec/xen: directly load images images into Xen Date: Mon, 7 Oct 2013 10:36:19 +0100 Message-ID: <52528093.90005@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: Simon Horman , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/10/13 22:33, Daniel Kiper wrote: > On Fri, Sep 20, 2013 at 02:16:38PM +0100, David Vrabel wrote: >> From: David Vrabel >> >> Xen 4.4 has an improvided kexec hypercall ABI that allows images to be >> loaded and executed without any kernel involvement. Use the API >> provided by libxc to load images when running in a Xen guest. >> >> Support for loading images via the kexec_load syscall in non-upstream >> ("classic") Xen kernels is no longer supported. >> >> Signed-off-by: David Vrabel > > [...] > >> --- /dev/null >> +++ b/kexec/kexec-xen.c [...] >> +int xen_kexec_unload(uint64_t kexec_flags) >> +{ >> + xc_interface *xch; >> + uint8_t type; >> + int ret; >> + >> + 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? This is correct but could be type = kexec_flags & KEXEC_TYPE_CRASH ? KEXEC_TYPE_CRASH : KEXEC_TYPE_DEFAULT for clarity. >> @@ -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. Because it's not needed. There's no point in checking if an image a loaded before trying to exec it because you can just try the exec and have that fail. I'm not going to add a sub-op for this just because one particular tool mistakenly thinks it needs to check in advance. David