On 04/29/19 at 12:48pm, Pingfan Liu wrote:
> On Mon, Apr 29, 2019 at 11:04 AM Pingfan Liu wrote:
> >
> > On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote:
> > >
> > > On 04/25/19 at 04:20pm, Pingfan Liu wrote:
> > > > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger
> > > > wrote:
> > > > >
> >
On Mon, Apr 29, 2019 at 11:04 AM Pingfan Liu wrote:
>
> On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote:
> >
> > On 04/25/19 at 04:20pm, Pingfan Liu wrote:
> > > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger
> > > wrote:
> > > >
> > > >
> > > [...]
> > > > > @@ -139,6 +141,8 @@ static int _
On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote:
>
> On 04/25/19 at 04:20pm, Pingfan Liu wrote:
> > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
> > >
> > >
> > [...]
> > > > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char
> > > > *cmdline,
> > > > p
From: Kairui Song
The current code only builds identity mapping for physical memory during
kexec-type loading. The regions reserved by firmware are not covered.
In the later patch, the boot decompressing code of kexec-ed kernel tries
to access EFI systab and ACPI tables, lacking identity mapping
When I kexec either Xen or Linux in real mode, from either Xen or
Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
IN:
0x000f70ec: mov%eax,%esi
0x000f70ef: mov$0xb5,%eax
0x000f70f5: mov$0x1234,%ecx
0x00
From: David Woodhouse
Unlike Linux which creates a full identity mapping, Xen only maps those
segments which are explicitly requested. Therefore, xen_kexec_load()
silently adds in a segment from zero to 1MiB to ensure that VGA memory
and other things are accessible.
However, this doesn't work wh
On 04/25/19 at 04:20pm, Pingfan Liu wrote:
> On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
> >
> >
> [...]
> > > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char
> > > *cmdline,
> > > pr_warn("crashkernel: unrecognized char: %c\n", *cur);
> > >
