On 12/05/13 at 09:52pm, Borislav Petkov wrote:
> On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
> > The smbios in efi_setup_data is necessary for kexec to pass the physical
> > address of the SMBIOS table from the 1st kernel to the 2nd kernel.
> >
> > The kernel boot sequence
On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
> The smbios in efi_setup_data is necessary for kexec to pass the physical
> address of the SMBIOS table from the 1st kernel to the 2nd kernel.
>
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios
On Thu, 2013-12-05 at 12:51 +0100, Borislav Petkov wrote:
> On Thu, Dec 05, 2013 at 09:56:15AM +0800, Dave Young wrote:
> > > The z420 firmware is based on some UEFI core that may be used by other
> > > vendors as well. Since this handling is totally harmless (just
> > > redundant), I'd suggest
On Thu, Dec 05, 2013 at 09:56:15AM +0800, Dave Young wrote:
> > The z420 firmware is based on some UEFI core that may be used by other
> > vendors as well. Since this handling is totally harmless (just
> > redundant), I'd suggest not to have a platform check on this handling.
>
> I have same
On Thu, Dec 05, 2013 at 09:56:15AM +0800, Dave Young wrote:
The z420 firmware is based on some UEFI core that may be used by other
vendors as well. Since this handling is totally harmless (just
redundant), I'd suggest not to have a platform check on this handling.
I have same worry as
On Thu, 2013-12-05 at 12:51 +0100, Borislav Petkov wrote:
On Thu, Dec 05, 2013 at 09:56:15AM +0800, Dave Young wrote:
The z420 firmware is based on some UEFI core that may be used by other
vendors as well. Since this handling is totally harmless (just
redundant), I'd suggest not to have
On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
The smbios in efi_setup_data is necessary for kexec to pass the physical
address of the SMBIOS table from the 1st kernel to the 2nd kernel.
The kernel boot sequence proceeds in the following order. Step 2
requires efi.smbios to be
On 12/05/13 at 09:52pm, Borislav Petkov wrote:
On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
The smbios in efi_setup_data is necessary for kexec to pass the physical
address of the SMBIOS table from the 1st kernel to the 2nd kernel.
The kernel boot sequence proceeds in the
On 12/04/13 at 09:43am, Toshi Kani wrote:
> On Wed, 2013-12-04 at 10:46 +0800, Dave Young wrote:
> > Hi, Toshi
> >
> > > Oh, I think I now understand what the issue was. The z420 firmware
> > > updates the SMBIOS table address in the EFI system table to a virtual
> > > address after calling EFI
On Wed, 2013-12-04 at 10:46 +0800, Dave Young wrote:
> Hi, Toshi
>
> > Oh, I think I now understand what the issue was. The z420 firmware
> > updates the SMBIOS table address in the EFI system table to a virtual
> > address after calling EFI SetVirtualAddressMap. So, you are passing the
> >
On Wed, 2013-12-04 at 10:46 +0800, Dave Young wrote:
Hi, Toshi
Oh, I think I now understand what the issue was. The z420 firmware
updates the SMBIOS table address in the EFI system table to a virtual
address after calling EFI SetVirtualAddressMap. So, you are passing the
original
On 12/04/13 at 09:43am, Toshi Kani wrote:
On Wed, 2013-12-04 at 10:46 +0800, Dave Young wrote:
Hi, Toshi
Oh, I think I now understand what the issue was. The z420 firmware
updates the SMBIOS table address in the EFI system table to a virtual
address after calling EFI
Hi, Toshi
> Oh, I think I now understand what the issue was. The z420 firmware
> updates the SMBIOS table address in the EFI system table to a virtual
> address after calling EFI SetVirtualAddressMap. So, you are passing the
> original physical address of the SMBIOS table from the 1st kernel to
On Tue, 2013-12-03 at 09:56 +0800, Dave Young wrote:
> On 12/02/13 at 06:31pm, Toshi Kani wrote:
> > On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
> > > On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
> > > > On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> > > > > On Tue, Nov 26, 2013
On Tue, 2013-12-03 at 09:56 +0800, Dave Young wrote:
On 12/02/13 at 06:31pm, Toshi Kani wrote:
On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
On Tue, Nov 26, 2013 at 01:57:52PM
Hi, Toshi
Oh, I think I now understand what the issue was. The z420 firmware
updates the SMBIOS table address in the EFI system table to a virtual
address after calling EFI SetVirtualAddressMap. So, you are passing the
original physical address of the SMBIOS table from the 1st kernel to the
On 12/02/13 at 06:31pm, Toshi Kani wrote:
> On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
> > On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
> > > On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> > > > On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> > > > > Add a new
On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
> On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
> > On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> > > On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> > > > Add a new setup_data type SETUP_EFI for kexec use.
> > > >
On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
> On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> > On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> > > Add a new setup_data type SETUP_EFI for kexec use.
> > > Passing the saved fw_vendor, runtime, config tables and
> > > efi
On Mon, Dec 02, 2013 at 10:49:15AM +0800, Dave Young wrote:
> All these setup_data passing, remapping etc. is mostly for kexec,
> add a lot of contiditional #if #endif makes the code a mess. I would
> prefer to not do this if you are not strongly object.
Right, having efi_kexec.c could solve all
On Mon, Dec 02, 2013 at 10:49:15AM +0800, Dave Young wrote:
All these setup_data passing, remapping etc. is mostly for kexec,
add a lot of contiditional #if #endif makes the code a mess. I would
prefer to not do this if you are not strongly object.
Right, having efi_kexec.c could solve all
On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime
On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved
On 12/02/13 at 06:31pm, Toshi Kani wrote:
On Mon, 2013-12-02 at 15:33 -0700, Toshi Kani wrote:
On Fri, 2013-11-29 at 17:14 +0800, Dave Young wrote:
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type
On 11/29/13 at 05:46pm, Borislav Petkov wrote:
> On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
> > That's reserved for future extension use, who knows if we will need to
> > pass other fields in the future.
>
> Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
>
On 11/29/13 at 05:46pm, Borislav Petkov wrote:
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
That's reserved for future extension use, who knows if we will need to
pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
> That's reserved for future extension use, who knows if we will need to
> pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
situation where machines might be using older kexec-tools?
On 11/27/13 at 10:17am, Matt Fleming wrote:
> On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
> > To make it more readable, I will change them like below:
> >
> > p = efi_runtime_map;
> > md = efi_setup->map;
> > for (i = 0; i < nr_efi_runtime_map; i++) {
> > [...]
> > md += 1;
> > }
>
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and
> > efi runtime mappings.
> >
> > When entering virtual mode, directly
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the
On 11/27/13 at 10:17am, Matt Fleming wrote:
On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
To make it more readable, I will change them like below:
p = efi_runtime_map;
md = efi_setup-map;
for (i = 0; i nr_efi_runtime_map; i++) {
[...]
md += 1;
}
Actually, md++ is
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
That's reserved for future extension use, who knows if we will need to
pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
situation where machines might be using older kexec-tools?
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and
> efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi
> runtime ragions which we passed in
On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
> To make it more readable, I will change them like below:
>
> p = efi_runtime_map;
> md = efi_setup->map;
> for (i = 0; i < nr_efi_runtime_map; i++) {
> [...]
> md += 1;
> }
Actually, md++ is the canonical way to write this.
> >
>
On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
To make it more readable, I will change them like below:
p = efi_runtime_map;
md = efi_setup-map;
for (i = 0; i nr_efi_runtime_map; i++) {
[...]
md += 1;
}
Actually, md++ is the canonical way to write this.
+
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously.
On 11/26/13 at 10:04pm, Matt Fleming wrote:
> On Tue, 26 Nov, at 01:57:52PM, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and
> > efi runtime mappings.
> >
> > When entering virtual mode, directly mapping the efi
On Tue, 26 Nov, at 01:57:52PM, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and
> efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi
> runtime ragions which we passed in previously. And
On Tue, 26 Nov, at 01:57:52PM, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the
On 11/26/13 at 10:04pm, Matt Fleming wrote:
On Tue, 26 Nov, at 01:57:52PM, Dave Young wrote:
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP
42 matches
Mail list logo
