David Vrabel
2013-Apr-16 17:13 UTC
[PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
The series 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. This has now missed the code freeze deadline but could it be considered for 4.3 anyway? kexec isn''t a core piece of functionality and I see minimal risk of introducing regressions to Xen as a whole with this series. The first patch is a simple clean-up. The second patch allows hypercall structures to be ABI compatible between 32- and 64-bit guests (by reusing stuff present for domctls and sysctls). This seems better than having to keep adding compat handling for new hypercalls etc. Patch 3 introduces the new ABI. Patch 4 and 5 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 6 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 7 and 8 add the libxc API for the kexec calls. These have been acked-by Ian Campbell already. The required patch series for kexec-tools have previously been posted and this series has been rebased on the latest kexec-tools and is available from the xen-v3 branch of: http://xenbits.xen.org/gitweb/?p=people/dvrabel/kexec-tools.git;a=summary Changes since v3: - 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 since v2: - 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
Daniel Kiper
2013-Apr-17 12:34 UTC
Re: [PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote:> The series 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. > > This has now missed the code freeze deadline but could it be > considered for 4.3 anyway? kexec isn''t a core piece of functionality > and I see minimal risk of introducing regressions to Xen as a whole > with this series. > > The first patch is a simple clean-up. > > The second patch allows hypercall structures to be ABI compatible > between 32- and 64-bit guests (by reusing stuff present for domctls > and sysctls). This seems better than having to keep adding compat > handling for new hypercalls etc. > > Patch 3 introduces the new ABI. > > Patch 4 and 5 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 6 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 7 and 8 add the libxc API for the kexec calls. These have > been acked-by Ian Campbell already. > > The required patch series for kexec-tools have previously been posted > and this series has been rebased on the latest kexec-tools and is > available from the xen-v3 branch of: > > http://xenbits.xen.org/gitweb/?p=people/dvrabel/kexec-tools.git;a=summarykexec -e still does not work. I see in my console: I''m in purgatory sha256 digests do not match :( ... Daniel
David Vrabel
2013-Apr-17 14:15 UTC
Re: [PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
On 17/04/13 13:34, Daniel Kiper wrote:> On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote: >> >> The required patch series for kexec-tools have previously been posted >> and this series has been rebased on the latest kexec-tools and is >> available from the xen-v3 branch of: >> >> http://xenbits.xen.org/gitweb/?p=people/dvrabel/kexec-tools.git;a=summary > > kexec -e still does not work. I see in my console: > > I''m in purgatory > sha256 digests do not match :(Some recent updates to kexec-tools has broken this. If you use the xen-v2 branch of kexec-tools it should be fine. I suspect the recent change to load 64-bit images about 4G but my unit testing says images above 4G work fine. Working out what''s wrong here is going to push the final patches even further into the code freeze so this will now be a Xen 4.4 candidate. David
Daniel Kiper
2013-Apr-17 14:53 UTC
Re: [PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
On Wed, Apr 17, 2013 at 03:15:39PM +0100, David Vrabel wrote:> On 17/04/13 13:34, Daniel Kiper wrote: > > On Tue, Apr 16, 2013 at 06:13:02PM +0100, David Vrabel wrote: > >> > >> The required patch series for kexec-tools have previously been posted > >> and this series has been rebased on the latest kexec-tools and is > >> available from the xen-v3 branch of: > >> > >> http://xenbits.xen.org/gitweb/?p=people/dvrabel/kexec-tools.git;a=summary > > > > kexec -e still does not work. I see in my console: > > > > I''m in purgatory > > sha256 digests do not match :( > > Some recent updates to kexec-tools has broken this. If you use the > xen-v2 branch of kexec-tools it should be fine.xen-v2 works without any issue...> I suspect the recent change to load 64-bit images about 4G but my unit > testing says images above 4G work fine. > > Working out what''s wrong here is going to push the final patches even > further into the code freeze so this will now be a Xen 4.4 candidate.If you wish I could put my Reviewed-by and Tested-by for all Xen patches. But please add this fix for memcpy() for patch 5 and repost all Xen patches. However, I could not add Reviewed-by and Tested-by for kexec-tools patches until all problems will be solved. Daniel
David Vrabel
2013-Apr-18 17:38 UTC
Re: [PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
On 17/04/13 13:34, Daniel Kiper wrote:> > kexec -e still does not work. I see in my console: > > I''m in purgatory > sha256 digests do not match :(I have now fixed this. Xen was not probably zeroing out trailing pages (only partial pages) when loading a default image (crash was fine). The kernel does this by allocating and clearing pages and then relocating these as normal but it''s wasteful to allocate a bunch of empty pages so I added a IND_ZERO entry type for the indirection pages which gets the relocation code to zero the destination. See the kexec-v5 branch at: http://xenbits.xen.org/gitweb/?p=people/dvrabel/xen.git;a=summary I shall repost this series again once the 4.4 development window is open. --- a/xen/arch/x86/x86_64/kexec_reloc.S +++ b/xen/arch/x86/x86_64/kexec_reloc.S @@ -130,13 +130,18 @@ relocate_pages: jmp 3f 2: testq $0x8, %rcx /* is it the source indicator? */ - jz 0b /* Ignore it otherwise */ + jz 2f movq %rcx, %rsi /* For ever source page do a copy */ andq $0xfffffffffffff000, %rsi - movq $512, %rcx rep movsq - + jmp 0b +2: + testq $0x10, %rcx /* is it the zero indicator? */ + jz 0b /* Ignore it otherwise */ + movq $512, %rcx /* Zero the destination page. */ + xorq %rax, %rax + rep stosq jmp 0b 3: ret diff --git a/xen/common/kimage.c b/xen/common/kimage.c index 86261ca..1cc0ef7 100644 --- a/xen/common/kimage.c +++ b/xen/common/kimage.c @@ -661,7 +661,7 @@ static int kimage_load_normal_segment(struct kexec_image *image, { unsigned long to_copy; unsigned long src_offset; - paddr_t dest; + paddr_t dest, end; int ret; to_copy = segment->buf_size; @@ -675,15 +675,13 @@ static int kimage_load_normal_segment(struct kexec_image *image, while ( to_copy ) { unsigned long dest_mfn; - size_t dest_off; struct page_info *page; void *dest_va; size_t size; dest_mfn = dest >> PAGE_SHIFT; - dest_off = dest & ~PAGE_MASK; - size = min(PAGE_SIZE - dest_off, to_copy); + size = min_t(unsigned long, PAGE_SIZE, to_copy); page = kimage_alloc_page(image, dest); if ( !page ) @@ -693,16 +691,21 @@ static int kimage_load_normal_segment(struct kexec_image *image, return ret; dest_va = __map_domain_page(page); - ret = copy_from_guest_offset(dest_va + dest_off, segment->buf, src_offset, size); + ret = copy_from_guest_offset(dest_va, segment->buf, src_offset, size); unmap_domain_page(dest_va); if ( ret ) return -EFAULT; to_copy -= size; src_offset += size; - dest += size; + dest += PAGE_SIZE; } + /* Remainder of the destination should be zeroed. */ + end = segment->dest_maddr + segment->dest_size; + for ( ; dest < end; dest += PAGE_SIZE ) + kimage_add_entry(image, IND_ZERO); + return 0; } --- a/xen/include/xen/kimage.h +++ b/xen/include/xen/kimage.h @@ -14,6 +14,7 @@ typedef paddr_t kimage_entry_t; #define IND_INDIRECTION 0x2 #define IND_DONE 0x4 #define IND_SOURCE 0x8 +#define IND_ZERO 0x10 struct kexec_image { uint8_t type; David
Daniel Kiper
2013-Apr-19 13:22 UTC
Re: [PATCHv4 0/8] kexec: extend kexec hypercall for use with pv-ops kernels
On Thu, Apr 18, 2013 at 06:38:39PM +0100, David Vrabel wrote:> On 17/04/13 13:34, Daniel Kiper wrote: > > > > kexec -e still does not work. I see in my console: > > > > I''m in purgatory > > sha256 digests do not match :( > > I have now fixed this. Xen was not probably zeroing out trailing pages > (only partial pages) when loading a default image (crash was fine).Idea is quite good but how many pages in percent are zero? Is it worth to do that? Additionally, I am afraid that this way you are only masking bug in kexec-tools. I think it is better to do bisect on it and find out which patch introduces a bug.> The kernel does this by allocating and clearing pages and then > relocating these as normal but it''s wasteful to allocate a bunch of > empty pages so I added a IND_ZERO entry type for the indirection pages > which gets the relocation code to zero the destination. > > See the kexec-v5 branch at: > > http://xenbits.xen.org/gitweb/?p=people/dvrabel/xen.git;a=summary > > I shall repost this series again once the 4.4 development window is open.Do you think that at this stage we are not able to introduce this kexec implementation into 4.3? I think that we should try. Daniel