From: Dave Young <dyoung@redhat.com>
To: Khalid Aziz <khalid.aziz@hp.com>
Cc: horms@verge.net.au, kexec@lists.infradead.org, vgoyal@redhat.com
Subject: Re: [PATCH]kdump: pass noefi and acpi_rsdp= to 2nd kernel
Date: Thu, 06 Sep 2012 11:18:03 +0800 [thread overview]
Message-ID: <504815EB.9000701@redhat.com> (raw)
In-Reply-To: <5047DBA9.8030000@hp.com>
On 09/06/2012 07:09 AM, Khalid Aziz wrote:
> This will evaluate only the first line in systab. I do not believe you
> are guaranteed to see ACPI20= or ACPI= in the first line. Here is the
> systab file from my machine:
>
> MPS=0xf4cf0
> ACPI20=0xcac3e000
> ACPI=0xcac3e000
> SMBIOS=0xcac4cf98
>
> We need to parse all the lines in systab.
Thanks for the reporting, will address this in the update patch
> I think running a kexec/kdump kernel with "noefi" is not a good idea.
> Today kernel makes very little use of UEFI run time services but this
> might change shortly. I have already seen ideas being proposed to use
> UEFI variables to store kernel panic information which would require
> accessing UEFI runtime services. If the kdump kernel runs into a panic,
> it would be good to be able to use UEFI variables to store some sort of
> tombstone. We might also start using UEFI runtime clock services one of
> these days especially now that all PCs soon will have UEFI due to
> Windows 8 requirements. There might be other ways to deal with EFI
> virtualization issue. I have solved it on a custom ia64 kernel by
> passing the kexec'd kernel a "kexec_reboot" on command line, although I
> wouldn't recommend that approach as a general approach. Creating a new
> kernel command line parameter just to tell the kernel to not virtualize
> EFI sounds excessive. May be we can come up with a different way to tell
> a kexec/kdump kernel to not virtualize EFI, like create a new signature,
> for example "EL32_KEXEC" and "EL64_KEXEC", for
> boot_params.efi_info.efi_loader_signature which tells the kexec/kdump
> kernel to enable EFI but skip the step of virtualizing it. More work
> will be needed to make this work, for example pass the EFI runtime
> service memory map from one kernel to the next so we keep it mapped in
> exact same spot, and other similar mapping issues.
>
I'm not so familiar with uefi detail, is the virtualization issue mean
"virtual mode" of efi? From my understanding for kdump kernel I would
vote for not interacting with bios at all. We have use "noefi" for long
time by passing it to 2nd kernel while kexecing. I prefer to do this way
until we have to switch to other approach.
--
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-09-06 3:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 5:44 [PATCH]kdump: pass noefi and acpi_rsdp= to 2nd kernel Dave Young
2012-09-05 7:45 ` Simon Horman
2012-09-06 2:48 ` Dave Young
2012-09-05 13:18 ` Vivek Goyal
2012-09-06 2:58 ` Dave Young
2012-09-06 20:46 ` Vivek Goyal
2012-09-05 23:09 ` Khalid Aziz
2012-09-06 3:18 ` Dave Young [this message]
2012-09-06 17:57 ` Khalid Aziz
2012-09-07 8:56 ` Dave Young
2012-09-07 14:37 ` Khalid Aziz
2012-09-13 13:38 ` Vivek Goyal
2012-09-14 20:32 ` Khalid Aziz
2012-09-20 7:49 ` Eric W. Biederman
2012-09-21 22:50 ` Khalid Aziz
2012-09-12 2:35 ` Dave Young
2012-10-18 3:12 ` Dave Young
2012-10-18 14:59 ` Khalid Aziz
2012-10-22 2:05 ` Dave Young
2012-09-06 20:24 ` Vivek Goyal
2012-09-07 14:32 ` Khalid Aziz
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=504815EB.9000701@redhat.com \
--to=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=khalid.aziz@hp.com \
--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 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.