From: Matt Fleming <matt@codeblueprint.co.uk>
To: Dave Young <dyoung@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
linux-efi@vger.kernel.org, kexec@lists.infradead.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
linux-acpi@vger.kernel.org, Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86/efi: skip bgrt init for kexec reboot
Date: Thu, 4 Feb 2016 11:56:56 +0000 [thread overview]
Message-ID: <20160204115656.GB2586@codeblueprint.co.uk> (raw)
In-Reply-To: <20160204110903.GA2977@dhcp-128-65.nay.redhat.com>
On Thu, 04 Feb, at 07:09:03PM, Dave Young wrote:
>
> Consider the original code path, maybe change it to efi_kexec_setup will
> be better to remind people? Or something else like a wraper function with
> similar name..
Possibly. I had considered adding a new efi_enabled() bit for
KEXEC_BOOT, but I'm worried that'll just encourage more uses.
The best approach is going to be to see whether we can reduce the uses
of efi_setup and the associated special code. Once we've completed
that exercise, we can think about the best name for this variable.
> For building ACPI tables we need do it in kernel instead of kexec-tools
> because of kexec_file_load for secure boot case so we still need a conditional
> code path for kexec..
Note that it may not be necessary to build any ACPI tables at all,
provided that things like acpi_get_table() fail gracefully for kexec.
I'm assuming that's the problem that you discovered when writing this
patch.
And yes, I don't expect you can build the ACPI table from userspace,
but it should at least be possible to do it in setup_boot_parameters()
or so when you setup the EFI table pointers (efi.config_tables), etc.
I think that would be a natural home for this feature.
> Also I'm not sure how to rebuild ACPI tables, it is easy or hard. Let me
> checking the detail and think more about it.
Thanks.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
Subject: Re: [PATCH] x86/efi: skip bgrt init for kexec reboot
Date: Thu, 4 Feb 2016 11:56:56 +0000 [thread overview]
Message-ID: <20160204115656.GB2586@codeblueprint.co.uk> (raw)
In-Reply-To: <20160204110903.GA2977-0VdLhd/A9Pl+NNSt+8eSiB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
On Thu, 04 Feb, at 07:09:03PM, Dave Young wrote:
>
> Consider the original code path, maybe change it to efi_kexec_setup will
> be better to remind people? Or something else like a wraper function with
> similar name..
Possibly. I had considered adding a new efi_enabled() bit for
KEXEC_BOOT, but I'm worried that'll just encourage more uses.
The best approach is going to be to see whether we can reduce the uses
of efi_setup and the associated special code. Once we've completed
that exercise, we can think about the best name for this variable.
> For building ACPI tables we need do it in kernel instead of kexec-tools
> because of kexec_file_load for secure boot case so we still need a conditional
> code path for kexec..
Note that it may not be necessary to build any ACPI tables at all,
provided that things like acpi_get_table() fail gracefully for kexec.
I'm assuming that's the problem that you discovered when writing this
patch.
And yes, I don't expect you can build the ACPI table from userspace,
but it should at least be possible to do it in setup_boot_parameters()
or so when you setup the EFI table pointers (efi.config_tables), etc.
I think that would be a natural home for this feature.
> Also I'm not sure how to rebuild ACPI tables, it is easy or hard. Let me
> checking the detail and think more about it.
Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Dave Young <dyoung@redhat.com>
Cc: linux-efi@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
linux-acpi@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Josh Triplett <josh@joshtriplett.org>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] x86/efi: skip bgrt init for kexec reboot
Date: Thu, 4 Feb 2016 11:56:56 +0000 [thread overview]
Message-ID: <20160204115656.GB2586@codeblueprint.co.uk> (raw)
In-Reply-To: <20160204110903.GA2977@dhcp-128-65.nay.redhat.com>
On Thu, 04 Feb, at 07:09:03PM, Dave Young wrote:
>
> Consider the original code path, maybe change it to efi_kexec_setup will
> be better to remind people? Or something else like a wraper function with
> similar name..
Possibly. I had considered adding a new efi_enabled() bit for
KEXEC_BOOT, but I'm worried that'll just encourage more uses.
The best approach is going to be to see whether we can reduce the uses
of efi_setup and the associated special code. Once we've completed
that exercise, we can think about the best name for this variable.
> For building ACPI tables we need do it in kernel instead of kexec-tools
> because of kexec_file_load for secure boot case so we still need a conditional
> code path for kexec..
Note that it may not be necessary to build any ACPI tables at all,
provided that things like acpi_get_table() fail gracefully for kexec.
I'm assuming that's the problem that you discovered when writing this
patch.
And yes, I don't expect you can build the ACPI table from userspace,
but it should at least be possible to do it in setup_boot_parameters()
or so when you setup the EFI table pointers (efi.config_tables), etc.
I think that would be a natural home for this feature.
> Also I'm not sure how to rebuild ACPI tables, it is easy or hard. Let me
> checking the detail and think more about it.
Thanks.
next prev parent reply other threads:[~2016-02-04 11:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 11:20 [PATCH] x86/efi: skip bgrt init for kexec reboot Dave Young
2016-01-27 11:20 ` Dave Young
2016-01-27 11:20 ` Dave Young
2016-02-03 21:42 ` Dave Young
2016-02-03 21:42 ` Dave Young
2016-02-03 21:42 ` Dave Young
2016-02-03 22:53 ` Matt Fleming
2016-02-03 22:53 ` Matt Fleming
2016-02-03 22:53 ` Matt Fleming
2016-02-04 10:03 ` Matt Fleming
2016-02-04 10:03 ` Matt Fleming
2016-02-04 10:03 ` Matt Fleming
2016-02-04 11:09 ` Dave Young
2016-02-04 11:09 ` Dave Young
2016-02-04 11:56 ` Matt Fleming [this message]
2016-02-04 11:56 ` Matt Fleming
2016-02-04 11:56 ` Matt Fleming
2016-02-05 0:41 ` Dave Young
2016-02-05 0:41 ` Dave Young
2016-02-11 16:09 ` Matt Fleming
2016-02-11 16:09 ` Matt Fleming
2016-02-12 12:45 ` Dave Young
2016-02-12 12:45 ` Dave Young
2016-02-16 14:48 ` Matt Fleming
2016-02-16 14:48 ` Matt Fleming
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=20160204115656.GB2586@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=josh@joshtriplett.org \
--cc=kexec@lists.infradead.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rjw@rjwysocki.net \
/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.