| Message ID | 20180614182232.78201-7-agraf@suse.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series | sandbox: efi_loader support | expand |
Hi Alex, On 14 June 2018 at 12:22, Alexander Graf <agraf@suse.de> wrote: > We try hard to make sure that SMBIOS tables live in the lower 32bit. > However, when we can not find any space at all there, we should not > error out but instead just fall back to map them in the full address > space instead. > > Signed-off-by: Alexander Graf <agraf@suse.de> > --- > lib/efi_loader/efi_smbios.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) Does that actually work? I thought the addresses in the table were always 32-bit? Regards, Simon
On 14.06.18 21:01, Simon Glass wrote: > Hi Alex, > > On 14 June 2018 at 12:22, Alexander Graf <agraf@suse.de> wrote: >> We try hard to make sure that SMBIOS tables live in the lower 32bit. >> However, when we can not find any space at all there, we should not >> error out but instead just fall back to map them in the full address >> space instead. >> >> Signed-off-by: Alexander Graf <agraf@suse.de> >> --- >> lib/efi_loader/efi_smbios.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) > > Does that actually work? I thought the addresses in the table were > always 32-bit? There is only a single table reference which indeed is 32bit: se->struct_table_address. That address however is unused in the EFI case usually, because the SMBIOS information is already encapsulated in a table, so there's no need to search through address space for a _DMI_ entry: https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 Alex
On 06/14/2018 09:13 PM, Alexander Graf wrote: > > > On 14.06.18 21:01, Simon Glass wrote: >> Hi Alex, >> >> On 14 June 2018 at 12:22, Alexander Graf <agraf@suse.de> wrote: >>> We try hard to make sure that SMBIOS tables live in the lower 32bit. >>> However, when we can not find any space at all there, we should not >>> error out but instead just fall back to map them in the full address >>> space instead. >>> >>> Signed-off-by: Alexander Graf <agraf@suse.de> >>> --- >>> lib/efi_loader/efi_smbios.c | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> Does that actually work? I thought the addresses in the table were >> always 32-bit? > > > There is only a single table reference which indeed is 32bit: > se->struct_table_address. > > That address however is unused in the EFI case usually, because the > SMBIOS information is already encapsulated in a table, so there's no > need to search through address space for a _DMI_ entry: > > https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 > > > Alex > We still have an open issue with E820 memory reservations not observed by Linux because they are not mirrored in the memory map. Could the same happen with smbios? Regards Heinrich
On 14.06.18 21:26, Heinrich Schuchardt wrote: > On 06/14/2018 09:13 PM, Alexander Graf wrote: >> >> >> On 14.06.18 21:01, Simon Glass wrote: >>> Hi Alex, >>> >>> On 14 June 2018 at 12:22, Alexander Graf <agraf@suse.de> wrote: >>>> We try hard to make sure that SMBIOS tables live in the lower 32bit. >>>> However, when we can not find any space at all there, we should not >>>> error out but instead just fall back to map them in the full address >>>> space instead. >>>> >>>> Signed-off-by: Alexander Graf <agraf@suse.de> >>>> --- >>>> lib/efi_loader/efi_smbios.c | 11 +++++++++-- >>>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> Does that actually work? I thought the addresses in the table were >>> always 32-bit? >> >> >> There is only a single table reference which indeed is 32bit: >> se->struct_table_address. >> >> That address however is unused in the EFI case usually, because the >> SMBIOS information is already encapsulated in a table, so there's no >> need to search through address space for a _DMI_ entry: >> >> https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 >> >> >> Alex >> > We still have an open issue with E820 memory reservations not observed > by Linux because they are not mirrored in the memory map. Could the same > happen with smbios? The SMBIOS tables get allocated from the EFI pool in lib/efi_loader/efi_smbios.c. So the e820 patch fell through the cracks? Alex
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c index 7c3fc8af0b..932f7582ec 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -26,8 +26,15 @@ efi_status_t efi_smbios_register(void) /* Reserve 4kiB page for SMBIOS */ ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, EFI_RUNTIME_SERVICES_DATA, 1, &dmi); - if (ret != EFI_SUCCESS) - return ret; + + if (ret != EFI_SUCCESS) { + /* Could not find space in lowmem, use highmem instead */ + ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, + EFI_RUNTIME_SERVICES_DATA, 1, &dmi); + + if (ret != EFI_SUCCESS) + return ret; + } /* * Generate SMBIOS tables - we know that efi_allocate_pages() returns
We try hard to make sure that SMBIOS tables live in the lower 32bit. However, when we can not find any space at all there, we should not error out but instead just fall back to map them in the full address space instead. Signed-off-by: Alexander Graf <agraf@suse.de> --- lib/efi_loader/efi_smbios.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)