From: Trammell Hudson <hudson@trmm.net>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Juergen Gross <JGross@suse.com>,
xen-devel@lists.xenproject.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: kexec and xen/arch/x86/boot/head.S trampoline
Date: Wed, 28 Feb 2018 09:27:09 -0700 [thread overview]
Message-ID: <20180228162709.GH9625@chishio.swcp.com> (raw)
In-Reply-To: <24de45ee-d705-4751-3d88-c3f5887e8bd1@citrix.com>
On Wed, Feb 28, 2018 at 03:07:41PM +0000, Andrew Cooper wrote:
> On 28/02/18 14:08, Trammell Hudson wrote:
> > kexec allocates a 1 page segment at 0x0 and memsets most of it to zero,
> > wiping out coreboot's EBDA structure, which xen's head.S consulted to
> > allocate the trampoline. Xen's code looks like this:
>
> This sounds like a bug as and of itself. I presume this is to do with
> IVT handling?
Maybe? That's the right address and it only populates 0x78 bytes
(in qemu) with contents, which would be about right for the interrupt
table. I haven't tracked down where that data comes from.
> [...]
> > Are there reasons to prefer EBDA over mbi->mem_lower?
>
> I think the expectation was that the EBDA would be more reliable than
> mbi->mem_lower. However, we recently hit a similar bug with PVH
> handling (c/s a232346b1fe), and these days, the EBDA is quite likely not
> to be present.
>
> I think we probably can use mbi->mem_lower (if available and sane) by
> default. If the bootloader has messed that up, all bets are off
> anyway. Irrespective, we should fix the EBDA lower sanity check.
What do you think of something like this instead?
/*
* If the multiboot structure memory limits are available,
* use it for the trampoline.
*/
testb $MBI_MEMLIMITS,(%ebx)
jz 1f /* not available? BDA value will be fine */
mov MB_mem_lower(%ebx),%ecx
cmp $0x100,%ecx /* is the multiboot value too small? */
jae 2f
1:
/* MBI not available, set up trampoline segment 64k below EBDA */
movzwl 0x40e,%ecx /* EBDA segment */
cmp $0xa000,%ecx /* sanity check (high) */
jae 0f
cmp $0x4000,%ecx /* sanity check (low) */
jae 2f
0:
movzwl 0x413,%ecx /* use base memory size on failure */
cmp $0xa000,%ecx /* sanity check (high) */
jae bad_ebda
cmp $0x4000,%ecx /* sanity check (low) */
jb bad_ebda
2: /* Reserve 64kb for the trampoline */
shl $10-4,%ecx /* convert to bytes */
sub $0x1000,%ecx
--
Trammell
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
prev parent reply other threads:[~2018-02-28 16:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 14:08 kexec and xen/arch/x86/boot/head.S trampoline Trammell Hudson
2018-02-28 15:07 ` Andrew Cooper
2018-02-28 16:27 ` Trammell Hudson [this message]
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=20180228162709.GH9625@chishio.swcp.com \
--to=hudson@trmm.net \
--cc=JBeulich@suse.com \
--cc=JGross@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).