From: Don Slutz <dslutz@verizon.com>
To: David Vrabel <david.vrabel@citrix.com>,
Daniel Kiper <daniel.kiper@oracle.com>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
Daniel Kiper <dkiper@net-space.pl>,
xen-devel@lists.xen.org
Subject: Re: [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels
Date: Thu, 31 Oct 2013 12:59:34 -0400 [thread overview]
Message-ID: <52728C76.8040501@terremark.com> (raw)
In-Reply-To: <52713A86.3050102@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 7445 bytes --]
On 10/30/13 12:57, David Vrabel wrote:
> On 21/10/13 21:20, Daniel Kiper wrote:
>> On Mon, Oct 21, 2013 at 01:56:09PM +0100, David Vrabel wrote:
>>> On 21/10/13 13:19, Daniel Kiper wrote:
>>>> On Sat, Oct 19, 2013 at 12:14:24AM +0100, David Vrabel wrote:
>>>>> On 18/10/2013 19:40, Daniel Kiper wrote:
>>>>>> On Tue, Oct 08, 2013 at 05:55:01PM +0100, David Vrabel wrote:
>>>>>>> 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.
>>>>>> I could not load panic image because Xen crashes in following way:
>>>>>>
>>>>>> (XEN) ----[ Xen-4.4-unstable x86_64 debug=y Tainted: C ]----
>>>>> [...]
>>>>>> (XEN) Xen call trace:
>>>>>> (XEN) [<ffff82d080114ef2>] kimage_free+0x67/0xd2
>>>>>> (XEN) [<ffff82d0801151f9>] do_kimage_alloc+0x29c/0x2f0
>>>>>> (XEN) [<ffff82d0801152fe>] kimage_alloc+0xb1/0xe6
>>>>>> (XEN) [<ffff82d0801144c0>] do_kexec_op_internal+0x68e/0x789
>>>>>> (XEN) [<ffff82d0801145c9>] do_kexec_op+0xe/0x12
>>>>>> (XEN) [<ffff82d0802268cb>] syscall_enter+0xeb/0x145
I get the same thing.
>>>>> The appended patch should fix this crash which only occurs if there's an
>>>>> error in do_kimage_alloc().
>>>> Patch had wrapped lines. I hope that I fixed it properly.
>>>> I cannot load panic kernel. kexec fails with following message:
My version of this patch is attached (0001...). It has both crashed right away and not:
(XEN) [2013-10-30 21:26:39] ----[ Xen-4.4-unstable x86_64 debug=y Not tainted ]----
(XEN) [2013-10-30 21:26:39] CPU: 7
(XEN) [2013-10-30 21:26:39] RIP: e008:[<ffff82d08012fd72>] xmem_pool_free+0x6f/0x2e9
(XEN) [2013-10-30 21:26:39] RFLAGS: 0000000000010286 CONTEXT: hypervisor
(XEN) [2013-10-30 21:26:39] rax: ffff8308df5a5e90 rbx: ffff83083f48f9f0 rcx: 000000000001b410
(XEN) [2013-10-30 21:26:39] rdx: 00000000a01164a0 rsi: ffff83083a1ae000 rdi: ffff83083a1af86c
(XEN) [2013-10-30 21:26:39] rbp: ffff830823fbfd88 rsp: ffff830823fbfd68 r8: 000000000000000c
(XEN) [2013-10-30 21:26:39] r9: 0000000010000000 r10: ffff83083f4904f0 r11: 00000000004c6000
(XEN) [2013-10-30 21:26:39] r12: ffff83083a1ae000 r13: ffff83083a1af868 r14: 00007fff5a9b7fc0
(XEN) [2013-10-30 21:26:39] r15: 0000000000000003 cr0: 0000000080050033 cr4: 00000000000426f0
(XEN) [2013-10-30 21:26:39] cr3: 000000066b482000 cr2: ffff8308df5a5e98
(XEN) [2013-10-30 21:26:39] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) [2013-10-30 21:26:39] Xen stack trace from rsp=ffff830823fbfd68:
(XEN) [2013-10-30 21:26:39] 00000000000000e0 00000000ffffff9d ffff83083f4904f0 ffff83083f48f9f0
(XEN) [2013-10-30 21:26:39] ffff830823fbfdc8 ffff82d0801304fe ffff830823fbfdc8 00000000ffffff9d
(XEN) [2013-10-30 21:26:39] ffff83083f4904f0 ffff8800870bb5e8 00007fff5a9b7fc0 0000000000000003
(XEN) [2013-10-30 21:26:39] ffff830823fbfee8 ffff82d08011450c ffff830823fbfef8 0000000000000000
(XEN) [2013-10-30 21:26:39] 0000000000000002 ffff830823fb10b8 ffff830823fbfe18 ffff82d08012b104
(XEN) [2013-10-30 21:26:39] ffff8300bf2f4060 000000000066a0cb 0000000000000000 ffff8300bf2f4000
(XEN) [2013-10-30 21:26:39] ffff82004001f000 00007ff000000003 00000007003e0001 00007f84d993b004
(XEN) [2013-10-30 21:26:39] 000000001ff53720 ffff830823fb1000 ffff830823fbfe68 ffff82d08016fb23
(XEN) [2013-10-30 21:26:39] ffff830823fbfe88 ffff82d080221348 ffff830823fb1000 ffff830823fbff18
(XEN) [2013-10-30 21:26:39] ffff830823fbfef8 ffff82d0802214a8 00000000d69204a7 0000000000000000
(XEN) [2013-10-30 21:26:39] 0000000000000217 0000003564eee0a7 0000000000000100 0000003564eee0a7
(XEN) [2013-10-30 21:26:39] ffff830823fbfed8 ffff82d08016fb23 ffff8300bf2f4000 00007fff5a9b7fc0
(XEN) [2013-10-30 21:26:39] ffff830823fbfef8 ffff82d0801145d9 00007cf7dc0400c7 ffff82d0802268cb
(XEN) [2013-10-30 21:26:39] ffffffff810014aa 0000000000000025 0000001efd525f9a 0000001efd60d300
(XEN) [2013-10-30 21:26:39] 0000000000000000 00000021d69204a7 ffff880087debe88 ffff880005d9a500
(XEN) [2013-10-30 21:26:39] 0000000000000286 00007fff5a9b8180 ffff880087191480 000000001ff53720
(XEN) [2013-10-30 21:26:39] 0000000000000025 ffffffff810014aa 0000003564a148e5 00007f84d8f3f004
(XEN) [2013-10-30 21:26:39] 0000000000000004 0001010000000000 ffffffff810014aa 000000000000e033
(XEN) [2013-10-30 21:26:39] 0000000000000286 ffff880087debde0 000000000000e02b d53835942492fce9
...
The auto reboot overwrote the rest. When it did not crash right away, the next day I got error messages about page table issues. (I forgot that the request to write hypervisor console data to a file is not the default.) I hope to still have the data at home.
Best guess at this point is that the error handling still has issues.
>>>> kexec_load failed: Cannot assign requested address
>>> This is -EADDRINVALID which means one of
>>>
>>> a) the entry point isn't within a segment.
>>> b) one of the segments is not page aligned.
>>> c) one of the segments is not within the crash region.
>>>
>>> But the segments kexec has constructed all looked fine to me (and
>>> similar to the segments I see).
I have tracked this down to in kexec-tools:
+ if (info->kexec_flags & KEXEC_ON_CRASH) {
+ set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);
+ xen_segs[s].buf_size = 0;
+ xen_segs[s].dest_maddr = info->backup_src_start;
+ xen_segs[s].dest_size = info->backup_src_size;
+ nr_segments++;
+ }
Which in some cases passes the 1st e820 line which for me is:
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009b800 (usable)
(XEN) 000000000009b800 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bf63f000 (usable)
...
000000000009b800 is not page aligned and so the test:
if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) )
goto out;
Fails.
A possible fix is attached as (0002...) this does allow me to get into the crash kernel.
-Don Slutz
>>> I'm afraid I cannot reproduce either of your failures. Are you sure
>>> you've built everything correctly? In particular has kexec-tools been
>>> built against the correct version of Xen headers?
>> It looks that I build it correctly but I will double check it.
>> Could you send me your Xen/Linux boot command lines and kexec
>> command lines for normal and panic kernel? Could you tell me
>> what is your RAM size?
> AMD Opteron 4264 with 8 GiB RAM.
>
> Xen 4.4-unstable debug=y:
>
> com1=115200,8n1 console=com1 crashkernel=256M@64M
>
> Linux 3.12-rc4
>
> root=/dev/mapper/cam--st09-root ro console=hvc0
>
> Normal image:
>
> build/sbin/kexec --debug --console-serial --serial-baud=115200
> --command-line="console=ttyS0,115200n8 maxcpus=1" -l
> /boot/vmlinuz-3.11.0.davidvr
>
> Panic image:
>
> build/sbin/kexec --debug --console-serial --serial-baud=115200
> --command-line="console=ttyS0,115200n8 maxcpus=1" -p
> /boot/vmlinuz-3.11.0.davidvr
>
> David
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 11977 bytes --]
[-- Attachment #2: 0001-kexec-v9a-Fix-error-handling-if-do_kimage_alloc-repo.patch --]
[-- Type: text/x-patch, Size: 2281 bytes --]
>From bb2407bb2b712b33355d8c3df751bd1ecde1f971 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Wed, 30 Oct 2013 17:17:24 -0400
Subject: [PATCH 1/2] kexec: v9a -- Fix error handling if do_kimage_alloc()
reports an error
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
xen/common/kimage.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 6bee9cf..f2b331e 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -179,7 +179,7 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry,
page_to_maddr(image->control_code_page),
page_to_maddr(image->control_code_page));
if ( result < 0 )
- return result;
+ goto out;
/* Add an empty indirection page. */
image->entry_page = kimage_alloc_control_page(image, 0);
@@ -188,7 +188,7 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry,
result = machine_kexec_add_page(image, page_to_maddr(image->entry_page),
page_to_maddr(image->entry_page));
if ( result < 0 )
- return result;
+ goto out;
image->head = page_to_maddr(image->entry_page);
@@ -510,15 +510,14 @@ static void kimage_free_entry(kimage_entry_t entry)
free_domheap_page(page);
}
-void kimage_free(struct kexec_image *image)
+static void kimage_free_all_entries(struct kexec_image *image)
{
kimage_entry_t *ptr, entry;
kimage_entry_t ind = 0;
- if ( !image )
+ if ( !image->head )
return;
- kimage_free_extra_pages(image);
for_each_kimage_entry(image, ptr, entry)
{
if ( entry & IND_INDIRECTION )
@@ -537,8 +536,15 @@ void kimage_free(struct kexec_image *image)
/* Free the final indirection page. */
if ( ind & IND_INDIRECTION )
kimage_free_entry(ind);
+}
- /* Free the kexec control pages. */
+void kimage_free(struct kexec_image *image)
+{
+ if ( !image )
+ return;
+
+ kimage_free_extra_pages(image);
+ kimage_free_all_entries(image);
kimage_free_page_list(&image->control_pages);
xfree(image->segments);
xfree(image);
--
1.7.11.7
[-- Attachment #3: 0002-kexec-Skip-checking-of-info-backup_src_start-info-ba.patch --]
[-- Type: text/x-patch, Size: 1913 bytes --]
>From a4eb6108908c65559d4b3997949fb41f0b2828a5 Mon Sep 17 00:00:00 2001
From: Don Slutz <dslutz@verizon.com>
Date: Thu, 31 Oct 2013 11:31:06 -0400
Subject: [PATCH 2/2] kexec: Skip checking of info->backup_src_start &
info->backup_src_size.
Signed-off-by: Don Slutz <dslutz@verizon.com>
---
xen/common/kimage.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index f2b331e..92c6ebf 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -124,6 +124,9 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry,
{
paddr_t mstart, mend;
+ if ( guest_handle_is_null(segments[i].buf.h) )
+ continue;
+
mstart = image->segments[i].dest_maddr;
mend = mstart + image->segments[i].dest_size;
if ( (mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK) )
@@ -142,11 +145,18 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry,
paddr_t mstart, mend;
unsigned long j;
+ if ( guest_handle_is_null(segments[i].buf.h) )
+ continue;
+
mstart = image->segments[i].dest_maddr;
mend = mstart + image->segments[i].dest_size;
for (j = 0; j < i; j++ )
{
paddr_t pstart, pend;
+
+ if ( guest_handle_is_null(segments[i].buf.h) )
+ continue;
+
pstart = image->segments[j].dest_maddr;
pend = pstart + image->segments[j].dest_size;
/* Do the segments overlap? */
@@ -163,6 +173,9 @@ static int do_kimage_alloc(struct kexec_image **rimage, paddr_t entry,
result = -EINVAL;
for ( i = 0; i < nr_segments; i++ )
{
+ if ( guest_handle_is_null(segments[i].buf.h) )
+ continue;
+
if ( image->segments[i].buf_size > image->segments[i].dest_size )
goto out;
}
--
1.7.11.7
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-10-31 16:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 16:55 [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels David Vrabel
2013-10-08 16:55 ` [PATCH 1/9] x86: give FIX_EFI_MPF its own fixmap entry David Vrabel
2013-10-08 16:55 ` [PATCH 2/9] kexec: add public interface for improved load/unload sub-ops David Vrabel
2013-10-08 16:55 ` [PATCH 3/9] kexec: add infrastructure for handling kexec images David Vrabel
2013-11-05 22:39 ` Don Slutz
2013-11-06 8:12 ` Jan Beulich
2013-10-08 16:55 ` [PATCH 4/9] kexec: extend hypercall with improved load/unload ops David Vrabel
2013-11-05 22:43 ` Don Slutz
2013-10-08 16:55 ` [PATCH 5/9] xen: kexec crash image when dom0 crashes David Vrabel
2013-10-08 16:55 ` [PATCH 6/9] libxc: add hypercall buffer arrays David Vrabel
2013-10-08 16:55 ` [PATCH 7/9] libxc: add API for kexec hypercall David Vrabel
2013-10-08 16:55 ` [PATCH 8/9] x86: check kexec relocation code fits in a page David Vrabel
2013-10-08 16:55 ` [PATCH 9/9] MAINTAINERS: Add KEXEC maintainer David Vrabel
2013-10-08 17:03 ` [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels Andrew Cooper
2013-10-09 15:26 ` Daniel Kiper
2013-10-09 15:52 ` Andrew Cooper
2013-10-09 16:03 ` David Vrabel
2013-10-10 15:45 ` Daniel Kiper
2013-10-10 16:35 ` David Vrabel
2013-10-10 21:24 ` Daniel Kiper
2013-10-11 6:49 ` Jan Beulich
2013-10-11 8:58 ` Daniel Kiper
2013-10-11 9:56 ` David Vrabel
2013-10-11 11:15 ` Daniel Kiper
2013-10-11 14:06 ` David Vrabel
2013-10-14 13:53 ` Daniel Kiper
2013-10-14 14:14 ` David Vrabel
2013-10-14 18:13 ` Daniel Kiper
2013-10-16 21:09 ` Daniel Kiper
2013-11-14 11:20 ` Daniel Kiper
2013-11-14 11:27 ` David Vrabel
2013-10-18 18:40 ` Daniel Kiper
2013-10-18 23:14 ` David Vrabel
2013-10-21 12:19 ` Daniel Kiper
2013-10-21 12:56 ` David Vrabel
2013-10-21 20:20 ` Daniel Kiper
2013-10-25 9:13 ` Daniel Kiper
2013-10-25 23:04 ` David Vrabel
2013-10-30 16:57 ` David Vrabel
2013-10-31 16:59 ` Don Slutz [this message]
2013-10-31 18:30 ` David Vrabel
2013-10-31 20:23 ` Don Slutz
2013-10-31 22:21 ` Daniel Kiper
2013-11-05 17:41 ` Daniel Kiper
2013-11-05 18:01 ` David Vrabel
2013-10-18 23:42 ` Andrew Cooper
2013-10-21 3:11 ` Xu, YongweiX
2013-10-21 10:21 ` David Vrabel
2013-10-21 12:26 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52728C76.8040501@terremark.com \
--to=dslutz@verizon.com \
--cc=daniel.kiper@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=dkiper@net-space.pl \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.