Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

["Xu, YongweiX" <yongweix.xu@xxxxxxxxx>]

Hi, David
I have tried to use kexec with upstream xen source(C/S:27758) which has been 
put your patches and didn't not work on Dom0. Step as below:
1. use upstream xen and tools with your patch
2. use kexec-tools with branch "remotes/origin/xen-v6"
3. kexec -l -t multiboot-x86 /boot/xen.gz --module="/boot/vmlinuz-xen 
root=/dev/sda1 o" --module="/boot/initrd-xen.img"
4. kexec -e
The phenomenon was that the kernel didn't change, but the network broke.

Is there any problem in my operation?

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of David Vrabel
> Sent: Wednesday, October 09, 2013 12:55 AM
> To: xen-devel@xxxxxxxxxxxxx
> Cc: Keir Fraser; David Vrabel; Jan Beulich
> Subject: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with
> pv-ops kernels
> 
> The series (for Xen 4.4) improves the kexec hypercall by making Xen 
> responsible
> for loading and relocating the image.  This allows kexec to be usable by 
> pv-ops
> kernels and should allow kexec to be usable from a HVM or PVH privileged
> domain.
> 
> The first patch is a simple clean-up.
> 
> Patch 2 introduces the new ABI.
> 
> Patch 3 and 4 nearly completely reimplement the kexec load, unload and exec
> sub-ops.  The old load_v1 sub-op is then implemented on top of the new code.
> 
> Patch 5 calls the kexec image when dom0 crashes.  This avoids having to alter
> dom0 kernels to do a exec sub-op call on crash -- a SHUTDOWN_crash by dom0
> will trigger the kexec.
> 
> Patches 6 and 7 add the libxc API for the kexec calls.  These have been
> acked-by Ian Campbell already.
> 
> Patch 8 adds a link time check for the size of the relocate code.
> 
> Patch 9 adds myself as the maintainer for kexec in Xen.
> 
> The required patch series for kexec-tools will be posted shortly and are
> available from the xen-v6 branch of:
> 
> http://xenbits.xen.org/gitweb/?p=people/dvrabel/kexec-tools.git;a=summary
> 
> Changes in v9:
> 
> - Update comments to correctly say 4.4.
> - Minor updates the kexec_reloc assembly to improve maintainability a
>   bit.
> 
> Changes in v8:
> 
> - Use #defines for compat ABI structures.
> - Tweak link time check for kexec_reloc.
> 
> Changes in v7:
> 
> - No longer use GUEST_HANDLE_64(), get a uniform ABI by using unions
>   and explicit padding.
> - Only map the segments and not all of RAM.
> - Add a mechanism to create mappings for use by the exec'd image (a
>   segment with a NULL buf handle).
> - Fix a bug where a crash image's code page would by placed at machine
>   address 0 (instead of inside the crash region).
> 
> Changes in v6:
> 
> - Fix double free in KEXEC_load_v1 failure path.
> - Only copy the relocation code and not the whole page.
> - Add myself as the kexec maintainer.
> 
> Changes in v5 (not posted to the list):
> 
> - _rsvd -> _pad in one of the public ABI structures.
> - Fix bug where trailing pages were not zeroed. This fixes loading a
>   64-bit Linux kernel using a more recent version of kexec-tools.
> - Check the relocation code fits into a page at link time.
> 
> Changes in v4:
> 
> - Use paddr_t and page_to_maddr() etc. for portability.
> - Add explicit padding to hypercall structures where required.
> - Minor cleanup of the kexec_reloc assembly.
> - Print a message before exec'ing a crash image.
> - Style fixes (tabs, trailing whitespace) and typos.
> - Fix a bug where using the V1 interface and unloading a image may crash.
> 
> Changes in v3:
> 
> - Provide old struct xen_kexec_load if __XEN_INTERFACE_VERSION__ < 4.3
> - Adjust new struct xen_kexec_load to avoid unnecessary padding.
> - Use domheap pages for the image and control pages.
> - Remove the DBG() macros from the reloc code.
> 
> David
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel