Patchwork lib: fwts_acpi_tables: fake table start address when loading from file.

login
register
mail settings
Submitter Colin King
Date May 31, 2012, 1:12 p.m.
Message ID <1338469974-5644-2-git-send-email-colin.king@canonical.com>
Download mbox | patch
Permalink /patch/162154/
State Accepted
Headers show

Comments

Colin King - May 31, 2012, 1:12 p.m.
From: Colin Ian King <colin.king@canonical.com>

Loading dumped ACPI tables from file is problematic because we have
no idea of their original physical location.  The current situation
is that we fake their address to physical location zero, which means
the table lookup against the RSDT or XSDT produced random first come
first dumped hash table lookups since all the tables were at a fake
address zero.  The way around this is simple, it has already been solved
for loading in tables from a raw ACPI dump file with null addresses - we
just create ascending fake addresses using fwts_fake_physical_addr()
for each table being loaded.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 src/lib/src/fwts_acpi_tables.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Keng-Yu Lin - June 4, 2012, 8:37 a.m.
On Thu, May 31, 2012 at 9:12 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Loading dumped ACPI tables from file is problematic because we have
> no idea of their original physical location.  The current situation
> is that we fake their address to physical location zero, which means
> the table lookup against the RSDT or XSDT produced random first come
> first dumped hash table lookups since all the tables were at a fake
> address zero.  The way around this is simple, it has already been solved
> for loading in tables from a raw ACPI dump file with null addresses - we
> just create ascending fake addresses using fwts_fake_physical_addr()
> for each table being loaded.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>  src/lib/src/fwts_acpi_tables.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
> index f09e94c..eabc2ea 100644
> --- a/src/lib/src/fwts_acpi_tables.c
> +++ b/src/lib/src/fwts_acpi_tables.c
> @@ -469,7 +469,8 @@ static int fwts_acpi_load_tables_from_file(fwts_framework *fw)
>                                strcpy(name, direntry->d_name);
>                                name[strlen(name)-4] = '\0';
>                                if ((table = fwts_acpi_load_table_from_file(fd, &length)) != NULL)
> -                                       fwts_acpi_add_table(name, table, (uint64_t)0, length);
> +                                       fwts_acpi_add_table(name, table,
> +                                               (uint64_t)fwts_fake_physical_addr(length), length);
>                                close(fd);
>                        } else
>                                fwts_log_error(fw, "Cannot load ACPI table from file '%s'\n", path);
> --
> 1.7.9.5
>
Acked-by: Keng-Yu Lin <kengyu@canonical.com>
Alex Hung - June 11, 2012, 10:35 a.m.
On 05/31/2012 09:12 PM, Colin King wrote:
> From: Colin Ian King<colin.king@canonical.com>
>
> Loading dumped ACPI tables from file is problematic because we have
> no idea of their original physical location.  The current situation
> is that we fake their address to physical location zero, which means
> the table lookup against the RSDT or XSDT produced random first come
> first dumped hash table lookups since all the tables were at a fake
> address zero.  The way around this is simple, it has already been solved
> for loading in tables from a raw ACPI dump file with null addresses - we
> just create ascending fake addresses using fwts_fake_physical_addr()
> for each table being loaded.
>
> Signed-off-by: Colin Ian King<colin.king@canonical.com>
> ---
>   src/lib/src/fwts_acpi_tables.c |    3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
> index f09e94c..eabc2ea 100644
> --- a/src/lib/src/fwts_acpi_tables.c
> +++ b/src/lib/src/fwts_acpi_tables.c
> @@ -469,7 +469,8 @@ static int fwts_acpi_load_tables_from_file(fwts_framework *fw)
>   				strcpy(name, direntry->d_name);
>   				name[strlen(name)-4] = '\0';
>   				if ((table = fwts_acpi_load_table_from_file(fd,&length)) != NULL)
> -					fwts_acpi_add_table(name, table, (uint64_t)0, length);
> +					fwts_acpi_add_table(name, table,
> +						(uint64_t)fwts_fake_physical_addr(length), length);
>   				close(fd);
>   			} else
>   				fwts_log_error(fw, "Cannot load ACPI table from file '%s'\n", path);
Acked-by: Alex Hung <alex.hung@canonical.com>
Ivan Hu - June 11, 2012, 10:46 a.m.
On 05/31/2012 09:12 PM, Colin King wrote:
> From: Colin Ian King<colin.king@canonical.com>
>
> Loading dumped ACPI tables from file is problematic because we have
> no idea of their original physical location.  The current situation
> is that we fake their address to physical location zero, which means
> the table lookup against the RSDT or XSDT produced random first come
> first dumped hash table lookups since all the tables were at a fake
> address zero.  The way around this is simple, it has already been solved
> for loading in tables from a raw ACPI dump file with null addresses - we
> just create ascending fake addresses using fwts_fake_physical_addr()
> for each table being loaded.
>
> Signed-off-by: Colin Ian King<colin.king@canonical.com>
> ---
>   src/lib/src/fwts_acpi_tables.c |    3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
> index f09e94c..eabc2ea 100644
> --- a/src/lib/src/fwts_acpi_tables.c
> +++ b/src/lib/src/fwts_acpi_tables.c
> @@ -469,7 +469,8 @@ static int fwts_acpi_load_tables_from_file(fwts_framework *fw)
>   				strcpy(name, direntry->d_name);
>   				name[strlen(name)-4] = '\0';
>   				if ((table = fwts_acpi_load_table_from_file(fd,&length)) != NULL)
> -					fwts_acpi_add_table(name, table, (uint64_t)0, length);
> +					fwts_acpi_add_table(name, table,
> +						(uint64_t)fwts_fake_physical_addr(length), length);
>   				close(fd);
>   			} else
>   				fwts_log_error(fw, "Cannot load ACPI table from file '%s'\n", path);
Acked-by: Ivan Hu<ivan.hu@canonical.com>

Patch

diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
index f09e94c..eabc2ea 100644
--- a/src/lib/src/fwts_acpi_tables.c
+++ b/src/lib/src/fwts_acpi_tables.c
@@ -469,7 +469,8 @@  static int fwts_acpi_load_tables_from_file(fwts_framework *fw)
 				strcpy(name, direntry->d_name);
 				name[strlen(name)-4] = '\0';
 				if ((table = fwts_acpi_load_table_from_file(fd, &length)) != NULL)
-					fwts_acpi_add_table(name, table, (uint64_t)0, length);
+					fwts_acpi_add_table(name, table,
+						(uint64_t)fwts_fake_physical_addr(length), length);
 				close(fd);
 			} else
 				fwts_log_error(fw, "Cannot load ACPI table from file '%s'\n", path);