From: Dave Young <dyoung@redhat.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: matt.fleming@intel.com,
Kweh Hock Leong <hock.leong.kweh@intel.com>,
linux-efi@vger.kernel.org, kexec@lists.infradead.org,
vgoyal@redhat.com
Subject: Re: [RFD] efi assisted kdump
Date: Tue, 27 Jan 2015 14:37:42 +0800 [thread overview]
Message-ID: <20150127063742.GE2506@darkstar.redhat.com> (raw)
In-Reply-To: <20150126163941.GD3320@codeblueprint.co.uk>
Hi, Matt
Thanks for the feedback.
On 01/26/15 at 04:39pm, Matt Fleming wrote:
> On Sat, 24 Jan, at 09:26:37PM, Dave Young wrote:
> >
> > There's several things I need to ask for help from EFI gurus to see if it is doable:
> >
> > * Make sure in case EFI warm reboot the memory of previous kernel can be retained.
>
> The only way to reserve memory across a reboot is with EFI capsules.
I know your capsules patchset, but I did not look into the details.
Do you means the old memory will be not reliable in case booting without capsules
even for warm reboot?
>
> > * How to determine if kernel is boot with EFI warm reboot in stub
>
> The presence of a capsule would indicate whether we were invoked from a
> crash handler.
Ok, another problem is for efi capsule handling, can we do it in efi stub, or I
in a efi application, which stage is the doable?
>
> > * What is the right way to pass informations from 1st kernel to 2nd kernel.
> > Is it ok for saving something with efi variables?
>
> EFI capsules would the be most natural mechanism, but you could
> conceivably do it with EFI variables (there's an upper limit on the size
> of variable data, though).
Will think about it after I checking the capsule machanisms details.
>
> > * Other possible problems what I missed
>
> Support for runtime EFI capsules was rather spotty last time I looked.
> Things may have moved on, but it's definitely something to watch out
> for.
>
> There have been patches on linux-efi in recent months for making use of
> EFI capsules,
>
> https://lkml.kernel.org/r/1412692886-25306-1-git-send-email-matt@console-pimps.org
> https://lkml.kernel.org/r/1414984030-13859-1-git-send-email-hock.leong.kweh@intel.com
>
> I could take a look at resubmitting the first series above if that would
> be useful for doing kexec across a reset.
Thanks a lot. I will take a look at how capsules works firstly.
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2015-01-27 6:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-24 13:26 [RFD] efi assisted kdump Dave Young
2015-01-24 16:03 ` Petr Tesarik
2015-01-27 6:21 ` Dave Young
2015-01-27 9:14 ` Petr Tesarik
2015-01-26 14:08 ` Vivek Goyal
2015-01-27 6:24 ` Dave Young
2015-01-26 16:39 ` Matt Fleming
2015-01-27 6:37 ` Dave Young [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=20150127063742.GE2506@darkstar.redhat.com \
--to=dyoung@redhat.com \
--cc=hock.leong.kweh@intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=matt@codeblueprint.co.uk \
--cc=vgoyal@redhat.com \
/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