linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Dave Young <dyoung@redhat.com>
Cc: "Jean Delvare" <jdelvare@suse.com>,
	linux-kernel@vger.kernel.org,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Javier Tiá" <javier.tia@gmail.com>,
	kexec@lists.infradead.org,
	"Eric Biederman" <ebiederm@xmission.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Ard Biesheuvel" <ardb@kernel.org>
Subject: Re: [PATCH v1 0/2] firmware: dmi_scan: Make it work in kexec'ed kernel
Date: Mon, 7 Jun 2021 19:22:21 +0300	[thread overview]
Message-ID: <YL5HvUqtsDXx5CzM@smile.fi.intel.com> (raw)
In-Reply-To: <YLss6ZNPMIXleLLF@dhcp-128-65.nay.redhat.com>

On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> Hi,
> On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > +Cc: Ard
> > 
> > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > it has been done for ACPI RSDP.
> > > > 
> > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > particular the default I2C host speed is choosen based on DMI system
> > > > information and now gets it correct.
> > > 
> > > Still nothing happens for a while and problem still exists.
> > > Can we do something about it, please?
> 
> Seems I totally missed this thread. Old emails lost.

You can always access to it via lore :-)
https://lore.kernel.org/linux-efi/20161217105721.GB6922@dhcp-128-65.nay.redhat.com/T/#u

(Okay, it's not full, but contains main parts anyway)


> The question Ard asked is to confirm if the firmware converted the
> SMBIOS3 addr to a virtual address after exit boot service. I do not
> remember some easy way to check it due to lost the context of the code.
> But you can try to check it via dmesg|grep SMBIOS both in normal boot
> and kexeced boot log.  And then compare if those addresses are
> identical.
> 
> If the SMBIOS3 addr in kexec kernel is different then it should have
> been modified by firmware. Then we need patch kernel and kexec-tools to
> support it.
> 
> You can try below patch to see if it works:

So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
and apply kernel patch for the second kernel? Or it's all for the first one?

> apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> (kexec_file_load):

Here is how we are using it:
https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54

> --- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
> +++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
> @@ -533,7 +533,8 @@ struct efi_setup_data {
>  	uint64_t runtime;
>  	uint64_t tables;
>  	uint64_t smbios;
> -	uint64_t reserved[8];
> +	uint64_t smbios3;
> +	uint64_t reserved[7];
>  };
>  
>  struct setup_data {
> @@ -580,6 +581,8 @@ static int get_efi_values(struct efi_set
>  
>  	ret = get_efi_value("/sys/firmware/efi/systab", "SMBIOS=0x",
>  			    &esd->smbios);
> +	ret |= get_efi_value("/sys/firmware/efi/systab", "SMBIOS3=0x",
> +			    &esd->smbios3);
>  	ret |= get_efi_value("/sys/firmware/efi/fw_vendor", "0x",
>  			     &esd->fw_vendor);
>  	ret |= get_efi_value("/sys/firmware/efi/runtime", "0x",
> 
> =============================================
> Kernel patch:
> 
> --- linux-x86.orig/arch/x86/include/asm/efi.h
> +++ linux-x86/arch/x86/include/asm/efi.h
> @@ -167,7 +167,8 @@ struct efi_setup_data {
>  	u64 __unused;
>  	u64 tables;
>  	u64 smbios;
> -	u64 reserved[8];
> +	u64 smbios3;
> +	u64 reserved[7];
>  };
>  
>  extern u64 efi_setup;
> --- linux-x86.orig/arch/x86/kernel/kexec-bzimage64.c
> +++ linux-x86/arch/x86/kernel/kexec-bzimage64.c
> @@ -144,6 +144,7 @@ prepare_add_efi_setup_data(struct boot_p
>  	esd->fw_vendor = efi_fw_vendor;
>  	esd->tables = efi_config_table;
>  	esd->smbios = efi.smbios;
> +	esd->smbios3 = efi.smbios3;
>  
>  	sd->type = SETUP_EFI;
>  	sd->len = sizeof(struct efi_setup_data);
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -497,8 +497,8 @@ void __init efi_free_boot_services(void)
>   * their physical addresses therefore we pass them via setup_data and
>   * correct those entries to their respective physical addresses here.
>   *
> - * Currently only handles smbios which is necessary for some firmware
> - * implementation.
> + * Currently only handles smbios and smbios3 which is necessary for
> + * some firmware implementation.
>   */
>  int __init efi_reuse_config(u64 tables, int nr_tables)
>  {
> @@ -521,7 +521,7 @@ int __init efi_reuse_config(u64 tables,
>  		goto out;
>  	}
>  
> -	if (!data->smbios)
> +	if (!data->smbios  && !data->smbios3)
>  		goto out_memremap;
>  
>  	sz = sizeof(efi_config_table_64_t);
> @@ -538,8 +538,10 @@ int __init efi_reuse_config(u64 tables,
>  
>  		guid = ((efi_config_table_64_t *)p)->guid;
>  
> -		if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> +		if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID) && data->smbios)
>  			((efi_config_table_64_t *)p)->table = data->smbios;
> +		else if (!efi_guidcmp(guid, SMBIOS3_TABLE_GUID) && data->smbios3)
> +			((efi_config_table_64_t *)p)->table = data->smbios3;
>  		p += sz;
>  	}
>  	early_memunmap(tablep, nr_tables * sz);
> 
> 
> Thanks
> Dave
> 

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-06-07 16:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20161202195416.58953-1-andriy.shevchenko@linux.intel.com>
     [not found] ` <20161202195416.58953-3-andriy.shevchenko@linux.intel.com>
     [not found]   ` <20161215122856.7d24b7a8@endymion>
     [not found]     ` <20161216023213.GA4505@dhcp-128-65.nay.redhat.com>
     [not found]       ` <1481890738.9552.70.camel@linux.intel.com>
     [not found]         ` <20161216143330.69e9c8ee@endymion>
2016-12-17 10:57           ` [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel Dave Young
2019-09-06 19:00             ` Andy Shevchenko
2020-01-20 12:19             ` Andy Shevchenko
2020-01-20 16:04               ` Eric W. Biederman
2020-01-20 21:42                 ` Jean Delvare
2020-01-20 21:55                   ` Andy Shevchenko
2020-01-21  9:03                     ` Jean Delvare
2020-01-21 16:29                       ` Eric W. Biederman
2020-01-21 17:24                         ` Andy Shevchenko
2020-01-20 22:31                 ` Andy Shevchenko
2020-01-20 23:18                   ` Ard Biesheuvel
2020-01-21 15:37                     ` Andy Shevchenko
2020-01-21 17:17                       ` Eric W. Biederman
2020-05-21 17:39                         ` Andy Shevchenko
2021-06-02  8:37                     ` Andy Shevchenko
2021-06-02  8:53                       ` Andy Shevchenko
2021-06-02  8:42 ` [PATCH v1 0/2] firmware: dmi_scan: Make it work in " Andy Shevchenko
2021-06-02  8:53   ` Andy Shevchenko
2021-06-05  7:51     ` Dave Young
2021-06-07 16:22       ` Andy Shevchenko [this message]
2021-06-07 17:18         ` Andy Shevchenko
2021-06-08 12:25           ` Dave Young
2021-06-08 12:38             ` Andy Shevchenko
2021-06-09 11:55               ` Dave Young
2021-06-12  4:40                 ` Dave Young
2021-06-14 15:38                   ` Andy Shevchenko
2021-06-14 17:07                     ` Andy Shevchenko
2021-06-14 17:27                       ` Andy Shevchenko
2021-07-19  7:53                         ` Ard Biesheuvel
2021-07-19  8:25                           ` Andy Shevchenko
2021-10-06 16:28                         ` Andy Shevchenko
2021-10-07  7:20                           ` Ard Biesheuvel
2021-10-07  7:23                             ` Andy Shevchenko
2021-10-17 13:31                               ` Ard Biesheuvel

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=YL5HvUqtsDXx5CzM@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=javier.tia@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mika.westerberg@linux.intel.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;
as well as URLs for NNTP newsgroup(s).