* [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-06 14:47 ` Konrad Rzeszutek Wilk
2016-07-08 9:52 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
` (19 subsequent siblings)
20 siblings, 2 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
In preparation for moving out ACPI builder make all
BIOSes call hvmloader_acpi_build_tables() instead of
calling ACPI code directly.
No functional changes.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Added last sentence to commit message
tools/firmware/hvmloader/ovmf.c | 2 +-
tools/firmware/hvmloader/rombios.c | 2 +-
tools/firmware/hvmloader/seabios.c | 2 +-
tools/firmware/hvmloader/util.c | 7 +++++++
tools/firmware/hvmloader/util.h | 4 ++++
5 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index db9fa7a..74fec56 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -125,7 +125,7 @@ static void ovmf_acpi_build_tables(void)
.dsdt_15cpu_len = 0
};
- acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
+ hvmloader_acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
}
static void ovmf_create_smbios_tables(void)
diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
index 1f15b94..1f8fc2d 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -180,7 +180,7 @@ static void rombios_acpi_build_tables(void)
.dsdt_15cpu_len = dsdt_15cpu_len,
};
- acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
+ hvmloader_acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
}
static void rombios_create_mp_tables(void)
diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
index c6b3d9f..9f66a79 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -100,7 +100,7 @@ static void seabios_acpi_build_tables(void)
.dsdt_15cpu_len = 0,
};
- acpi_build_tables(&config, rsdp);
+ hvmloader_acpi_build_tables(&config, rsdp);
add_table(rsdp);
}
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9382709..9af29b1 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -21,6 +21,7 @@
#include "config.h"
#include "hypercall.h"
#include "ctype.h"
+#include "acpi/acpi2_0.h"
#include <stdint.h>
#include <xen/xen.h>
#include <xen/memory.h>
@@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
return ((hpet_id >> 16) == 0x8086);
}
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical)
+{
+ acpi_build_tables(config, physical);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 3126817..b226df4 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -273,6 +273,10 @@ extern struct e820map memory_map;
bool check_overlap(uint64_t start, uint64_t size,
uint64_t reserved_start, uint64_t reserved_size);
+struct acpi_config;
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical);
+
#endif /* __HVMLOADER_UTIL_H__ */
/*
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
2016-07-05 19:05 ` [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
@ 2016-07-06 14:47 ` Konrad Rzeszutek Wilk
2016-07-08 9:52 ` Jan Beulich
1 sibling, 0 replies; 104+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-07-06 14:47 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Tue, Jul 05, 2016 at 03:05:00PM -0400, Boris Ostrovsky wrote:
> In preparation for moving out ACPI builder make all
> BIOSes call hvmloader_acpi_build_tables() instead of
> calling ACPI code directly.
>
> No functional changes.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>
> Changes in v1:
> * Added last sentence to commit message
>
> tools/firmware/hvmloader/ovmf.c | 2 +-
> tools/firmware/hvmloader/rombios.c | 2 +-
> tools/firmware/hvmloader/seabios.c | 2 +-
> tools/firmware/hvmloader/util.c | 7 +++++++
> tools/firmware/hvmloader/util.h | 4 ++++
> 5 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
> index db9fa7a..74fec56 100644
> --- a/tools/firmware/hvmloader/ovmf.c
> +++ b/tools/firmware/hvmloader/ovmf.c
> @@ -125,7 +125,7 @@ static void ovmf_acpi_build_tables(void)
> .dsdt_15cpu_len = 0
> };
>
> - acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> + hvmloader_acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> }
>
> static void ovmf_create_smbios_tables(void)
> diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
> index 1f15b94..1f8fc2d 100644
> --- a/tools/firmware/hvmloader/rombios.c
> +++ b/tools/firmware/hvmloader/rombios.c
> @@ -180,7 +180,7 @@ static void rombios_acpi_build_tables(void)
> .dsdt_15cpu_len = dsdt_15cpu_len,
> };
>
> - acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> + hvmloader_acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> }
>
> static void rombios_create_mp_tables(void)
> diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
> index c6b3d9f..9f66a79 100644
> --- a/tools/firmware/hvmloader/seabios.c
> +++ b/tools/firmware/hvmloader/seabios.c
> @@ -100,7 +100,7 @@ static void seabios_acpi_build_tables(void)
> .dsdt_15cpu_len = 0,
> };
>
> - acpi_build_tables(&config, rsdp);
> + hvmloader_acpi_build_tables(&config, rsdp);
> add_table(rsdp);
> }
>
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 9382709..9af29b1 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -21,6 +21,7 @@
> #include "config.h"
> #include "hypercall.h"
> #include "ctype.h"
> +#include "acpi/acpi2_0.h"
> #include <stdint.h>
> #include <xen/xen.h>
> #include <xen/memory.h>
> @@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
> return ((hpet_id >> 16) == 0x8086);
> }
>
> +void hvmloader_acpi_build_tables(struct acpi_config *config,
> + unsigned int physical)
> +{
> + acpi_build_tables(config, physical);
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 3126817..b226df4 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -273,6 +273,10 @@ extern struct e820map memory_map;
> bool check_overlap(uint64_t start, uint64_t size,
> uint64_t reserved_start, uint64_t reserved_size);
>
> +struct acpi_config;
> +void hvmloader_acpi_build_tables(struct acpi_config *config,
> + unsigned int physical);
> +
> #endif /* __HVMLOADER_UTIL_H__ */
>
> /*
> --
> 1.7.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
2016-07-05 19:05 ` [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
2016-07-06 14:47 ` Konrad Rzeszutek Wilk
@ 2016-07-08 9:52 ` Jan Beulich
1 sibling, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 9:52 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> In preparation for moving out ACPI builder make all
> BIOSes call hvmloader_acpi_build_tables() instead of
> calling ACPI code directly.
>
> No functional changes.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-07-05 19:05 ` [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-07 16:58 ` Ian Jackson
2016-07-08 10:10 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
` (18 subsequent siblings)
20 siblings, 2 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
acpi_info can be initialized by hvmloader itself. Now ACPI code
doesn't need to use hvmloader-private variables/routines such as
uart_exists(), lpt_exists() etc.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Create libacpi.h for libacpi interface definitions
* Move RSDP struct acpi_info pointers into struct acpi_config
tools/firmware/hvmloader/acpi/acpi2_0.h | 11 ----
tools/firmware/hvmloader/acpi/build.c | 48 +++---------------
tools/firmware/hvmloader/acpi/libacpi.h | 80 +++++++++++++++++++++++++++++++
tools/firmware/hvmloader/seabios.c | 1 +
tools/firmware/hvmloader/util.c | 21 ++++++++-
5 files changed, 109 insertions(+), 52 deletions(-)
create mode 100644 tools/firmware/hvmloader/acpi/libacpi.h
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 78eb43d..ddcee74 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -449,17 +449,6 @@ struct acpi_20_slit {
#define ACPI_2_0_SRAT_REVISION 0x01
#define ACPI_2_0_SLIT_REVISION 0x01
-#pragma pack ()
-
-struct acpi_config {
- unsigned char *dsdt_anycpu;
- int dsdt_anycpu_len;
- unsigned char *dsdt_15cpu;
- int dsdt_15cpu_len;
-};
-
-void acpi_build_tables(struct acpi_config *config, unsigned int physical);
-
#endif /* _ACPI_2_0_H_ */
/*
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1f7103e..1092b4e 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -16,6 +16,7 @@
*/
#include "acpi2_0.h"
+#include "libacpi.h"
#include "ssdt_s3.h"
#include "ssdt_s4.h"
#include "ssdt_tpm.h"
@@ -38,24 +39,6 @@ extern struct acpi_20_fadt Fadt;
extern struct acpi_20_facs Facs;
extern struct acpi_20_waet Waet;
-/*
- * Located at ACPI_INFO_PHYSICAL_ADDRESS.
- *
- * This must match the Field("BIOS"....) definition in the DSDT.
- */
-struct acpi_info {
- uint8_t com1_present:1; /* 0[0] - System has COM1? */
- uint8_t com2_present:1; /* 0[1] - System has COM2? */
- uint8_t lpt1_present:1; /* 0[2] - System has LPT1? */
- uint8_t hpet_present:1; /* 0[3] - System has HPET? */
- uint16_t nr_cpus; /* 2 - Number of CPUs */
- uint32_t pci_min, pci_len; /* 4, 8 - PCI I/O hole boundaries */
- uint32_t madt_csum_addr; /* 12 - Address of MADT checksum */
- uint32_t madt_lapic0_addr; /* 16 - Address of first MADT LAPIC struct */
- uint32_t vm_gid_addr; /* 20 - Address of VM generation id buffer */
- uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
-};
-
static void set_checksum(
void *table, uint32_t checksum_offset, uint32_t length)
{
@@ -358,7 +341,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* HPET. */
- if ( hpet_exists(ACPI_HPET_ADDRESS) )
+ if ( info->hpet_present )
{
hpet = construct_hpet();
if (!hpet) return -1;
@@ -493,9 +476,8 @@ static int new_vm_gid(struct acpi_info *acpi_info)
return 1;
}
-void acpi_build_tables(struct acpi_config *config, unsigned int physical)
+void acpi_build_tables(struct acpi_config *config)
{
- struct acpi_info *acpi_info;
struct acpi_20_rsdp *rsdp;
struct acpi_20_rsdt *rsdt;
struct acpi_20_xsdt *xsdt;
@@ -506,11 +488,6 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
unsigned long secondary_tables[ACPI_MAX_SECONDARY_TABLES];
int nr_secondaries, i;
- /* Allocate and initialise the acpi info area. */
- mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
- acpi_info = (struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS;
- memset(acpi_info, 0, sizeof(*acpi_info));
-
/*
* Fill in high-memory data structures, starting at @buf.
*/
@@ -570,7 +547,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_20_fadt));
- nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+ nr_secondaries = construct_secondary_tables(secondary_tables,
+ &config->ainfo);
if ( nr_secondaries < 0 )
goto oom;
@@ -603,7 +581,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
/*
* Fill in low-memory data structures: acpi_info and RSDP.
*/
- rsdp = (struct acpi_20_rsdp *)physical;
+ rsdp = (struct acpi_20_rsdp *)config->rsdp;
memcpy(rsdp, &Rsdp, sizeof(struct acpi_20_rsdp));
rsdp->rsdt_address = (unsigned long)rsdt;
@@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
offsetof(struct acpi_20_rsdp, extended_checksum),
sizeof(struct acpi_20_rsdp));
- if ( !new_vm_gid(acpi_info) )
+ if ( !new_vm_gid(&config->ainfo) )
goto oom;
- acpi_info->com1_present = uart_exists(0x3f8);
- acpi_info->com2_present = uart_exists(0x2f8);
- acpi_info->lpt1_present = lpt_exists(0x378);
- acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
- acpi_info->pci_min = pci_mem_start;
- acpi_info->pci_len = pci_mem_end - pci_mem_start;
- if ( pci_hi_mem_end > pci_hi_mem_start )
- {
- acpi_info->pci_hi_min = pci_hi_mem_start;
- acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
- }
+ *(struct acpi_info *)config->ainfop = config->ainfo;
return;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
new file mode 100644
index 0000000..098eee1
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -0,0 +1,80 @@
+/******************************************************************************
+ * libacpi.h
+ *
+ * libacpi interfaces
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+
+#ifndef __LIBACPI_H__
+#define __LIBACPI_H__
+
+#pragma pack ()
+
+/*
+ * This must match the Field("BIOS"....) definition in the DSDT.
+ */
+struct acpi_info {
+ uint8_t com1_present:1; /* 0[0] - System has COM1? */
+ uint8_t com2_present:1; /* 0[1] - System has COM2? */
+ uint8_t lpt1_present:1; /* 0[2] - System has LPT1? */
+ uint8_t hpet_present:1; /* 0[3] - System has HPET? */
+ uint16_t nr_cpus; /* 2 - Number of CPUs */
+ uint32_t pci_min, pci_len; /* 4, 8 - PCI I/O hole boundaries */
+ uint32_t madt_csum_addr; /* 12 - Address of MADT checksum */
+ uint32_t madt_lapic0_addr; /* 16 - Address of first MADT LAPIC struct */
+ uint32_t vm_gid_addr; /* 20 - Address of VM generation id buffer */
+ uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
+};
+
+struct acpi_config {
+ const unsigned char *dsdt_anycpu;
+ unsigned int dsdt_anycpu_len;
+ const unsigned char *dsdt_15cpu;
+ unsigned int dsdt_15cpu_len;
+
+ /* May have some fields updated by acpi_build_table() */
+ struct acpi_info ainfo;
+ /*
+ * Address where acpi_info should be placed.
+ * This must match the OperationRegion(BIOS, SystemMemory, ....)
+ * definition in the DSDT
+ */
+ unsigned int ainfop;
+
+ /* RSDP address */
+ unsigned int rsdp;
+};
+
+void acpi_build_tables(struct acpi_config *config);
+
+#endif /* __LIBACPI_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
index 9f66a79..2fbc3af 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -26,6 +26,7 @@
#include "smbios_types.h"
#include "acpi/acpi2_0.h"
+#include "acpi/libacpi.h"
#define ROM_INCLUDE_SEABIOS
#include "roms.inc"
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9af29b1..4293efa 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,6 +22,7 @@
#include "hypercall.h"
#include "ctype.h"
#include "acpi/acpi2_0.h"
+#include "acpi/libacpi.h"
#include <stdint.h>
#include <xen/xen.h>
#include <xen/memory.h>
@@ -860,7 +861,25 @@ int hpet_exists(unsigned long hpet_base)
void hvmloader_acpi_build_tables(struct acpi_config *config,
unsigned int physical)
{
- acpi_build_tables(config, physical);
+ /* Allocate and initialise the acpi info area. */
+ mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
+
+ config->ainfo.com1_present = uart_exists(0x3f8);
+ config->ainfo.com2_present = uart_exists(0x2f8);
+ config->ainfo.lpt1_present = lpt_exists(0x378);
+ config->ainfo.hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
+ config->ainfo.pci_min = pci_mem_start;
+ config->ainfo.pci_len = pci_mem_end - pci_mem_start;
+ if ( pci_hi_mem_end > pci_hi_mem_start )
+ {
+ config->ainfo.pci_hi_min = pci_hi_mem_start;
+ config->ainfo.pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
+ }
+
+ config->rsdp = physical;
+ config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
+
+ acpi_build_tables(config);
}
/*
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-05 19:05 ` [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
@ 2016-07-07 16:58 ` Ian Jackson
2016-07-07 17:09 ` Boris Ostrovsky
2016-07-08 10:10 ` Jan Beulich
1 sibling, 1 reply; 104+ messages in thread
From: Ian Jackson @ 2016-07-07 16:58 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
Boris Ostrovsky writes ("[PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> acpi_info can be initialized by hvmloader itself. Now ACPI code
> doesn't need to use hvmloader-private variables/routines such as
> uart_exists(), lpt_exists() etc.
...
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
...
> * Create libacpi.h for libacpi interface definitions
Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>
I'm afraid this patch contains a licence violation, contrary to your
S-O-B.
You have moved this:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
...
> -struct acpi_info {
> - uint8_t com1_present:1; /* 0[0] - System has COM1? */
> - uint8_t com2_present:1; /* 0[1] - System has COM2? */
> - uint8_t lpt1_present:1; /* 0[2] - System has LPT1? */
Into a new file:
> --- /dev/null
> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
> @@ -0,0 +1,80 @@
...
> +struct acpi_info {
> + uint8_t com1_present:1; /* 0[0] - System has COM1? */
> + uint8_t com2_present:1; /* 0[1] - System has COM2? */
> + uint8_t lpt1_present:1; /* 0[2] - System has LPT1? */
The original file has this copyright header:
/*
* Copyright (c) 2004, Intel Corporation.
* Copyright (c) 2006, Keir Fraser, XenSource Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms and conditions of the GNU General
* Public License, version 2, as published by the Free Software
* Foundation.
*
* This program is distributed in the hope it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; If not, see
* <http://www.gnu.org/licenses/>.
*/
(rewrapped for legibility). The dates haven't been updated for ages,
but this file is clearly GPLv2-only.
However your new file has this copyright header (again, wrapped);
> +/******************************************************************************
> + * libacpi.h
> + *
> + * libacpi interfaces
> + *
> + * Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + */
There are two serious problems with this.
1. You have dropped the copyright attribution to Intel and Xensource.
2. You have changed the licence to BSD-style, even though the original
was GPLv2-only.
Please be more careful!
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-07 16:58 ` Ian Jackson
@ 2016-07-07 17:09 ` Boris Ostrovsky
2016-07-07 17:15 ` Wei Liu
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-07 17:09 UTC (permalink / raw)
To: Ian Jackson
Cc: wei.liu2, andrew.cooper3, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
On 07/07/2016 12:58 PM, Ian Jackson wrote:
>
> There are two serious problems with this.
>
> 1. You have dropped the copyright attribution to Intel and Xensource.
>
> 2. You have changed the licence to BSD-style, even though the original
> was GPLv2-only.
I meant this to be a GPLv2 license. And I made the same mistake in a
couple of other files.
-boris
>
>
> Please be more careful!
>
> Thanks,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-07 17:09 ` Boris Ostrovsky
@ 2016-07-07 17:15 ` Wei Liu
2016-07-07 17:45 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-07 17:15 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, Ian Jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Thu, Jul 07, 2016 at 01:09:28PM -0400, Boris Ostrovsky wrote:
> On 07/07/2016 12:58 PM, Ian Jackson wrote:
> >
> > There are two serious problems with this.
> >
> > 1. You have dropped the copyright attribution to Intel and Xensource.
> >
> > 2. You have changed the licence to BSD-style, even though the original
> > was GPLv2-only.
>
>
> I meant this to be a GPLv2 license. And I made the same mistake in a
> couple of other files.
>
The other question is, will this GPLv2 file be linked against other
toolstack components (libxl is LGPL)? If so, how should we deal with
different licences?
Wei.
> -boris
>
>
> >
> >
> > Please be more careful!
> >
> > Thanks,
> > Ian.
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-07 17:15 ` Wei Liu
@ 2016-07-07 17:45 ` Boris Ostrovsky
2016-07-08 15:06 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-07 17:45 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, Ian Jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
On 07/07/2016 01:15 PM, Wei Liu wrote:
> On Thu, Jul 07, 2016 at 01:09:28PM -0400, Boris Ostrovsky wrote:
>> On 07/07/2016 12:58 PM, Ian Jackson wrote:
>>> There are two serious problems with this.
>>>
>>> 1. You have dropped the copyright attribution to Intel and Xensource.
>>>
>>> 2. You have changed the licence to BSD-style, even though the original
>>> was GPLv2-only.
>>
>> I meant this to be a GPLv2 license. And I made the same mistake in a
>> couple of other files.
>>
> The other question is, will this GPLv2 file be linked against other
> toolstack components (libxl is LGPL)? If so, how should we deal with
> different licences?
Two new libxl files will be LGPL and but libacpi files will be GPLv2
(because most of the files there are already GPLv2, I just added a
couple of new ones).
Which would mean that a non-GPL users cannot link against libxl anymore,
right?
-boris
>
> Wei.
>
>> -boris
>>
>>
>>>
>>> Please be more careful!
>>>
>>> Thanks,
>>> Ian.
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-07 17:45 ` Boris Ostrovsky
@ 2016-07-08 15:06 ` Konrad Rzeszutek Wilk
2016-07-08 15:50 ` Ian Jackson
0 siblings, 1 reply; 104+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-07-08 15:06 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, Ian Jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Thu, Jul 07, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> On 07/07/2016 01:15 PM, Wei Liu wrote:
> > On Thu, Jul 07, 2016 at 01:09:28PM -0400, Boris Ostrovsky wrote:
> >> On 07/07/2016 12:58 PM, Ian Jackson wrote:
> >>> There are two serious problems with this.
> >>>
> >>> 1. You have dropped the copyright attribution to Intel and Xensource.
> >>>
> >>> 2. You have changed the licence to BSD-style, even though the original
> >>> was GPLv2-only.
> >>
> >> I meant this to be a GPLv2 license. And I made the same mistake in a
> >> couple of other files.
> >>
> > The other question is, will this GPLv2 file be linked against other
> > toolstack components (libxl is LGPL)? If so, how should we deal with
> > different licences?
>
> Two new libxl files will be LGPL and but libacpi files will be GPLv2
> (because most of the files there are already GPLv2, I just added a
> couple of new ones).
>
> Which would mean that a non-GPL users cannot link against libxl anymore,
> right?
Having different licenses will invite the lawyers in the conversation
which can drag things out.
A quick read says one can add an exception to GPLv2 license to allow it
to be linked (see https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs)
but that would require Copyright OK from the original holders.
It would be far easier to ask the copyright holders:
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
David Vrabel <david.vrabel@citrix.com>
Dexuan Cui <dexuan.cui@intel.com>
Eddie Dong <eddie.dong@intel.com>
Ian Campbell <ian.campbell@citrix.com>
John Levon <john.levon@sun.com>
Keir Fraser <keir@xen.org>
Keir Fraser <keir@xensource.com>
Liu, Jinsong <jinsong.liu@intel.com>
Paul Durrant <paul.durrant@citrix.com>
Qing He <qing.he@intel.com>
Stefan Berger <stefanb@us.ibm.com>
Tim Deegan <Tim.Deegan@citrix.com>
Tobias Geiger <tobias.geiger@vido.info>
Xiaowei Yang <xiaowei.yang@intel.com>
If they would be OK making the code (this is from
tools/firmware/hvmloader/acpi/acpi2_0.h) lGPL.
Or is there some other technical way around this?
I can't recall whether the 'dlopen' (so runtime loading
vs linking) of an GPL library is from Lesser GPL is OK.
(so proprietary code linking with libxl, and libxl dlopen'ing
the libacpi code').
Sounds like we may need to consult the lawyers after all.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 15:06 ` Konrad Rzeszutek Wilk
@ 2016-07-08 15:50 ` Ian Jackson
2016-07-08 15:57 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Ian Jackson @ 2016-07-08 15:50 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, andrew.cooper3, xen-devel, julien.grall, jbeulich,
zhaoshenglong, Boris Ostrovsky, roger.pau
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> Having different licenses will invite the lawyers in the conversation
> which can drag things out.
We don't want libxl to have some confusing combination of
alleged-licences.
> A quick read says one can add an exception to GPLv2 license to allow it
> to be linked (see https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs)
> but that would require Copyright OK from the original holders.
>
> It would be far easier to ask the copyright holders:
Yes. That seems to be Citrix, Intel, Sun (Oracle), IBM, and:
> Tobias Geiger <tobias.geiger@vido.info>
>
> If they would be OK making the code (this is from
> tools/firmware/hvmloader/acpi/acpi2_0.h) lGPL.
Right.
> Or is there some other technical way around this?
No.
> I can't recall whether the 'dlopen' (so runtime loading
> vs linking) of an GPL library is from Lesser GPL is OK.
> (so proprietary code linking with libxl, and libxl dlopen'ing
> the libacpi code').
This kind of attempt at licence workaround by some kind of technical
bodge is not legally effective.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 15:50 ` Ian Jackson
@ 2016-07-08 15:57 ` Boris Ostrovsky
2016-07-08 16:21 ` Ian Jackson
2016-07-11 12:10 ` Wei Liu
0 siblings, 2 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 15:57 UTC (permalink / raw)
To: Ian Jackson, Konrad Rzeszutek Wilk
Cc: Wei Liu, andrew.cooper3, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
On 07/08/2016 11:50 AM, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
>> Having different licenses will invite the lawyers in the conversation
>> which can drag things out.
> We don't want libxl to have some confusing combination of
> alleged-licences.
>
>> A quick read says one can add an exception to GPLv2 license to allow it
>> to be linked (see https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs)
>> but that would require Copyright OK from the original holders.
>>
>> It would be far easier to ask the copyright holders:
> Yes. That seems to be Citrix, Intel, Sun (Oracle), IBM, and:
>
>> Tobias Geiger <tobias.geiger@vido.info>
Do we need to get consent from companies only or (also) from individuals
listed in the files? Which means Keir and Kamala Narasimhan (who works,
or at least used to work) for Citrix.
For IBM --- whom can we contact?
>>
>> If they would be OK making the code (this is from
>> tools/firmware/hvmloader/acpi/acpi2_0.h) lGPL.
> Right.
>
>> Or is there some other technical way around this?
> No.
>
>> I can't recall whether the 'dlopen' (so runtime loading
>> vs linking) of an GPL library is from Lesser GPL is OK.
>> (so proprietary code linking with libxl, and libxl dlopen'ing
>> the libacpi code').
> This kind of attempt at licence workaround by some kind of technical
> bodge is not legally effective.
We don't build files in libacpi as a dynamic library. The object files
are linked against whoever wants to use the functionality, just like
what we do for libelf.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 15:57 ` Boris Ostrovsky
@ 2016-07-08 16:21 ` Ian Jackson
2016-07-11 12:10 ` Wei Liu
1 sibling, 0 replies; 104+ messages in thread
From: Ian Jackson @ 2016-07-08 16:21 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> Do we need to get consent from companies only or (also) from individuals
> listed in the files? Which means Keir and Kamala Narasimhan (who works,
> or at least used to work) for Citrix.
Where the people were doing the work as part of their employemnt we
need consent only from their employer.
I confess I didn't check the dates of Keir's contributions but they
probably postdate his employment by XenSource.
> For IBM --- whom can we contact?
The named person is probably the first point of contact.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 15:57 ` Boris Ostrovsky
2016-07-08 16:21 ` Ian Jackson
@ 2016-07-11 12:10 ` Wei Liu
2016-07-11 14:47 ` Lars Kurth
1 sibling, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-11 12:10 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, lars.kurth.xen, andrew.cooper3, Ian Jackson, xen-devel,
julien.grall, jbeulich, zhaoshenglong, roger.pau
CC Lars
More licence stuff. Do you have contact(s)?
Wei.
On Fri, Jul 08, 2016 at 11:57:59AM -0400, Boris Ostrovsky wrote:
> On 07/08/2016 11:50 AM, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> >> Having different licenses will invite the lawyers in the conversation
> >> which can drag things out.
> > We don't want libxl to have some confusing combination of
> > alleged-licences.
> >
> >> A quick read says one can add an exception to GPLv2 license to allow it
> >> to be linked (see https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs)
> >> but that would require Copyright OK from the original holders.
> >>
> >> It would be far easier to ask the copyright holders:
> > Yes. That seems to be Citrix, Intel, Sun (Oracle), IBM, and:
> >
> >> Tobias Geiger <tobias.geiger@vido.info>
>
>
> Do we need to get consent from companies only or (also) from individuals
> listed in the files? Which means Keir and Kamala Narasimhan (who works,
> or at least used to work) for Citrix.
>
> For IBM --- whom can we contact?
>
> >>
> >> If they would be OK making the code (this is from
> >> tools/firmware/hvmloader/acpi/acpi2_0.h) lGPL.
> > Right.
> >
> >> Or is there some other technical way around this?
> > No.
> >
> >> I can't recall whether the 'dlopen' (so runtime loading
> >> vs linking) of an GPL library is from Lesser GPL is OK.
> >> (so proprietary code linking with libxl, and libxl dlopen'ing
> >> the libacpi code').
> > This kind of attempt at licence workaround by some kind of technical
> > bodge is not legally effective.
>
> We don't build files in libacpi as a dynamic library. The object files
> are linked against whoever wants to use the functionality, just like
> what we do for libelf.
>
> -boris
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 12:10 ` Wei Liu
@ 2016-07-11 14:47 ` Lars Kurth
2016-07-11 14:54 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 104+ messages in thread
From: Lars Kurth @ 2016-07-11 14:47 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, Ian Jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, Boris Ostrovsky, roger.pau
> On 11 Jul 2016, at 13:10, Wei Liu <wei.liu2@citrix.com> wrote:
>
> CC Lars
>
> More licence stuff. Do you have contact(s)?
James (on vacation) or I can confirm on behalf of Citrix.
I am assuming that Konrad can get the approval for Sun/Oracle
As for Intel, we can ask Susie Li. It would have to be a Intel decision because many of the people on that list are not working for Intel anymore.
We should probably double check the dates of Keir's contributions: getting his explicit ACK is most likely not an issue
According to LinkedIn, Stefan Berger still works for IBM.
And a quick google search for Tobias Geiger's e-mail address and 2016 shows that the e-mail address was last used a month ago.
> It would be far easier to ask the copyright holders:
>
> Andrew Cooper <andrew.cooper3@citrix.com>
> Anthony PERARD <anthony.perard@citrix.com>
> David Vrabel <david.vrabel@citrix.com>
> Dexuan Cui <dexuan.cui@intel.com>
> Eddie Dong <eddie.dong@intel.com>
> Ian Campbell <ian.campbell@citrix.com>
> John Levon <john.levon@sun.com>
> Keir Fraser <keir@xen.org>
> Keir Fraser <keir@xensource.com>
> Liu, Jinsong <jinsong.liu@intel.com>
> Paul Durrant <paul.durrant@citrix.com>
> Qing He <qing.he@intel.com>
> Stefan Berger <stefanb@us.ibm.com>
> Tim Deegan <Tim.Deegan@citrix.com>
> Tobias Geiger <tobias.geiger@vido.info>
> Xiaowei Yang <xiaowei.yang@intel.com>
How was this list established? I get a different set of names for both
build.c http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/build.c
acpi2_0.h http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/acpi2_0.h
Or did I miss anything?
Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 14:47 ` Lars Kurth
@ 2016-07-11 14:54 ` Konrad Rzeszutek Wilk
2016-07-11 15:06 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-07-11 14:54 UTC (permalink / raw)
To: Lars Kurth
Cc: Wei Liu, andrew.cooper3, Ian Jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, Boris Ostrovsky, roger.pau
On Mon, Jul 11, 2016 at 03:47:20PM +0100, Lars Kurth wrote:
>
> > On 11 Jul 2016, at 13:10, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > CC Lars
> >
> > More licence stuff. Do you have contact(s)?
>
> James (on vacation) or I can confirm on behalf of Citrix.
> I am assuming that Konrad can get the approval for Sun/Oracle
> As for Intel, we can ask Susie Li. It would have to be a Intel decision because many of the people on that list are not working for Intel anymore.
>
> We should probably double check the dates of Keir's contributions: getting his explicit ACK is most likely not an issue
>
> According to LinkedIn, Stefan Berger still works for IBM.
> And a quick google search for Tobias Geiger's e-mail address and 2016 shows that the e-mail address was last used a month ago.
>
> > It would be far easier to ask the copyright holders:
> >
> > Andrew Cooper <andrew.cooper3@citrix.com>
> > Anthony PERARD <anthony.perard@citrix.com>
> > David Vrabel <david.vrabel@citrix.com>
> > Dexuan Cui <dexuan.cui@intel.com>
> > Eddie Dong <eddie.dong@intel.com>
> > Ian Campbell <ian.campbell@citrix.com>
> > John Levon <john.levon@sun.com>
> > Keir Fraser <keir@xen.org>
> > Keir Fraser <keir@xensource.com>
> > Liu, Jinsong <jinsong.liu@intel.com>
> > Paul Durrant <paul.durrant@citrix.com>
> > Qing He <qing.he@intel.com>
> > Stefan Berger <stefanb@us.ibm.com>
> > Tim Deegan <Tim.Deegan@citrix.com>
> > Tobias Geiger <tobias.geiger@vido.info>
> > Xiaowei Yang <xiaowei.yang@intel.com>
>
> How was this list established? I get a different set of names for both
> build.c http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/build.c
> acpi2_0.h http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/acpi2_0.h
>
> Or did I miss anything?
I did:
git log tools/firmware/hvmloader/acpi/acpi2_0.h | grep \@ | sed s/.*:// | sort | uniq
And removed the duplicate entries.
But hadn't done the build.c which has:
[konrad@char xen]$ git log tools/firmware/hvmloader/acpi/build.c | grep \@ | sed s/.*:// | sort | uniq
Adnan Misherfi <adnan.misherfi@oracle.com>
Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD <anthony.perard@citrix.com>
Atsushi SAKAI <sakaia@jp.fujitsu.com>
Christoph Egger <Christoph.Egger@amd.com>
Dan Magenheimer <dan.magenheimer@oracle.com>
David Vrabel <david.vrabel@citrix.com
David Vrabel <david.vrabel@citrix.com>
Dexuan Cui <dexuan.cui@intel.com>
Eddie Dong <eddie.dong@intel.com>
Frediano Ziglio <frediano.ziglio@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
kaf24@localhost.localdomain <kaf24@localhost.localdomain>
Kamala Narasimhan <kamala.narasimhan@citrix.com>
Keir Fraser <keir.fraser@citrix.com>
Keir Fraser <keir.xen@gmail.com>
Keir Fraser <keir@xen.org>
Keir Fraser <keir@xensource.com>
kfraser@localhost.localdomain <kfraser@localhost.localdomain>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Liu, Jinsong <jinsong.liu@intel.com>
Paolo Bonzini <pbonzini@redhat.com>
Paul Durrant <paul.durrant@citrix.com>
Qing He <qing.he@intel.com>
Ross Philipson <ross.philipson@citrix.com>
Samuel Thibault <samuel.thibault@eu.citrix.com>
Trolle Selander <trolle.selander@eu.citrix.com>
Xiaowei Yang <xiaowei.yang@intel.com>
Thought http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=883236e49a86a0174c6df61cac995ebf16d72b35
shows that the file was moved, and I hadn't taken that into account.
So would need to look even further back under a different directory.
>
> Regards
> Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 14:54 ` Konrad Rzeszutek Wilk
@ 2016-07-11 15:06 ` Boris Ostrovsky
2016-07-11 15:38 ` Ian Jackson
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-11 15:06 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Lars Kurth
Cc: Wei Liu, andrew.cooper3, Ian Jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On 07/11/2016 10:54 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 11, 2016 at 03:47:20PM +0100, Lars Kurth wrote:
>>> On 11 Jul 2016, at 13:10, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>> CC Lars
>>>
>>> More licence stuff. Do you have contact(s)?
>> James (on vacation) or I can confirm on behalf of Citrix.
>> I am assuming that Konrad can get the approval for Sun/Oracle
>> As for Intel, we can ask Susie Li. It would have to be a Intel decision because many of the people on that list are not working for Intel anymore.
>>
>> We should probably double check the dates of Keir's contributions: getting his explicit ACK is most likely not an issue
>>
>> According to LinkedIn, Stefan Berger still works for IBM.
>> And a quick google search for Tobias Geiger's e-mail address and 2016 shows that the e-mail address was last used a month ago.
>>
>>> It would be far easier to ask the copyright holders:
>>>
>>> Andrew Cooper <andrew.cooper3@citrix.com>
>>> Anthony PERARD <anthony.perard@citrix.com>
>>> David Vrabel <david.vrabel@citrix.com>
>>> Dexuan Cui <dexuan.cui@intel.com>
>>> Eddie Dong <eddie.dong@intel.com>
>>> Ian Campbell <ian.campbell@citrix.com>
>>> John Levon <john.levon@sun.com>
>>> Keir Fraser <keir@xen.org>
>>> Keir Fraser <keir@xensource.com>
>>> Liu, Jinsong <jinsong.liu@intel.com>
>>> Paul Durrant <paul.durrant@citrix.com>
>>> Qing He <qing.he@intel.com>
>>> Stefan Berger <stefanb@us.ibm.com>
>>> Tim Deegan <Tim.Deegan@citrix.com>
>>> Tobias Geiger <tobias.geiger@vido.info>
>>> Xiaowei Yang <xiaowei.yang@intel.com>
>> How was this list established? I get a different set of names for both
>> build.c http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/build.c
>> acpi2_0.h http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=tools/firmware/hvmloader/acpi/acpi2_0.h
>>
>> Or did I miss anything?
> I did:
>
> git log tools/firmware/hvmloader/acpi/acpi2_0.h | grep \@ | sed s/.*:// | sort | uniq
> And removed the duplicate entries.
>
> But hadn't done the build.c which has:
>
> [konrad@char xen]$ git log tools/firmware/hvmloader/acpi/build.c | grep \@ | sed s/.*:// | sort | uniq
> Adnan Misherfi <adnan.misherfi@oracle.com>
> Andrew Cooper <andrew.cooper3@citrix.com>
> Anthony PERARD <anthony.perard@citrix.com>
> Atsushi SAKAI <sakaia@jp.fujitsu.com>
> Christoph Egger <Christoph.Egger@amd.com>
> Dan Magenheimer <dan.magenheimer@oracle.com>
> David Vrabel <david.vrabel@citrix.com
> David Vrabel <david.vrabel@citrix.com>
> Dexuan Cui <dexuan.cui@intel.com>
> Eddie Dong <eddie.dong@intel.com>
> Frediano Ziglio <frediano.ziglio@citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Jan Beulich <jbeulich@suse.com>
> kaf24@localhost.localdomain <kaf24@localhost.localdomain>
> Kamala Narasimhan <kamala.narasimhan@citrix.com>
> Keir Fraser <keir.fraser@citrix.com>
> Keir Fraser <keir.xen@gmail.com>
> Keir Fraser <keir@xen.org>
> Keir Fraser <keir@xensource.com>
> kfraser@localhost.localdomain <kfraser@localhost.localdomain>
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Liu, Jinsong <jinsong.liu@intel.com>
> Paolo Bonzini <pbonzini@redhat.com>
> Paul Durrant <paul.durrant@citrix.com>
> Qing He <qing.he@intel.com>
> Ross Philipson <ross.philipson@citrix.com>
> Samuel Thibault <samuel.thibault@eu.citrix.com>
> Trolle Selander <trolle.selander@eu.citrix.com>
> Xiaowei Yang <xiaowei.yang@intel.com>
>
>
> Thought http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=883236e49a86a0174c6df61cac995ebf16d72b35
> shows that the file was moved, and I hadn't taken that into account.
>
> So would need to look even further back under a different directory.
But do we need to look at who touched the file or who is explicitly
listed as copyright holder (in files' headers)?
So I did (because I thought only Signed-off might important, is it?)
ostr@workbase> git log . | grep Signed | sed -e 's/.*@/ /g' | sort | uniq
citrix.com
citrix.com>
debian.org>
eu.citrix.com>
intel.com>
jp.fujitsu.com>
net-space.pl>
novell.com>
oracle.com>
redhat.com>
sun.com>
suse.com>
us.ibm.com>
verge.net.au>
xen.org>
xensource.com>
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 15:06 ` Boris Ostrovsky
@ 2016-07-11 15:38 ` Ian Jackson
2016-07-11 15:47 ` Ian Jackson
2016-07-11 16:07 ` Boris Ostrovsky
0 siblings, 2 replies; 104+ messages in thread
From: Ian Jackson @ 2016-07-11 15:38 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, Lars Kurth, andrew.cooper3, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> But do we need to look at who touched the file or who is explicitly
> listed as copyright holder (in files' headers)?
You need to look at the history.
Sadly, we don't have any means of keeping the copyright headers up to
date with lists of contributors.
> So I did (because I thought only Signed-off might important, is it?)
No. In general I think From: is probably more relevant but I would
include both From: and S-o-b:.
If there are edge cases that crop up only once or twice they could be
excluded.
> ostr@workbase> git log . | grep Signed | sed -e 's/.*@/ /g' | sort | uniq
> citrix.com
> citrix.com>
> debian.org>
> eu.citrix.com>
> intel.com>
> jp.fujitsu.com>
> net-space.pl>
> novell.com>
> oracle.com>
> redhat.com>
> sun.com>
> suse.com>
> us.ibm.com>
> verge.net.au>
> xen.org>
> xensource.com>
That's a useful list.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 15:38 ` Ian Jackson
@ 2016-07-11 15:47 ` Ian Jackson
2016-07-11 16:07 ` Boris Ostrovsky
1 sibling, 0 replies; 104+ messages in thread
From: Ian Jackson @ 2016-07-11 15:47 UTC (permalink / raw)
To: Boris Ostrovsky, Konrad Rzeszutek Wilk, Lars Kurth, Wei Liu,
andrew.cooper3, xen-devel, julien.grall, jbeulich, zhaoshenglong,
roger.pau
Ian Jackson writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
> > But do we need to look at who touched the file or who is explicitly
> > listed as copyright holder (in files' headers)?
>
> You need to look at the history.
>
> Sadly, we don't have any means of keeping the copyright headers up to
> date with lists of contributors.
Wait a moment, Lars points out that you are moving only certain bits
of these files into libxl.
Only the authorship of the moved parts is relevant.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-11 15:38 ` Ian Jackson
2016-07-11 15:47 ` Ian Jackson
@ 2016-07-11 16:07 ` Boris Ostrovsky
1 sibling, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-11 16:07 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, Lars Kurth, andrew.cooper3, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On 07/11/2016 11:38 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code"):
>> But do we need to look at who touched the file or who is explicitly
>> listed as copyright holder (in files' headers)?
> You need to look at the history.
>
> Sadly, we don't have any means of keeping the copyright headers up to
> date with lists of contributors.
>
>> So I did (because I thought only Signed-off might important, is it?)
> No. In general I think From: is probably more relevant but I would
> include both From: and S-o-b:.
>
> If there are edge cases that crop up only once or twice they could be
> excluded.
OK, then with contribution count:
ostr@workbase> git log . | egrep "Signed|From" | sed -e 's/.*@/ /g' |
sort | uniq -c
1 citrix.com
73 citrix.com>
1 debian.org>
5 eu.citrix.com>
18 intel.com>
2 jp.fujitsu.com>
1 net-space.pl>
1 novell.com>
1 oracle.com>
1 redhat.com>
1 sun.com>
8 suse.com>
1 us.ibm.com>
6 verge.net.au>
4 xen.org>
25 xensource.com>
debian.com is a single trivial patch:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a
fujitsu is one trivial and one somewhat less trivial
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407
net-space.pl is Daniel Kiper (who is at Oracle now)
redhat is one simple patch (that has been reverted):
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e
ibm is one significant patch:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737
verge is a bunch of patches by Simon Horman who probably still is at
that address (I see a message from him on the list from lat December)
xensource and xen.org tags are all from Keir.
So it seems that we need to get permission to convert GPLv2 to LGPL from
Citrix
Intel
Suse/Novell
Oracle/Sun
Simon Horman/Verge
Keir (his commits signed from @xen.org are all from 2011, I don't know
whether that was still while he was at Citrix/Xensource)
+maybe IBM.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-05 19:05 ` [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
2016-07-07 16:58 ` Ian Jackson
@ 2016-07-08 10:10 ` Jan Beulich
2016-07-08 14:39 ` Boris Ostrovsky
1 sibling, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 10:10 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -449,17 +449,6 @@ struct acpi_20_slit {
> #define ACPI_2_0_SRAT_REVISION 0x01
> #define ACPI_2_0_SLIT_REVISION 0x01
>
> -#pragma pack ()
This must not be removed from here.
> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
> offsetof(struct acpi_20_rsdp, extended_checksum),
> sizeof(struct acpi_20_rsdp));
>
> - if ( !new_vm_gid(acpi_info) )
> + if ( !new_vm_gid(&config->ainfo) )
> goto oom;
>
> - acpi_info->com1_present = uart_exists(0x3f8);
> - acpi_info->com2_present = uart_exists(0x2f8);
> - acpi_info->lpt1_present = lpt_exists(0x378);
> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
> - acpi_info->pci_min = pci_mem_start;
> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
> - if ( pci_hi_mem_end > pci_hi_mem_start )
> - {
> - acpi_info->pci_hi_min = pci_hi_mem_start;
> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
> - }
> + *(struct acpi_info *)config->ainfop = config->ainfo;
With your new separation of responsibilities - does this really
belong here rather than in the caller? And if it is to stay here, then
I think the pointer field should be made of pointer type, leaving it
to the caller to do whatever casting is necessary when filling in that
field.
> --- /dev/null
> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
> @@ -0,0 +1,80 @@
> +/******************************************************************************
> + * libacpi.h
> + *
> + * libacpi interfaces
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + */
> +
> +
> +#ifndef __LIBACPI_H__
> +#define __LIBACPI_H__
> +
> +#pragma pack ()
I guess this is going to be unneeded once the removal from acpi2_0.h
gets undone?
> +/*
> + * This must match the Field("BIOS"....) definition in the DSDT.
> + */
This is a single line comment. And considering what this comment
says I wonder whether the following structure definition wouldn't
better be wrapped in a #pragma pack(1) / #pragma pack() pair,
with ...
> +struct acpi_info {
> + uint8_t com1_present:1; /* 0[0] - System has COM1? */
> + uint8_t com2_present:1; /* 0[1] - System has COM2? */
> + uint8_t lpt1_present:1; /* 0[2] - System has LPT1? */
> + uint8_t hpet_present:1; /* 0[3] - System has HPET? */
explicit (unnamed) padding added here.
> +struct acpi_config {
> + const unsigned char *dsdt_anycpu;
> + unsigned int dsdt_anycpu_len;
> + const unsigned char *dsdt_15cpu;
> + unsigned int dsdt_15cpu_len;
> +
> + /* May have some fields updated by acpi_build_table() */
> + struct acpi_info ainfo;
> + /*
> + * Address where acpi_info should be placed.
> + * This must match the OperationRegion(BIOS, SystemMemory, ....)
> + * definition in the DSDT
> + */
> + unsigned int ainfop;
What is the "a" prefix of these two fields good for? Considering the
name of the structure I don't see a need for any prefix. But if you
absolutely want one, then acpi_ please.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 10:10 ` Jan Beulich
@ 2016-07-08 14:39 ` Boris Ostrovsky
2016-07-08 15:11 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 14:39 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 06:10 AM, Jan Beulich wrote:
>
>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>> offsetof(struct acpi_20_rsdp, extended_checksum),
>> sizeof(struct acpi_20_rsdp));
>>
>> - if ( !new_vm_gid(acpi_info) )
>> + if ( !new_vm_gid(&config->ainfo) )
>> goto oom;
>>
>> - acpi_info->com1_present = uart_exists(0x3f8);
>> - acpi_info->com2_present = uart_exists(0x2f8);
>> - acpi_info->lpt1_present = lpt_exists(0x378);
>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>> - acpi_info->pci_min = pci_mem_start;
>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>> - {
>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>> - }
>> + *(struct acpi_info *)config->ainfop = config->ainfo;
> With your new separation of responsibilities - does this really
> belong here rather than in the caller?
I think it should be done here: when the call returns all tables are
already in memory. If the caller wants to load those tables separately
(as probably the toolstack will) then it can simply copy it as a blob.
>
>> +struct acpi_config {
>> + const unsigned char *dsdt_anycpu;
>> + unsigned int dsdt_anycpu_len;
>> + const unsigned char *dsdt_15cpu;
>> + unsigned int dsdt_15cpu_len;
>> +
>> + /* May have some fields updated by acpi_build_table() */
>> + struct acpi_info ainfo;
>> + /*
>> + * Address where acpi_info should be placed.
>> + * This must match the OperationRegion(BIOS, SystemMemory, ....)
>> + * definition in the DSDT
>> + */
>> + unsigned int ainfop;
> What is the "a" prefix of these two fields good for? Considering the
> name of the structure I don't see a need for any prefix. But if you
> absolutely want one, then acpi_ please.
You requested 'acpi_' prefix to be dropped earlier. I added 'a' (and
'pt_' in patch 5) to be a bit more cscope-friendly: names like info,
addr and length will result in lots of unnecessary hits.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 14:39 ` Boris Ostrovsky
@ 2016-07-08 15:11 ` Jan Beulich
2016-07-08 16:14 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 15:11 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 08.07.16 at 16:39, <boris.ostrovsky@oracle.com> wrote:
> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>
>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
> unsigned int physical)
>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>> sizeof(struct acpi_20_rsdp));
>>>
>>> - if ( !new_vm_gid(acpi_info) )
>>> + if ( !new_vm_gid(&config->ainfo) )
>>> goto oom;
>>>
>>> - acpi_info->com1_present = uart_exists(0x3f8);
>>> - acpi_info->com2_present = uart_exists(0x2f8);
>>> - acpi_info->lpt1_present = lpt_exists(0x378);
>>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>>> - acpi_info->pci_min = pci_mem_start;
>>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>>> - {
>>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>>> - }
>>> + *(struct acpi_info *)config->ainfop = config->ainfo;
>> With your new separation of responsibilities - does this really
>> belong here rather than in the caller?
>
> I think it should be done here: when the call returns all tables are
> already in memory. If the caller wants to load those tables separately
> (as probably the toolstack will) then it can simply copy it as a blob.
But this structure isn't part of the ACPI tables, and by not doing
it here (a) at least some of the intended callers may be able to
get away without the ugly cast and (b) the field now named
ainfop wouldn't be needed either afaict.
>>> +struct acpi_config {
>>> + const unsigned char *dsdt_anycpu;
>>> + unsigned int dsdt_anycpu_len;
>>> + const unsigned char *dsdt_15cpu;
>>> + unsigned int dsdt_15cpu_len;
>>> +
>>> + /* May have some fields updated by acpi_build_table() */
>>> + struct acpi_info ainfo;
>>> + /*
>>> + * Address where acpi_info should be placed.
>>> + * This must match the OperationRegion(BIOS, SystemMemory, ....)
>>> + * definition in the DSDT
>>> + */
>>> + unsigned int ainfop;
>> What is the "a" prefix of these two fields good for? Considering the
>> name of the structure I don't see a need for any prefix. But if you
>> absolutely want one, then acpi_ please.
>
> You requested 'acpi_' prefix to be dropped earlier. I added 'a' (and
> 'pt_' in patch 5) to be a bit more cscope-friendly: names like info,
> addr and length will result in lots of unnecessary hits.
I remember having that discussion once with Mukesh too. I continue
to think source code should not get uglified just because of some
random tool's limitations, maybe unless _everyone_ uses that tool.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 15:11 ` Jan Beulich
@ 2016-07-08 16:14 ` Boris Ostrovsky
2016-08-01 10:09 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 16:14 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 11:11 AM, Jan Beulich wrote:
>>>> On 08.07.16 at 16:39, <boris.ostrovsky@oracle.com> wrote:
>> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
>> unsigned int physical)
>>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>>> sizeof(struct acpi_20_rsdp));
>>>>
>>>> - if ( !new_vm_gid(acpi_info) )
>>>> + if ( !new_vm_gid(&config->ainfo) )
>>>> goto oom;
>>>>
>>>> - acpi_info->com1_present = uart_exists(0x3f8);
>>>> - acpi_info->com2_present = uart_exists(0x2f8);
>>>> - acpi_info->lpt1_present = lpt_exists(0x378);
>>>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>>>> - acpi_info->pci_min = pci_mem_start;
>>>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>>>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>>>> - {
>>>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>>>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>>>> - }
>>>> + *(struct acpi_info *)config->ainfop = config->ainfo;
>>> With your new separation of responsibilities - does this really
>>> belong here rather than in the caller?
>> I think it should be done here: when the call returns all tables are
>> already in memory. If the caller wants to load those tables separately
>> (as probably the toolstack will) then it can simply copy it as a blob.
> But this structure isn't part of the ACPI tables, and by not doing
> it here (a) at least some of the intended callers may be able to
> get away without the ugly cast and (b) the field now named
> ainfop wouldn't be needed either afaict.
I probably didn't use right terminology. This is not a table, but an AML
piece? In any case, it's something that is ACPI-specific and I was
hoping we wouldn't need to expose this to the caller. The fact that it
is passed in the right format in struct acpi_info is a happy
coincidence. We may change it in the future (and so perhaps I should
drop the comment in libacpi.h about "This must match the
Field("BIOS"....) definition in the DSDT.")
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-07-08 16:14 ` Boris Ostrovsky
@ 2016-08-01 10:09 ` Jan Beulich
2016-08-01 14:06 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-08-01 10:09 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 08.07.16 at 18:14, <boris.ostrovsky@oracle.com> wrote:
> On 07/08/2016 11:11 AM, Jan Beulich wrote:
>>>>> On 08.07.16 at 16:39, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
>>> unsigned int physical)
>>>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>>>> sizeof(struct acpi_20_rsdp));
>>>>>
>>>>> - if ( !new_vm_gid(acpi_info) )
>>>>> + if ( !new_vm_gid(&config->ainfo) )
>>>>> goto oom;
>>>>>
>>>>> - acpi_info->com1_present = uart_exists(0x3f8);
>>>>> - acpi_info->com2_present = uart_exists(0x2f8);
>>>>> - acpi_info->lpt1_present = lpt_exists(0x378);
>>>>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>>>>> - acpi_info->pci_min = pci_mem_start;
>>>>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>>>>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>>>>> - {
>>>>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>>>>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>>>>> - }
>>>>> + *(struct acpi_info *)config->ainfop = config->ainfo;
>>>> With your new separation of responsibilities - does this really
>>>> belong here rather than in the caller?
>>> I think it should be done here: when the call returns all tables are
>>> already in memory. If the caller wants to load those tables separately
>>> (as probably the toolstack will) then it can simply copy it as a blob.
>> But this structure isn't part of the ACPI tables, and by not doing
>> it here (a) at least some of the intended callers may be able to
>> get away without the ugly cast and (b) the field now named
>> ainfop wouldn't be needed either afaict.
>
>
> I probably didn't use right terminology. This is not a table, but an AML
> piece?
Clearly not. This is data structure we define ourselves, which only
gets used by AML code.
> In any case, it's something that is ACPI-specific and I was
> hoping we wouldn't need to expose this to the caller.
That would imo be a relevant argument only if the structure
type was indeed private to a single (sub-)component.
> The fact that it
> is passed in the right format in struct acpi_info is a happy
> coincidence. We may change it in the future (and so perhaps I should
> drop the comment in libacpi.h about "This must match the
> Field("BIOS"....) definition in the DSDT.")
Definitely not: The two absolutely have to remain in sync. They're
C and AML representations of the same thing.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-08-01 10:09 ` Jan Beulich
@ 2016-08-01 14:06 ` Boris Ostrovsky
2016-08-01 14:18 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-08-01 14:06 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 08/01/2016 06:09 AM, Jan Beulich wrote:
>>>> On 08.07.16 at 18:14, <boris.ostrovsky@oracle.com> wrote:
>> On 07/08/2016 11:11 AM, Jan Beulich wrote:
>>>>>> On 08.07.16 at 16:39, <boris.ostrovsky@oracle.com> wrote:
>>>> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>>>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
>>>> unsigned int physical)
>>>>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>>>>> sizeof(struct acpi_20_rsdp));
>>>>>>
>>>>>> - if ( !new_vm_gid(acpi_info) )
>>>>>> + if ( !new_vm_gid(&config->ainfo) )
>>>>>> goto oom;
>>>>>>
>>>>>> - acpi_info->com1_present = uart_exists(0x3f8);
>>>>>> - acpi_info->com2_present = uart_exists(0x2f8);
>>>>>> - acpi_info->lpt1_present = lpt_exists(0x378);
>>>>>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>>>>>> - acpi_info->pci_min = pci_mem_start;
>>>>>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>>>>>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>>>>>> - {
>>>>>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>>>>>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>>>>>> - }
>>>>>> + *(struct acpi_info *)config->ainfop = config->ainfo;
>>>>> With your new separation of responsibilities - does this really
>>>>> belong here rather than in the caller?
>>>> I think it should be done here: when the call returns all tables are
>>>> already in memory. If the caller wants to load those tables separately
>>>> (as probably the toolstack will) then it can simply copy it as a blob.
>>> But this structure isn't part of the ACPI tables, and by not doing
>>> it here (a) at least some of the intended callers may be able to
>>> get away without the ugly cast and (b) the field now named
>>> ainfop wouldn't be needed either afaict.
>>
>> I probably didn't use right terminology. This is not a table, but an AML
>> piece?
> Clearly not. This is data structure we define ourselves, which only
> gets used by AML code.
>
>> In any case, it's something that is ACPI-specific and I was
>> hoping we wouldn't need to expose this to the caller.
> That would imo be a relevant argument only if the structure
> type was indeed private to a single (sub-)component.
As I said below, I only expose this structure to callers for convenience.
How about I keep acpi_info private to the builder and instead define new
structure that will pass necessary information to the builder so that it
can fill acpi_info internally and copy it to memory?
This will also have side effect of allowing us to keep acpi_info and
tables in contiguous memory. We do this now implicitly for hvmloader
(RESERVED_MEMORY_DYNAMIC_START = ACPI_INFO_PHYSICAL_ADDRESS + PAGE_SIZE)
so nothing should change from that side but from tools perspective it's
easier to deal with a single ACPI blob.
-boris
>
>> The fact that it
>> is passed in the right format in struct acpi_info is a happy
>> coincidence. We may change it in the future (and so perhaps I should
>> drop the comment in libacpi.h about "This must match the
>> Field("BIOS"....) definition in the DSDT.")
> Definitely not: The two absolutely have to remain in sync. They're
> C and AML representations of the same thing.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
2016-08-01 14:06 ` Boris Ostrovsky
@ 2016-08-01 14:18 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-08-01 14:18 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 01.08.16 at 16:06, <boris.ostrovsky@oracle.com> wrote:
> On 08/01/2016 06:09 AM, Jan Beulich wrote:
>>>>> On 08.07.16 at 18:14, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/08/2016 11:11 AM, Jan Beulich wrote:
>>>>>>> On 08.07.16 at 16:39, <boris.ostrovsky@oracle.com> wrote:
>>>>> On 07/08/2016 06:10 AM, Jan Beulich wrote:
>>>>>>> @@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config,
>>>>> unsigned int physical)
>>>>>>> offsetof(struct acpi_20_rsdp, extended_checksum),
>>>>>>> sizeof(struct acpi_20_rsdp));
>>>>>>>
>>>>>>> - if ( !new_vm_gid(acpi_info) )
>>>>>>> + if ( !new_vm_gid(&config->ainfo) )
>>>>>>> goto oom;
>>>>>>>
>>>>>>> - acpi_info->com1_present = uart_exists(0x3f8);
>>>>>>> - acpi_info->com2_present = uart_exists(0x2f8);
>>>>>>> - acpi_info->lpt1_present = lpt_exists(0x378);
>>>>>>> - acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
>>>>>>> - acpi_info->pci_min = pci_mem_start;
>>>>>>> - acpi_info->pci_len = pci_mem_end - pci_mem_start;
>>>>>>> - if ( pci_hi_mem_end > pci_hi_mem_start )
>>>>>>> - {
>>>>>>> - acpi_info->pci_hi_min = pci_hi_mem_start;
>>>>>>> - acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>>>>>>> - }
>>>>>>> + *(struct acpi_info *)config->ainfop = config->ainfo;
>>>>>> With your new separation of responsibilities - does this really
>>>>>> belong here rather than in the caller?
>>>>> I think it should be done here: when the call returns all tables are
>>>>> already in memory. If the caller wants to load those tables separately
>>>>> (as probably the toolstack will) then it can simply copy it as a blob.
>>>> But this structure isn't part of the ACPI tables, and by not doing
>>>> it here (a) at least some of the intended callers may be able to
>>>> get away without the ugly cast and (b) the field now named
>>>> ainfop wouldn't be needed either afaict.
>>>
>>> I probably didn't use right terminology. This is not a table, but an AML
>>> piece?
>> Clearly not. This is data structure we define ourselves, which only
>> gets used by AML code.
>>
>>> In any case, it's something that is ACPI-specific and I was
>>> hoping we wouldn't need to expose this to the caller.
>> That would imo be a relevant argument only if the structure
>> type was indeed private to a single (sub-)component.
>
> As I said below, I only expose this structure to callers for convenience.
>
> How about I keep acpi_info private to the builder and instead define new
> structure that will pass necessary information to the builder so that it
> can fill acpi_info internally and copy it to memory?
Well, let's see how that ends up being.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-07-05 19:05 ` [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
2016-07-05 19:05 ` [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 10:18 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader Boris Ostrovsky
` (17 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
This way ACPI code won't use xenstore-read() and hvm_param_set()
which are private to hvmloader.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
This is one patch that modifies config->ainfo.vm_gid_addr in build.c, with that change
consumed by the caller (when it sets VM_PARAM_VM_GENERATION_ID_ADDR). We could
make the caller fill out config->ainfo.vm_gid_addr to avoid this as suggested by Jan but
I think logically this belongs in the ACPI builder.
tools/firmware/hvmloader/acpi/build.c | 30 +++++++++++-------------------
tools/firmware/hvmloader/acpi/libacpi.h | 2 ++
tools/firmware/hvmloader/util.c | 16 ++++++++++++++++
3 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1092b4e..ca9727f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -446,32 +446,24 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
*
* Return 0 if memory failure, != 0 if success
*/
-static int new_vm_gid(struct acpi_info *acpi_info)
+static int new_vm_gid(struct acpi_config *config)
{
- uint64_t vm_gid[2], *buf;
- const char * s;
- char *end;
-
- acpi_info->vm_gid_addr = 0;
-
- /* read ID and check for 0 */
- s = xenstore_read("platform/generation-id", "0:0");
- vm_gid[0] = strtoll(s, &end, 0);
- vm_gid[1] = 0;
- if ( end && end[0] == ':' )
- vm_gid[1] = strtoll(end+1, NULL, 0);
- if ( !vm_gid[0] && !vm_gid[1] )
+ uint64_t *buf;
+
+ config->ainfo.vm_gid_addr = 0;
+
+ /* check for 0 ID*/
+ if ( !config->vm_gid[0] && !config->vm_gid[1] )
return 1;
/* copy to allocate BIOS memory */
- buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+ buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
if ( !buf )
return 0;
- memcpy(buf, vm_gid, sizeof(vm_gid));
+ memcpy(buf, config->vm_gid, sizeof(config->vm_gid));
/* set into ACPI table and HVM param the address */
- acpi_info->vm_gid_addr = virt_to_phys(buf);
- hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, acpi_info->vm_gid_addr);
+ config->ainfo.vm_gid_addr = virt_to_phys(buf);
return 1;
}
@@ -593,7 +585,7 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_20_rsdp, extended_checksum),
sizeof(struct acpi_20_rsdp));
- if ( !new_vm_gid(&config->ainfo) )
+ if ( !new_vm_gid(config) )
goto oom;
*(struct acpi_info *)config->ainfop = config->ainfo;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 098eee1..aa19972 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -52,6 +52,8 @@ struct acpi_config {
const unsigned char *dsdt_15cpu;
unsigned int dsdt_15cpu_len;
+ uint64_t vm_gid[2];
+
/* May have some fields updated by acpi_build_table() */
struct acpi_info ainfo;
/*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 4293efa..e62052b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
#include <xen/xen.h>
#include <xen/memory.h>
#include <xen/sched.h>
+#include <xen/hvm/params.h>
/*
* Check whether there exists overlap in the specified memory range.
@@ -861,6 +862,8 @@ int hpet_exists(unsigned long hpet_base)
void hvmloader_acpi_build_tables(struct acpi_config *config,
unsigned int physical)
{
+ const char *s;
+
/* Allocate and initialise the acpi info area. */
mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -876,10 +879,23 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
config->ainfo.pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
}
+ s = xenstore_read("platform/generation-id", "0:0");
+ if ( s )
+ {
+ char *end;
+
+ config->vm_gid[0] = strtoll(s, &end, 0);
+ config->vm_gid[1] = 0;
+ if ( end && end[0] == ':' )
+ config->vm_gid[1] = strtoll(end+1, NULL, 0);
+ }
+
config->rsdp = physical;
config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
acpi_build_tables(config);
+
+ hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->ainfo.vm_gid_addr);
}
/*
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code
2016-07-05 19:05 ` [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
@ 2016-07-08 10:18 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 10:18 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> This way ACPI code won't use xenstore-read() and hvm_param_set()
> which are private to hvmloader.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> This is one patch that modifies config->ainfo.vm_gid_addr in build.c, with that change
> consumed by the caller (when it sets VM_PARAM_VM_GENERATION_ID_ADDR). We could
> make the caller fill out config->ainfo.vm_gid_addr to avoid this as suggested by Jan but
> I think logically this belongs in the ACPI builder.
Yeah, looking at the patch I think this is fine as is.
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -446,32 +446,24 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> *
> * Return 0 if memory failure, != 0 if success
> */
> -static int new_vm_gid(struct acpi_info *acpi_info)
> +static int new_vm_gid(struct acpi_config *config)
> {
> - uint64_t vm_gid[2], *buf;
> - const char * s;
> - char *end;
> -
> - acpi_info->vm_gid_addr = 0;
> -
> - /* read ID and check for 0 */
> - s = xenstore_read("platform/generation-id", "0:0");
> - vm_gid[0] = strtoll(s, &end, 0);
> - vm_gid[1] = 0;
> - if ( end && end[0] == ':' )
> - vm_gid[1] = strtoll(end+1, NULL, 0);
> - if ( !vm_gid[0] && !vm_gid[1] )
> + uint64_t *buf;
Afaict you no-where deref that pointer, so I can't see why it can't
be void *.
> + config->ainfo.vm_gid_addr = 0;
> +
> + /* check for 0 ID*/
> + if ( !config->vm_gid[0] && !config->vm_gid[1] )
> return 1;
>
> /* copy to allocate BIOS memory */
> - buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
> + buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
In any event this cast is pointless (and has been before).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (2 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 10:27 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
` (16 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
With that, xenstore_read() won't need to be done in ACPI code
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
tools/firmware/hvmloader/acpi/build.c | 20 +++++++-------------
tools/firmware/hvmloader/acpi/libacpi.h | 7 +++++++
tools/firmware/hvmloader/util.c | 12 ++++++++++++
3 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index ca9727f..0bcb185 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,11 +54,6 @@ static void set_checksum(
p[checksum_offset] = -sum;
}
-static uint8_t battery_port_exists(void)
-{
- return (inb(0x88) == 0x1F);
-}
-
static struct acpi_20_madt *construct_madt(struct acpi_info *info)
{
struct acpi_20_madt *madt;
@@ -320,7 +315,7 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
}
static int construct_secondary_tables(unsigned long *table_ptrs,
- struct acpi_info *info)
+ struct acpi_config *config)
{
int nr_tables = 0;
struct acpi_20_madt *madt;
@@ -335,13 +330,13 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
/* MADT. */
if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
{
- madt = construct_madt(info);
+ madt = construct_madt(&config->ainfo);
if (!madt) return -1;
table_ptrs[nr_tables++] = (unsigned long)madt;
}
/* HPET. */
- if ( info->hpet_present )
+ if ( config->ainfo.hpet_present )
{
hpet = construct_hpet();
if (!hpet) return -1;
@@ -353,7 +348,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
if (!waet) return -1;
table_ptrs[nr_tables++] = (unsigned long)waet;
- if ( battery_port_exists() )
+ if ( config->table_flags & ACPI_BUILD_SSDT_PM )
{
ssdt = mem_alloc(sizeof(ssdt_pm), 16);
if (!ssdt) return -1;
@@ -361,7 +356,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
table_ptrs[nr_tables++] = (unsigned long)ssdt;
}
- if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+ if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
{
ssdt = mem_alloc(sizeof(ssdt_s3), 16);
if (!ssdt) return -1;
@@ -371,7 +366,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
printf("S3 disabled\n");
}
- if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+ if ( config->table_flags & ACPI_BUILD_SSDT_S4 )
{
ssdt = mem_alloc(sizeof(ssdt_s4), 16);
if (!ssdt) return -1;
@@ -539,8 +534,7 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_20_fadt));
- nr_secondaries = construct_secondary_tables(secondary_tables,
- &config->ainfo);
+ nr_secondaries = construct_secondary_tables(secondary_tables, config);
if ( nr_secondaries < 0 )
goto oom;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index aa19972..5454bc2 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -28,6 +28,11 @@
#ifndef __LIBACPI_H__
#define __LIBACPI_H__
+/* Flags indicating which tables to build */
+#define ACPI_BUILD_SSDT_PM (1<<0)
+#define ACPI_BUILD_SSDT_S3 (1<<1)
+#define ACPI_BUILD_SSDT_S4 (1<<2)
+
#pragma pack ()
/*
@@ -54,6 +59,8 @@ struct acpi_config {
uint64_t vm_gid[2];
+ uint32_t table_flags;
+
/* May have some fields updated by acpi_build_table() */
struct acpi_info ainfo;
/*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index e62052b..1ccb38c 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -859,6 +859,11 @@ int hpet_exists(unsigned long hpet_base)
return ((hpet_id >> 16) == 0x8086);
}
+static uint8_t battery_port_exists(void)
+{
+ return (inb(0x88) == 0x1F);
+}
+
void hvmloader_acpi_build_tables(struct acpi_config *config,
unsigned int physical)
{
@@ -890,6 +895,13 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
config->vm_gid[1] = strtoll(end+1, NULL, 0);
}
+ if ( battery_port_exists() )
+ config->table_flags |= ACPI_BUILD_SSDT_PM;
+ if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+ config->table_flags |= ACPI_BUILD_SSDT_S3;
+ if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+ config->table_flags |= ACPI_BUILD_SSDT_S4;
+
config->rsdp = physical;
config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader
2016-07-05 19:05 ` [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader Boris Ostrovsky
@ 2016-07-08 10:27 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 10:27 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> @@ -890,6 +895,13 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
> config->vm_gid[1] = strtoll(end+1, NULL, 0);
> }
>
> + if ( battery_port_exists() )
> + config->table_flags |= ACPI_BUILD_SSDT_PM;
> + if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
> + config->table_flags |= ACPI_BUILD_SSDT_S3;
> + if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
> + config->table_flags |= ACPI_BUILD_SSDT_S4;
I think that both here and at the consuming side this would look
better if you used bit fields. But even in its current form
Acked-by: Jan Beulich <jbeulich@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (3 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 10:46 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
` (15 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Rename acpi_pt_length/addr to pt_length/addr
tools/firmware/hvmloader/acpi/build.c | 22 +++++++---------------
tools/firmware/hvmloader/acpi/libacpi.h | 5 +++++
tools/firmware/hvmloader/util.c | 11 +++++++++++
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 0bcb185..95f6cf8 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -269,10 +269,10 @@ static struct acpi_20_slit *construct_slit(void)
}
static int construct_passthrough_tables(unsigned long *table_ptrs,
- int nr_tables)
+ int nr_tables,
+ struct acpi_config *config)
{
- const char *s;
- uint8_t *acpi_pt_addr;
+ unsigned long acpi_pt_addr;
uint32_t acpi_pt_length;
struct acpi_header *header;
int nr_added;
@@ -280,19 +280,11 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
uint32_t total = 0;
uint8_t *buffer;
- s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
- if ( s == NULL )
- return 0;
-
- acpi_pt_addr = (uint8_t*)(uint32_t)strtoll(s, NULL, 0);
- if ( acpi_pt_addr == NULL )
- return 0;
-
- s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
- if ( s == NULL )
+ if ( config->pt.pt_addr == 0 )
return 0;
- acpi_pt_length = (uint32_t)strtoll(s, NULL, 0);
+ acpi_pt_addr = config->pt.pt_addr;
+ acpi_pt_length = config->pt.pt_length;
for ( nr_added = 0; nr_added < nr_max; nr_added++ )
{
@@ -428,7 +420,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* Load any additional tables passed through. */
- nr_tables += construct_passthrough_tables(table_ptrs, nr_tables);
+ nr_tables += construct_passthrough_tables(table_ptrs, nr_tables, config);
table_ptrs[nr_tables] = 0;
return nr_tables;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 5454bc2..05e6c69 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -61,6 +61,11 @@ struct acpi_config {
uint32_t table_flags;
+ struct {
+ uint32_t pt_addr;
+ uint32_t pt_length;
+ } pt;
+
/* May have some fields updated by acpi_build_table() */
struct acpi_info ainfo;
/*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1ccb38c..1864d7a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
#include <xen/xen.h>
#include <xen/memory.h>
#include <xen/sched.h>
+#include <xen/hvm/hvm_xs_strings.h>
#include <xen/hvm/params.h>
/*
@@ -895,6 +896,16 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
config->vm_gid[1] = strtoll(end+1, NULL, 0);
}
+ s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
+ if ( s )
+ {
+ config->pt.pt_addr = strtoll(s, NULL, 0);
+
+ s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
+ if ( s )
+ config->pt.pt_length = strtoll(s, NULL, 0);
+ }
+
if ( battery_port_exists() )
config->table_flags |= ACPI_BUILD_SSDT_PM;
if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code
2016-07-05 19:05 ` [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
@ 2016-07-08 10:46 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 10:46 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> Changes in v1:
> * Rename acpi_pt_length/addr to pt_length/addr
And stopped half way? I ask because ...
> @@ -280,19 +280,11 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
> uint32_t total = 0;
> uint8_t *buffer;
>
> - s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
> - if ( s == NULL )
> - return 0;
> -
> - acpi_pt_addr = (uint8_t*)(uint32_t)strtoll(s, NULL, 0);
> - if ( acpi_pt_addr == NULL )
> - return 0;
> -
> - s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
> - if ( s == NULL )
> + if ( config->pt.pt_addr == 0 )
> return 0;
>
> - acpi_pt_length = (uint32_t)strtoll(s, NULL, 0);
> + acpi_pt_addr = config->pt.pt_addr;
> + acpi_pt_length = config->pt.pt_length;
... expressions like the right side ones here look like K&R C to me -
the pt_ prefixes are redundant too. With that taken care of and ...
> @@ -895,6 +896,16 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
> config->vm_gid[1] = strtoll(end+1, NULL, 0);
> }
>
> + s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
> + if ( s )
> + {
> + config->pt.pt_addr = strtoll(s, NULL, 0);
> +
> + s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
> + if ( s )
... the double blank here reduced to just one
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (4 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 13:36 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
` (14 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
No need for ACPI code to rely on hvm_info.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Pass hvm_info_table pointer in acpi_config
tools/firmware/hvmloader/acpi/build.c | 53 ++++++++++++++++---------------
tools/firmware/hvmloader/acpi/libacpi.h | 13 +++++++
tools/firmware/hvmloader/util.c | 9 +++++
3 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 95f6cf8..d6e7798 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,7 +54,7 @@ static void set_checksum(
p[checksum_offset] = -sum;
}
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(struct acpi_config *config)
{
struct acpi_20_madt *madt;
struct acpi_20_madt_intsrcovr *intsrcovr;
@@ -65,7 +65,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info *info)
sz = sizeof(struct acpi_20_madt);
sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
sz += sizeof(struct acpi_20_madt_ioapic);
- sz += sizeof(struct acpi_20_madt_lapic) * hvm_info->nr_vcpus;
+ sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
madt = mem_alloc(sz, 16);
if (!madt) return NULL;
@@ -118,9 +118,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info *info)
io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
- info->nr_cpus = hvm_info->nr_vcpus;
- info->madt_lapic0_addr = (uint32_t)lapic;
- for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+ config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
+ config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
+ for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
{
memset(lapic, 0, sizeof(*lapic));
lapic->type = ACPI_PROCESSOR_LOCAL_APIC;
@@ -128,7 +128,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info *info)
/* Processor ID must match processor-object IDs in the DSDT. */
lapic->acpi_processor_id = i;
lapic->apic_id = LAPIC_ID(i);
- lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+ lapic->flags = (test_bit(i, config->hvminfo->vcpu_online)
? ACPI_LOCAL_APIC_ENABLED : 0);
lapic++;
}
@@ -136,7 +136,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info *info)
madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
set_checksum(madt, offsetof(struct acpi_header, checksum),
madt->header.length);
- info->madt_csum_addr = (uint32_t)&madt->header.checksum;
+ config->ainfo.madt_csum_addr = (uint32_t)&madt->header.checksum;
return madt;
}
@@ -179,7 +179,7 @@ static struct acpi_20_waet *construct_waet(void)
return waet;
}
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(struct acpi_config *config)
{
struct acpi_20_srat *srat;
struct acpi_20_srat_processor *processor;
@@ -188,8 +188,8 @@ static struct acpi_20_srat *construct_srat(void)
void *p;
unsigned int i;
- size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
- sizeof(*memory) * nr_vmemranges;
+ size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+ sizeof(*memory) * config->numa.nr_vmemranges;
p = mem_alloc(size, 16);
if ( !p )
@@ -206,25 +206,26 @@ static struct acpi_20_srat *construct_srat(void)
srat->table_revision = ACPI_SRAT_TABLE_REVISION;
processor = (struct acpi_20_srat_processor *)(srat + 1);
- for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+ for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
{
processor->type = ACPI_PROCESSOR_AFFINITY;
processor->length = sizeof(*processor);
- processor->domain = vcpu_to_vnode[i];
+ processor->domain = config->numa.vcpu_to_vnode[i];
processor->apic_id = LAPIC_ID(i);
processor->flags = ACPI_LOCAL_APIC_AFFIN_ENABLED;
processor++;
}
memory = (struct acpi_20_srat_memory *)processor;
- for ( i = 0; i < nr_vmemranges; i++ )
+ for ( i = 0; i < config->numa.nr_vmemranges; i++ )
{
memory->type = ACPI_MEMORY_AFFINITY;
memory->length = sizeof(*memory);
- memory->domain = vmemrange[i].nid;
+ memory->domain = config->numa.vmemrange[i].nid;
memory->flags = ACPI_MEM_AFFIN_ENABLED;
- memory->base_address = vmemrange[i].start;
- memory->mem_length = vmemrange[i].end - vmemrange[i].start;
+ memory->base_address = config->numa.vmemrange[i].start;
+ memory->mem_length = config->numa.vmemrange[i].end -
+ config->numa.vmemrange[i].start;
memory++;
}
@@ -236,12 +237,12 @@ static struct acpi_20_srat *construct_srat(void)
return srat;
}
-static struct acpi_20_slit *construct_slit(void)
+static struct acpi_20_slit *construct_slit(struct acpi_config *config)
{
struct acpi_20_slit *slit;
unsigned int i, num, size;
- num = nr_vnodes * nr_vnodes;
+ num = config->numa.nr_vnodes * config->numa.nr_vnodes;
size = sizeof(*slit) + num * sizeof(uint8_t);
slit = mem_alloc(size, 16);
@@ -258,9 +259,9 @@ static struct acpi_20_slit *construct_slit(void)
slit->header.creator_revision = ACPI_CREATOR_REVISION;
for ( i = 0; i < num; i++ )
- slit->entry[i] = vdistance[i];
+ slit->entry[i] = config->numa.vdistance[i];
- slit->localities = nr_vnodes;
+ slit->localities = config->numa.nr_vnodes;
slit->header.length = size;
set_checksum(slit, offsetof(struct acpi_header, checksum), size);
@@ -320,9 +321,9 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
void *lasa;
/* MADT. */
- if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
+ if ( (config->hvminfo->nr_vcpus > 1) || config->hvminfo->apic_mode )
{
- madt = construct_madt(&config->ainfo);
+ madt = construct_madt(config);
if (!madt) return -1;
table_ptrs[nr_tables++] = (unsigned long)madt;
}
@@ -404,10 +405,10 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* SRAT and SLIT */
- if ( nr_vnodes > 0 )
+ if ( config->numa.nr_vnodes > 0 )
{
- struct acpi_20_srat *srat = construct_srat();
- struct acpi_20_slit *slit = construct_slit();
+ struct acpi_20_srat *srat = construct_srat(config);
+ struct acpi_20_slit *slit = construct_slit(config);
if ( srat )
table_ptrs[nr_tables++] = (unsigned long)srat;
@@ -483,7 +484,7 @@ void acpi_build_tables(struct acpi_config *config)
* The latter is required for Windows 2000, which experiences a BSOD of
* KMODE_EXCEPTION_NOT_HANDLED if it sees more than 15 processor objects.
*/
- if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
+ if ( config->hvminfo->nr_vcpus <= 15 && config->dsdt_15cpu)
{
dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
if (!dsdt) goto oom;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 05e6c69..9d28ba7 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -28,6 +28,8 @@
#ifndef __LIBACPI_H__
#define __LIBACPI_H__
+#include <xen/memory.h>
+
/* Flags indicating which tables to build */
#define ACPI_BUILD_SSDT_PM (1<<0)
#define ACPI_BUILD_SSDT_S3 (1<<1)
@@ -51,6 +53,14 @@ struct acpi_info {
uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
};
+struct acpi_numa {
+ uint32_t nr_vmemranges;
+ uint32_t nr_vnodes;
+ unsigned int *vcpu_to_vnode;
+ unsigned int *vdistance;
+ xen_vmemrange_t *vmemrange;
+};
+
struct acpi_config {
const unsigned char *dsdt_anycpu;
unsigned int dsdt_anycpu_len;
@@ -66,6 +76,9 @@ struct acpi_config {
uint32_t pt_length;
} pt;
+ struct acpi_numa numa;
+ struct hvm_info_table *hvminfo;
+
/* May have some fields updated by acpi_build_table() */
struct acpi_info ainfo;
/*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1864d7a..020cf1d 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -21,6 +21,7 @@
#include "config.h"
#include "hypercall.h"
#include "ctype.h"
+#include "vnuma.h"
#include "acpi/acpi2_0.h"
#include "acpi/libacpi.h"
#include <stdint.h>
@@ -913,6 +914,14 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
config->table_flags |= ACPI_BUILD_SSDT_S4;
+ config->numa.nr_vmemranges = nr_vmemranges;
+ config->numa.nr_vnodes = nr_vnodes;
+ config->numa.vcpu_to_vnode = vcpu_to_vnode;
+ config->numa.vdistance = vdistance;
+ config->numa.vmemrange = vmemrange;
+
+ config->hvminfo = hvm_info;
+
config->rsdp = physical;
config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
2016-07-05 19:05 ` [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
@ 2016-07-08 13:36 ` Jan Beulich
2016-07-08 15:08 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 13:36 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> No need for ACPI code to rely on hvm_info.
Perhaps better "... on the hvm_info variable"?
> @@ -118,9 +118,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info *info)
> io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
>
> lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
> - info->nr_cpus = hvm_info->nr_vcpus;
> - info->madt_lapic0_addr = (uint32_t)lapic;
> - for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> + config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
Misplaced space.
> memory = (struct acpi_20_srat_memory *)processor;
> - for ( i = 0; i < nr_vmemranges; i++ )
> + for ( i = 0; i < config->numa.nr_vmemranges; i++ )
> {
> memory->type = ACPI_MEMORY_AFFINITY;
> memory->length = sizeof(*memory);
> - memory->domain = vmemrange[i].nid;
> + memory->domain = config->numa.vmemrange[i].nid;
> memory->flags = ACPI_MEM_AFFIN_ENABLED;
> - memory->base_address = vmemrange[i].start;
> - memory->mem_length = vmemrange[i].end - vmemrange[i].start;
> + memory->base_address = config->numa.vmemrange[i].start;
> + memory->mem_length = config->numa.vmemrange[i].end -
> + config->numa.vmemrange[i].start;
I'd prefer for the two config-> of this expression to align with one
another.
> --- a/tools/firmware/hvmloader/acpi/libacpi.h
> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
> @@ -28,6 +28,8 @@
> #ifndef __LIBACPI_H__
> #define __LIBACPI_H__
>
> +#include <xen/memory.h>
I think this can be avoided if ...
> @@ -51,6 +53,14 @@ struct acpi_info {
> uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
> };
>
> +struct acpi_numa {
> + uint32_t nr_vmemranges;
> + uint32_t nr_vnodes;
> + unsigned int *vcpu_to_vnode;
> + unsigned int *vdistance;
> + xen_vmemrange_t *vmemrange;
... you use struct xen_vmemrange * here.
Also I think the two pointed to types can and should be const
qualified.
And then - any reason not to put this ...
> @@ -66,6 +76,9 @@ struct acpi_config {
> uint32_t pt_length;
> } pt;
>
> + struct acpi_numa numa;
... right here, perhaps even omitting the structure tag?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
2016-07-08 13:36 ` Jan Beulich
@ 2016-07-08 15:08 ` Boris Ostrovsky
2016-07-08 15:14 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 15:08 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 09:36 AM, Jan Beulich wrote:
>
>> @@ -51,6 +53,14 @@ struct acpi_info {
>> uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
>> };
>>
>> +struct acpi_numa {
>> + uint32_t nr_vmemranges;
>> + uint32_t nr_vnodes;
>> + unsigned int *vcpu_to_vnode;
>> + unsigned int *vdistance;
>> + xen_vmemrange_t *vmemrange;
> ... you use struct xen_vmemrange * here.
>
> Also I think the two pointed to types can and should be const
> qualified.
>
> And then - any reason not to put this ...
>
>> @@ -66,6 +76,9 @@ struct acpi_config {
>> uint32_t pt_length;
>> } pt;
>>
>> + struct acpi_numa numa;
> ... right here, perhaps even omitting the structure tag?
I'd like to have a data type for better readability. See patch 20,
init_acpi_config().
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
2016-07-08 15:08 ` Boris Ostrovsky
@ 2016-07-08 15:14 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 15:14 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 08.07.16 at 17:08, <boris.ostrovsky@oracle.com> wrote:
> On 07/08/2016 09:36 AM, Jan Beulich wrote:
>>> @@ -51,6 +53,14 @@ struct acpi_info {
>>> @@ -66,6 +76,9 @@ struct acpi_config {
>>> uint32_t pt_length;
>>> } pt;
>>>
>>> + struct acpi_numa numa;
>> ... right here, perhaps even omitting the structure tag?
>
> I'd like to have a data type for better readability. See patch 20,
> init_acpi_config().
Okay, if it becomes of use later on, fine with me.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 07/20] acpi/hvmloader: Set TIS header address in hvmloader
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (5 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 13:38 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
` (13 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Users other than hvmloader may provide TIS address as virtual.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Merged 'if' conditions to make the diff smaller
tools/firmware/hvmloader/acpi/build.c | 9 ++++-----
tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
tools/firmware/hvmloader/config.h | 2 ++
tools/firmware/hvmloader/util.c | 4 ++++
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index d6e7798..94b46c1 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -317,7 +317,6 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
struct acpi_20_tcpa *tcpa;
unsigned char *ssdt;
static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
- uint16_t *tis_hdr;
void *lasa;
/* MADT. */
@@ -370,10 +369,10 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* TPM TCPA and SSDT. */
- tis_hdr = (uint16_t *)0xFED40F00;
- if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+ if ( (config->table_flags & ACPI_BUILD_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
{
ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 9d28ba7..75874ec 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -34,6 +34,7 @@
#define ACPI_BUILD_SSDT_PM (1<<0)
#define ACPI_BUILD_SSDT_S3 (1<<1)
#define ACPI_BUILD_SSDT_S4 (1<<2)
+#define ACPI_BUILD_TCPA (1<<3)
#pragma pack ()
@@ -79,6 +80,8 @@ struct acpi_config {
struct acpi_numa numa;
struct hvm_info_table *hvminfo;
+ uint16_t *tis_hdr;
+
/* May have some fields updated by acpi_build_table() */
struct acpi_info ainfo;
/*
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index b838cf9..c7460fb 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -55,6 +55,8 @@ extern struct bios_config ovmf_config;
/* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
#define PCI_MEM_END 0xfc000000
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
extern unsigned long pci_mem_start, pci_mem_end;
extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 020cf1d..9f9c93b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,6 +914,10 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
config->table_flags |= ACPI_BUILD_SSDT_S4;
+ config->table_flags |= ACPI_BUILD_TCPA;
+
+ config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
config->numa.nr_vmemranges = nr_vmemranges;
config->numa.nr_vnodes = nr_vnodes;
config->numa.vcpu_to_vnode = vcpu_to_vnode;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 07/20] acpi/hvmloader: Set TIS header address in hvmloader
2016-07-05 19:05 ` [PATCH v1 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
@ 2016-07-08 13:38 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 13:38 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> @@ -79,6 +80,8 @@ struct acpi_config {
> struct acpi_numa numa;
> struct hvm_info_table *hvminfo;
>
> + uint16_t *tis_hdr;
const?
With that adjusted (unless impossible)
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (6 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 13:41 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
` (12 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
tools/firmware/hvmloader/acpi/build.c | 68 +++++++++++++++++--------------
tools/firmware/hvmloader/acpi/libacpi.h | 1 +
tools/firmware/hvmloader/util.c | 2 +-
3 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 94b46c1..8780984 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -81,43 +81,49 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
madt->lapic_addr = LAPIC_BASE_ADDRESS;
madt->flags = ACPI_PCAT_COMPAT;
- intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
- for ( i = 0; i < 16; i++ )
+ if ( config->table_flags & ACPI_BUILD_IOAPIC )
{
- memset(intsrcovr, 0, sizeof(*intsrcovr));
- intsrcovr->type = ACPI_INTERRUPT_SOURCE_OVERRIDE;
- intsrcovr->length = sizeof(*intsrcovr);
- intsrcovr->source = i;
-
- if ( i == 0 )
- {
- /* ISA IRQ0 routed to IOAPIC GSI 2. */
- intsrcovr->gsi = 2;
- intsrcovr->flags = 0x0;
- }
- else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+ intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+ for ( i = 0; i < 16; i++ )
{
- /* PCI: active-low level-triggered. */
- intsrcovr->gsi = i;
- intsrcovr->flags = 0xf;
- }
- else
- {
- /* No need for a INT source override structure. */
- continue;
+ memset(intsrcovr, 0, sizeof(*intsrcovr));
+ intsrcovr->type = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+ intsrcovr->length = sizeof(*intsrcovr);
+ intsrcovr->source = i;
+
+ if ( i == 0 )
+ {
+ /* ISA IRQ0 routed to IOAPIC GSI 2. */
+ intsrcovr->gsi = 2;
+ intsrcovr->flags = 0x0;
+ }
+ else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+ {
+ /* PCI: active-low level-triggered. */
+ intsrcovr->gsi = i;
+ intsrcovr->flags = 0xf;
+ }
+ else
+ {
+ /* No need for a INT source override structure. */
+ continue;
+ }
+
+ intsrcovr++;
}
- intsrcovr++;
- }
+ io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+ memset(io_apic, 0, sizeof(*io_apic));
+ io_apic->type = ACPI_IO_APIC;
+ io_apic->length = sizeof(*io_apic);
+ io_apic->ioapic_id = IOAPIC_ID;
+ io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
- io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
- memset(io_apic, 0, sizeof(*io_apic));
- io_apic->type = ACPI_IO_APIC;
- io_apic->length = sizeof(*io_apic);
- io_apic->ioapic_id = IOAPIC_ID;
- io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
+ lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+ }
+ else
+ lapic = (struct acpi_20_madt_lapic *)(madt + 1);
- lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 75874ec..86f19b9 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -35,6 +35,7 @@
#define ACPI_BUILD_SSDT_S3 (1<<1)
#define ACPI_BUILD_SSDT_S4 (1<<2)
#define ACPI_BUILD_TCPA (1<<3)
+#define ACPI_BUILD_IOAPIC (1<<4)
#pragma pack ()
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9f9c93b..5aecf7b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,7 +914,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
config->table_flags |= ACPI_BUILD_SSDT_S4;
- config->table_flags |= ACPI_BUILD_TCPA;
+ config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC);
config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (7 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 13:42 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
` (11 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
tools/firmware/hvmloader/acpi/build.c | 9 ++++++---
tools/firmware/hvmloader/acpi/libacpi.h | 1 +
tools/firmware/hvmloader/util.c | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 8780984..570d26f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -342,9 +342,12 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* WAET. */
- waet = construct_waet();
- if (!waet) return -1;
- table_ptrs[nr_tables++] = (unsigned long)waet;
+ if ( config->table_flags & ACPI_BUILD_WAET )
+ {
+ waet = construct_waet();
+ if ( !waet ) return -1;
+ table_ptrs[nr_tables++] = (unsigned long)waet;
+ }
if ( config->table_flags & ACPI_BUILD_SSDT_PM )
{
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index 86f19b9..b052eab 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -36,6 +36,7 @@
#define ACPI_BUILD_SSDT_S4 (1<<2)
#define ACPI_BUILD_TCPA (1<<3)
#define ACPI_BUILD_IOAPIC (1<<4)
+#define ACPI_BUILD_WAET (1<<5)
#pragma pack ()
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 5aecf7b..08328f8 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,7 +914,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
config->table_flags |= ACPI_BUILD_SSDT_S4;
- config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC);
+ config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC |
+ ACPI_BUILD_WAET);
config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally
2016-07-05 19:05 ` [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
@ 2016-07-08 13:42 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 13:42 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -342,9 +342,12 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
> }
>
> /* WAET. */
> - waet = construct_waet();
> - if (!waet) return -1;
> - table_ptrs[nr_tables++] = (unsigned long)waet;
> + if ( config->table_flags & ACPI_BUILD_WAET )
> + {
> + waet = construct_waet();
> + if ( !waet ) return -1;
Now that you touch it, this should become two lines. With that
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (8 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 13:58 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
` (10 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Keep memory ops seprate from acpi_config, in struct acpi_context.
Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who might want to
use those. The builder uses (should use) mem_alloc() to allocate memory for tables, not as a
general-purpose allocator.
tools/firmware/hvmloader/acpi/build.c | 87 +++++++++++++++++--------------
tools/firmware/hvmloader/acpi/libacpi.h | 9 +++-
tools/firmware/hvmloader/util.c | 16 +++++-
3 files changed, 71 insertions(+), 41 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 570d26f..0adb3d6 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,7 +54,8 @@ static void set_checksum(
p[checksum_offset] = -sum;
}
-static struct acpi_20_madt *construct_madt(struct acpi_config *config)
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
struct acpi_20_madt *madt;
struct acpi_20_madt_intsrcovr *intsrcovr;
@@ -67,7 +68,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
sz += sizeof(struct acpi_20_madt_ioapic);
sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
- madt = mem_alloc(sz, 16);
+ madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
if (!madt) return NULL;
memset(madt, 0, sizeof(*madt));
@@ -147,11 +148,12 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
return madt;
}
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
struct acpi_20_hpet *hpet;
- hpet = mem_alloc(sizeof(*hpet), 16);
+ hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
if (!hpet) return NULL;
memset(hpet, 0, sizeof(*hpet));
@@ -170,11 +172,12 @@ static struct acpi_20_hpet *construct_hpet(void)
return hpet;
}
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
struct acpi_20_waet *waet;
- waet = mem_alloc(sizeof(*waet), 16);
+ waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
if (!waet) return NULL;
memcpy(waet, &Waet, sizeof(*waet));
@@ -185,7 +188,8 @@ static struct acpi_20_waet *construct_waet(void)
return waet;
}
-static struct acpi_20_srat *construct_srat(struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
struct acpi_20_srat *srat;
struct acpi_20_srat_processor *processor;
@@ -197,7 +201,7 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
- p = mem_alloc(size, 16);
+ p = ctxt->mem_ops.alloc(ctxt, size, 16);
if ( !p )
return NULL;
@@ -243,7 +247,8 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
return srat;
}
-static struct acpi_20_slit *construct_slit(struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
struct acpi_20_slit *slit;
unsigned int i, num, size;
@@ -251,7 +256,7 @@ static struct acpi_20_slit *construct_slit(struct acpi_config *config)
num = config->numa.nr_vnodes * config->numa.nr_vnodes;
size = sizeof(*slit) + num * sizeof(uint8_t);
- slit = mem_alloc(size, 16);
+ slit = ctxt->mem_ops.alloc(ctxt, size, 16);
if ( !slit )
return NULL;
@@ -275,7 +280,8 @@ static struct acpi_20_slit *construct_slit(struct acpi_config *config)
return slit;
}
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+ unsigned long *table_ptrs,
int nr_tables,
struct acpi_config *config)
{
@@ -300,7 +306,7 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
header = (struct acpi_header*)acpi_pt_addr;
- buffer = mem_alloc(header->length, 16);
+ buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
if ( buffer == NULL )
break;
memcpy(buffer, header, header->length);
@@ -313,7 +319,8 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
return nr_added;
}
-static int construct_secondary_tables(unsigned long *table_ptrs,
+static int construct_secondary_tables(struct acpi_ctxt *ctxt,
+ unsigned long *table_ptrs,
struct acpi_config *config)
{
int nr_tables = 0;
@@ -328,7 +335,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
/* MADT. */
if ( (config->hvminfo->nr_vcpus > 1) || config->hvminfo->apic_mode )
{
- madt = construct_madt(config);
+ madt = construct_madt(ctxt, config);
if (!madt) return -1;
table_ptrs[nr_tables++] = (unsigned long)madt;
}
@@ -336,7 +343,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
/* HPET. */
if ( config->ainfo.hpet_present )
{
- hpet = construct_hpet();
+ hpet = construct_hpet(ctxt, config);
if (!hpet) return -1;
table_ptrs[nr_tables++] = (unsigned long)hpet;
}
@@ -344,14 +351,14 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
/* WAET. */
if ( config->table_flags & ACPI_BUILD_WAET )
{
- waet = construct_waet();
+ waet = construct_waet(ctxt, config);
if ( !waet ) return -1;
table_ptrs[nr_tables++] = (unsigned long)waet;
}
if ( config->table_flags & ACPI_BUILD_SSDT_PM )
{
- ssdt = mem_alloc(sizeof(ssdt_pm), 16);
+ ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
table_ptrs[nr_tables++] = (unsigned long)ssdt;
@@ -359,7 +366,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
{
- ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+ ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
table_ptrs[nr_tables++] = (unsigned long)ssdt;
@@ -369,7 +376,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
if ( config->table_flags & ACPI_BUILD_SSDT_S4 )
{
- ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+ ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
table_ptrs[nr_tables++] = (unsigned long)ssdt;
@@ -383,12 +390,12 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
(config->tis_hdr[1] == tis_signature[1]) &&
(config->tis_hdr[2] == tis_signature[2]) )
{
- ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
+ ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
table_ptrs[nr_tables++] = (unsigned long)ssdt;
- tcpa = mem_alloc(sizeof(struct acpi_20_tcpa), 16);
+ tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
if (!tcpa) return -1;
memset(tcpa, 0, sizeof(*tcpa));
table_ptrs[nr_tables++] = (unsigned long)tcpa;
@@ -401,9 +408,9 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
tcpa->header.oem_revision = ACPI_OEM_REVISION;
tcpa->header.creator_id = ACPI_CREATOR_ID;
tcpa->header.creator_revision = ACPI_CREATOR_REVISION;
- if ( (lasa = mem_alloc(ACPI_2_0_TCPA_LAML_SIZE, 16)) != NULL )
+ if ( (lasa = ctxt->mem_ops.alloc(ctxt, ACPI_2_0_TCPA_LAML_SIZE, 16)) != NULL )
{
- tcpa->lasa = virt_to_phys(lasa);
+ tcpa->lasa = ctxt->mem_ops.v2p(ctxt, lasa);
tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
memset(lasa, 0, tcpa->laml);
set_checksum(tcpa,
@@ -415,8 +422,8 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
/* SRAT and SLIT */
if ( config->numa.nr_vnodes > 0 )
{
- struct acpi_20_srat *srat = construct_srat(config);
- struct acpi_20_slit *slit = construct_slit(config);
+ struct acpi_20_srat *srat = construct_srat(ctxt, config);
+ struct acpi_20_slit *slit = construct_slit(ctxt, config);
if ( srat )
table_ptrs[nr_tables++] = (unsigned long)srat;
@@ -429,7 +436,8 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
}
/* Load any additional tables passed through. */
- nr_tables += construct_passthrough_tables(table_ptrs, nr_tables, config);
+ nr_tables += construct_passthrough_tables(ctxt, table_ptrs,
+ nr_tables, config);
table_ptrs[nr_tables] = 0;
return nr_tables;
@@ -442,7 +450,8 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
*
* Return 0 if memory failure, != 0 if success
*/
-static int new_vm_gid(struct acpi_config *config)
+static int new_vm_gid(struct acpi_ctxt *ctxt,
+ struct acpi_config *config)
{
uint64_t *buf;
@@ -453,18 +462,18 @@ static int new_vm_gid(struct acpi_config *config)
return 1;
/* copy to allocate BIOS memory */
- buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
+ buf = (uint64_t *) ctxt->mem_ops.alloc(ctxt, sizeof(config->vm_gid), 8);
if ( !buf )
return 0;
memcpy(buf, config->vm_gid, sizeof(config->vm_gid));
/* set into ACPI table and HVM param the address */
- config->ainfo.vm_gid_addr = virt_to_phys(buf);
+ config->ainfo.vm_gid_addr = ctxt->mem_ops.v2p(ctxt, buf);
return 1;
}
-void acpi_build_tables(struct acpi_config *config)
+void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
{
struct acpi_20_rsdp *rsdp;
struct acpi_20_rsdt *rsdt;
@@ -480,7 +489,7 @@ void acpi_build_tables(struct acpi_config *config)
* Fill in high-memory data structures, starting at @buf.
*/
- facs = mem_alloc(sizeof(struct acpi_20_facs), 16);
+ facs = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_facs), 16);
if (!facs) goto oom;
memcpy(facs, &Facs, sizeof(struct acpi_20_facs));
@@ -494,13 +503,13 @@ void acpi_build_tables(struct acpi_config *config)
*/
if ( config->hvminfo->nr_vcpus <= 15 && config->dsdt_15cpu)
{
- dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
+ dsdt = ctxt->mem_ops.alloc(ctxt, config->dsdt_15cpu_len, 16);
if (!dsdt) goto oom;
memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
}
else
{
- dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
+ dsdt = ctxt->mem_ops.alloc(ctxt, config->dsdt_anycpu_len, 16);
if (!dsdt) goto oom;
memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
}
@@ -513,7 +522,7 @@ void acpi_build_tables(struct acpi_config *config)
* compatible revision 1 FADT that is linked with the RSDT. Refer to:
* http://www.acpi.info/presentations/S01USMOBS169_OS%20new.ppt
*/
- fadt_10 = mem_alloc(sizeof(struct acpi_10_fadt), 16);
+ fadt_10 = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_10_fadt), 16);
if (!fadt_10) goto oom;
memcpy(fadt_10, &Fadt, sizeof(struct acpi_10_fadt));
fadt_10->header.length = sizeof(struct acpi_10_fadt);
@@ -524,7 +533,7 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_10_fadt));
- fadt = mem_alloc(sizeof(struct acpi_20_fadt), 16);
+ fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
if (!fadt) goto oom;
memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
fadt->dsdt = (unsigned long)dsdt;
@@ -535,11 +544,11 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_20_fadt));
- nr_secondaries = construct_secondary_tables(secondary_tables, config);
+ nr_secondaries = construct_secondary_tables(ctxt, secondary_tables, config);
if ( nr_secondaries < 0 )
goto oom;
- xsdt = mem_alloc(sizeof(struct acpi_20_xsdt)+
+ xsdt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_xsdt)+
sizeof(uint64_t)*nr_secondaries,
16);
if (!xsdt) goto oom;
@@ -552,7 +561,7 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_header, checksum),
xsdt->header.length);
- rsdt = mem_alloc(sizeof(struct acpi_20_rsdt)+
+ rsdt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_rsdt)+
sizeof(uint32_t)*nr_secondaries,
16);
if (!rsdt) goto oom;
@@ -580,7 +589,7 @@ void acpi_build_tables(struct acpi_config *config)
offsetof(struct acpi_20_rsdp, extended_checksum),
sizeof(struct acpi_20_rsdp));
- if ( !new_vm_gid(config) )
+ if ( !new_vm_gid(ctxt, config) )
goto oom;
*(struct acpi_info *)config->ainfop = config->ainfo;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/firmware/hvmloader/acpi/libacpi.h
index b052eab..87a2937 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -64,6 +64,13 @@ struct acpi_numa {
xen_vmemrange_t *vmemrange;
};
+struct acpi_ctxt {
+ struct acpi_mem_ops {
+ void *(*alloc)(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align);
+ unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
+ } mem_ops;
+};
+
struct acpi_config {
const unsigned char *dsdt_anycpu;
unsigned int dsdt_anycpu_len;
@@ -97,7 +104,7 @@ struct acpi_config {
unsigned int rsdp;
};
-void acpi_build_tables(struct acpi_config *config);
+void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
#endif /* __LIBACPI_H__ */
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 08328f8..9438571 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -866,10 +866,21 @@ static uint8_t battery_port_exists(void)
return (inb(0x88) == 0x1F);
}
+static unsigned long acpi_v2p(struct acpi_ctxt *ctxt, void *v)
+{
+ return virt_to_phys(v);
+}
+
+static void *acpi_mem_alloc(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align)
+{
+ return mem_alloc(size, align);
+}
+
void hvmloader_acpi_build_tables(struct acpi_config *config,
unsigned int physical)
{
const char *s;
+ struct acpi_ctxt ctxt;
/* Allocate and initialise the acpi info area. */
mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -930,7 +941,10 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
config->rsdp = physical;
config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
- acpi_build_tables(config);
+ ctxt.mem_ops.alloc = acpi_mem_alloc;
+ ctxt.mem_ops.v2p = acpi_v2p;
+
+ acpi_build_tables(&ctxt, config);
hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->ainfo.vm_gid_addr);
}
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-05 19:05 ` [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
@ 2016-07-08 13:58 ` Jan Beulich
2016-07-08 15:23 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 13:58 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> Components that wish to use ACPI builder will need to provide their own
> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
> be passed to the builder as memory ops.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> Changes in v1:
> * Keep memory ops seprate from acpi_config, in struct acpi_context.
>
> Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who might want to
> use those. The builder uses (should use) mem_alloc() to allocate memory for tables, not as a
> general-purpose allocator.
In addition to what I said back then, did you think of error cleanup
paths here? Not all errors mean the guest has to die.
> @@ -453,18 +462,18 @@ static int new_vm_gid(struct acpi_config *config)
> return 1;
>
> /* copy to allocate BIOS memory */
> - buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
> + buf = (uint64_t *) ctxt->mem_ops.alloc(ctxt, sizeof(config->vm_gid), 8);
Once again this appears to be a cast that already before was
unnecessary. So it (and in any event the stray blank) should
perhaps already get deleted when you touch this line the first
time (in one of the earlier patches).
> --- a/tools/firmware/hvmloader/acpi/libacpi.h
> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
> @@ -64,6 +64,13 @@ struct acpi_numa {
> xen_vmemrange_t *vmemrange;
> };
>
> +struct acpi_ctxt {
> + struct acpi_mem_ops {
> + void *(*alloc)(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align);
> + unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
> + } mem_ops;
> +};
> +
> struct acpi_config {
> const unsigned char *dsdt_anycpu;
> unsigned int dsdt_anycpu_len;
While you mention this in the revision log, I don't see the reason
for keeping this fully separate. Quite a few of the changes you
do here could be avoided if the new structure got pointed to by a
field in struct acpi_config.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-08 13:58 ` Jan Beulich
@ 2016-07-08 15:23 ` Boris Ostrovsky
2016-07-08 15:35 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 15:23 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 09:58 AM, Jan Beulich wrote:
>>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
>> Components that wish to use ACPI builder will need to provide their own
>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
>> be passed to the builder as memory ops.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>
>> Changes in v1:
>> * Keep memory ops seprate from acpi_config, in struct acpi_context.
>>
>> Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who might want to
>> use those. The builder uses (should use) mem_alloc() to allocate memory for tables, not as a
>> general-purpose allocator.
> In addition to what I said back then, did you think of error cleanup
> paths here? Not all errors mean the guest has to die.
If there is an error and the builder decides to free up memory needed
for a table, how do we communicate to the caller which table has been
failed? Is it up to the builder to decide which tables are important and
which are not?
>
>>
>> +struct acpi_ctxt {
>> + struct acpi_mem_ops {
>> + void *(*alloc)(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align);
>> + unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>> + } mem_ops;
>> +};
>> +
>> struct acpi_config {
>> const unsigned char *dsdt_anycpu;
>> unsigned int dsdt_anycpu_len;
> While you mention this in the revision log, I don't see the reason
> for keeping this fully separate. Quite a few of the changes you
> do here could be avoided if the new structure got pointed to by a
> field in struct acpi_config.
I kept them separate here because acpi_config is intended to pass data
about tables content and acpi_ctxt is needed for storing info used for
building (ops, and as will be seen in patch 20, certain allocator
information).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-08 15:23 ` Boris Ostrovsky
@ 2016-07-08 15:35 ` Jan Beulich
2016-07-08 16:19 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 15:35 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 08.07.16 at 17:23, <boris.ostrovsky@oracle.com> wrote:
> On 07/08/2016 09:58 AM, Jan Beulich wrote:
>>>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
>>> Components that wish to use ACPI builder will need to provide their own
>>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
>>> be passed to the builder as memory ops.
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>>
>>> Changes in v1:
>>> * Keep memory ops seprate from acpi_config, in struct acpi_context.
>>>
>>> Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who might want to
>>> use those. The builder uses (should use) mem_alloc() to allocate memory for tables, not as a
>>> general-purpose allocator.
>> In addition to what I said back then, did you think of error cleanup
>> paths here? Not all errors mean the guest has to die.
>
> If there is an error and the builder decides to free up memory needed
> for a table, how do we communicate to the caller which table has been
> failed?
I don't understand - that's what the proposed free hook would be for.
> Is it up to the builder to decide which tables are important and which
> are not?
I'm afraid that's not so easy to tell. If for example we can't fit the
HPET table, the guest could be run without HPET unless a HPET
was specifically requested (rather than just defaulted to).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-08 15:35 ` Jan Beulich
@ 2016-07-08 16:19 ` Boris Ostrovsky
2016-07-19 9:11 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 16:19 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 11:35 AM, Jan Beulich wrote:
>>>> On 08.07.16 at 17:23, <boris.ostrovsky@oracle.com> wrote:
>> On 07/08/2016 09:58 AM, Jan Beulich wrote:
>>>>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
>>>> Components that wish to use ACPI builder will need to provide their own
>>>> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
>>>> be passed to the builder as memory ops.
>>>>
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> ---
>>>>
>>>> Changes in v1:
>>>> * Keep memory ops seprate from acpi_config, in struct acpi_context.
>>>>
>>>> Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who might want to
>>>> use those. The builder uses (should use) mem_alloc() to allocate memory for tables, not as a
>>>> general-purpose allocator.
>>> In addition to what I said back then, did you think of error cleanup
>>> paths here? Not all errors mean the guest has to die.
>> If there is an error and the builder decides to free up memory needed
>> for a table, how do we communicate to the caller which table has been
>> failed?
> I don't understand - that's what the proposed free hook would be for.
The hook will free the memory for the failed table.
What I meant was how will the caller know, upon return from the builder,
which tables have not been built? And so freeing a chunk of memory
doesn't really buy us much.
>
>> Is it up to the builder to decide which tables are important and which
>> are not?
> I'm afraid that's not so easy to tell. If for example we can't fit the
> HPET table, the guest could be run without HPET unless a HPET
> was specifically requested (rather than just defaulted to).
But again --- how will the caller know that it was only HPET table that
was not built?
I suppose we can return a bitmask of successes but that would be
somewhat awkward, don't you think?
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-08 16:19 ` Boris Ostrovsky
@ 2016-07-19 9:11 ` Jan Beulich
2016-07-19 14:08 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-19 9:11 UTC (permalink / raw)
To: boris.ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 07/08/16 6:20 PM >>>
>On 07/08/2016 11:35 AM, Jan Beulich wrote:
>>>>> On 08.07.16 at 17:23, <boris.ostrovsky@oracle.com> wrote:
>>> Is it up to the builder to decide which tables are important and which
>>> are not?
>> I'm afraid that's not so easy to tell. If for example we can't fit the
>> HPET table, the guest could be run without HPET unless a HPET
>> was specifically requested (rather than just defaulted to).
>
>But again --- how will the caller know that it was only HPET table that
>was not built?
Why would the caller care? I guess examples could be found where it is
necessary for the caller to know, but for the specific example (and at least
some others) failure is of no interest to the caller - it's only the guest which
is affected.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
2016-07-19 9:11 ` Jan Beulich
@ 2016-07-19 14:08 ` Boris Ostrovsky
0 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-19 14:08 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/19/2016 05:11 AM, Jan Beulich wrote:
>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 07/08/16 6:20 PM >>>
>> On 07/08/2016 11:35 AM, Jan Beulich wrote:
>>>>>> On 08.07.16 at 17:23, <boris.ostrovsky@oracle.com> wrote:
>>>> Is it up to the builder to decide which tables are important and which
>>>> are not?
>>> I'm afraid that's not so easy to tell. If for example we can't fit the
>>> HPET table, the guest could be run without HPET unless a HPET
>>> was specifically requested (rather than just defaulted to).
>> But again --- how will the caller know that it was only HPET table that
>> was not built?
> Why would the caller care? I guess examples could be found where it is
> necessary for the caller to know, but for the specific example (and at least
> some others) failure is of no interest to the caller - it's only the guest which
> is affected.
HPET was just an example, the same question could be asked for (almost)
any other table.
But I can see that we can defer to the guest to deal with ACPI
brokenness, although some not built tables will almost certainly lead to
guest's failure.
(We probably will not get to use this new free() op anyway since failure
to allocate memory is currently the only possible error and there is one
allocation per table)
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (9 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 14:31 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
` (9 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
tools/firmware/hvmloader/acpi/build.c | 47 +++++++++++++++++----------------
1 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 0adb3d6..4b0302c 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -126,7 +126,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
lapic = (struct acpi_20_madt_lapic *)(madt + 1);
config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
- config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
+ config->ainfo.madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
{
memset(lapic, 0, sizeof(*lapic));
@@ -143,7 +143,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
set_checksum(madt, offsetof(struct acpi_header, checksum),
madt->header.length);
- config->ainfo.madt_csum_addr = (uint32_t)&madt->header.checksum;
+ config->ainfo.madt_csum_addr =
+ ctxt->mem_ops.v2p(ctxt, &madt->header.checksum);
return madt;
}
@@ -311,7 +312,7 @@ static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
break;
memcpy(buffer, header, header->length);
- table_ptrs[nr_tables++] = (unsigned long)buffer;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
total += header->length;
acpi_pt_addr += header->length;
}
@@ -337,7 +338,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
{
madt = construct_madt(ctxt, config);
if (!madt) return -1;
- table_ptrs[nr_tables++] = (unsigned long)madt;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
}
/* HPET. */
@@ -345,7 +346,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
{
hpet = construct_hpet(ctxt, config);
if (!hpet) return -1;
- table_ptrs[nr_tables++] = (unsigned long)hpet;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
}
/* WAET. */
@@ -353,7 +354,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
{
waet = construct_waet(ctxt, config);
if ( !waet ) return -1;
- table_ptrs[nr_tables++] = (unsigned long)waet;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
}
if ( config->table_flags & ACPI_BUILD_SSDT_PM )
@@ -361,7 +362,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
- table_ptrs[nr_tables++] = (unsigned long)ssdt;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
}
if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
@@ -369,7 +370,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
- table_ptrs[nr_tables++] = (unsigned long)ssdt;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
} else {
printf("S3 disabled\n");
}
@@ -379,7 +380,7 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
- table_ptrs[nr_tables++] = (unsigned long)ssdt;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
} else {
printf("S4 disabled\n");
}
@@ -393,12 +394,12 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
if (!ssdt) return -1;
memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
- table_ptrs[nr_tables++] = (unsigned long)ssdt;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
if (!tcpa) return -1;
memset(tcpa, 0, sizeof(*tcpa));
- table_ptrs[nr_tables++] = (unsigned long)tcpa;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
tcpa->header.length = sizeof(*tcpa);
@@ -426,11 +427,11 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt,
struct acpi_20_slit *slit = construct_slit(ctxt, config);
if ( srat )
- table_ptrs[nr_tables++] = (unsigned long)srat;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, srat);
else
printf("Failed to build SRAT, skipping...\n");
if ( slit )
- table_ptrs[nr_tables++] = (unsigned long)slit;
+ table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, slit);
else
printf("Failed to build SLIT, skipping...\n");
}
@@ -527,8 +528,8 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
memcpy(fadt_10, &Fadt, sizeof(struct acpi_10_fadt));
fadt_10->header.length = sizeof(struct acpi_10_fadt);
fadt_10->header.revision = ACPI_1_0_FADT_REVISION;
- fadt_10->dsdt = (unsigned long)dsdt;
- fadt_10->firmware_ctrl = (unsigned long)facs;
+ fadt_10->dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
+ fadt_10->firmware_ctrl = ctxt->mem_ops.v2p(ctxt, facs);
set_checksum(fadt_10,
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_10_fadt));
@@ -536,10 +537,10 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
if (!fadt) goto oom;
memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
- fadt->dsdt = (unsigned long)dsdt;
- fadt->x_dsdt = (unsigned long)dsdt;
- fadt->firmware_ctrl = (unsigned long)facs;
- fadt->x_firmware_ctrl = (unsigned long)facs;
+ fadt->dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
+ fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
+ fadt->firmware_ctrl = ctxt->mem_ops.v2p(ctxt, facs);
+ fadt->x_firmware_ctrl = ctxt->mem_ops.v2p(ctxt, facs);
set_checksum(fadt,
offsetof(struct acpi_header, checksum),
sizeof(struct acpi_20_fadt));
@@ -553,7 +554,7 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
16);
if (!xsdt) goto oom;
memcpy(xsdt, &Xsdt, sizeof(struct acpi_header));
- xsdt->entry[0] = (unsigned long)fadt;
+ xsdt->entry[0] = ctxt->mem_ops.v2p(ctxt, fadt);
for ( i = 0; secondary_tables[i]; i++ )
xsdt->entry[i+1] = secondary_tables[i];
xsdt->header.length = sizeof(struct acpi_header) + (i+1)*sizeof(uint64_t);
@@ -566,7 +567,7 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
16);
if (!rsdt) goto oom;
memcpy(rsdt, &Rsdt, sizeof(struct acpi_header));
- rsdt->entry[0] = (unsigned long)fadt_10;
+ rsdt->entry[0] = ctxt->mem_ops.v2p(ctxt, fadt_10);
for ( i = 0; secondary_tables[i]; i++ )
rsdt->entry[i+1] = secondary_tables[i];
rsdt->header.length = sizeof(struct acpi_header) + (i+1)*sizeof(uint32_t);
@@ -580,8 +581,8 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
rsdp = (struct acpi_20_rsdp *)config->rsdp;
memcpy(rsdp, &Rsdp, sizeof(struct acpi_20_rsdp));
- rsdp->rsdt_address = (unsigned long)rsdt;
- rsdp->xsdt_address = (unsigned long)xsdt;
+ rsdp->rsdt_address = ctxt->mem_ops.v2p(ctxt, rsdt);
+ rsdp->xsdt_address = ctxt->mem_ops.v2p(ctxt, xsdt);
set_checksum(rsdp,
offsetof(struct acpi_10_rsdp, checksum),
sizeof(struct acpi_10_rsdp));
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (10 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 14:51 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments Boris Ostrovsky
` (8 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Build ASL and C files in target's (hvmloader) directory
.gitignore | 8 +++---
tools/firmware/hvmloader/Makefile | 11 ++++++++-
tools/firmware/hvmloader/acpi/Makefile | 37 +++++++++++++++----------------
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/.gitignore b/.gitignore
index e019f2e..9dd2086 100644
--- a/.gitignore
+++ b/.gitignore
@@ -126,10 +126,10 @@ tools/firmware/*bios/*bios*.txt
tools/firmware/etherboot/gpxe/*
tools/firmware/extboot/extboot.img
tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/mk_dsdt
+tools/firmware/hvmloader/dsdt*.c
+tools/firmware/hvmloader/dsdt_*.asl
+tools/firmware/hvmloader/ssdt_*.h
tools/firmware/hvmloader/hvmloader
tools/firmware/hvmloader/roms.h
tools/firmware/hvmloader/roms.inc
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index f2f4791..043da50 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/firmware/Rules.mk
+export ACPI_BUILD_DIR=$(shell pwd)
SUBDIRS := acpi
# The HVM loader is started in 32-bit mode at the address below:
@@ -95,7 +96,15 @@ all: subdirs-all
ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c static_tables.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..4866912 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,36 +17,41 @@
XEN_ROOT = $(CURDIR)/../../../..
include $(XEN_ROOT)/tools/firmware/Rules.mk
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c dsdt_anycpu_qemu_xen.c
-OBJS = $(patsubst %.c,%.o,$(C_SRC))
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
-CFLAGS += $(CFLAGS_xeninclude)
+# Sources to be generated
+C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c
+H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h $(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+ cd $(ACPI_BUILD_DIR)
iasl -vs -p $* -tc $<
sed -e 's/AmlCode/$*/g' $*.hex >$@
rm -f $*.hex $*.aml
+ cd $(CURDIR)
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
- ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+ $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
# NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
- ./mk_dsdt --debug=$(debug) --maxcpu $* >> $@
+ $(MK_DSDT) --debug=$(debug) --maxcpu $* >> $@
-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
- iasl -vs -p $* -tc $*.asl
+$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
+ cd $(ACPI_BUILD_DIR)
+ iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/$*.asl
sed -e 's/AmlCode/$*/g' $*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
rm -f $*.aml $*.hex
+ cd $(CURDIR)
iasl:
@echo
@@ -56,14 +61,8 @@ iasl:
@echo
@exit 1
-build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
-
-acpi.a: $(OBJS)
- $(AR) rc $@ $(OBJS)
-
clean:
- rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
- rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+ rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
distclean: clean
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly
2016-07-05 19:05 ` [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
@ 2016-07-08 14:51 ` Jan Beulich
2016-07-08 15:41 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 14:51 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> @@ -95,7 +96,15 @@ all: subdirs-all
> ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
> smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>
> -hvmloader: $(OBJS) acpi/acpi.a
> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
I think I did say so already on the RFC series: I'd much prefer if we
could stick to relative references, so trees have a better chances of
being movable.
> +ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c static_tables.c
> +ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
> +$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
What is the -I. needed for? The ACPI files shouldn't be referencing
other hvmloader files, and generated .h files should be included
using "" instead of <>.
> +vpath build.c $(ACPI_PATH)/
> +vpath static_tables.c $(ACPI_PATH)/
I don't think the trailing slashes are needed here.
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -17,36 +17,41 @@
> XEN_ROOT = $(CURDIR)/../../../..
> include $(XEN_ROOT)/tools/firmware/Rules.mk
>
> -C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
> dsdt_anycpu_qemu_xen.c
> -OBJS = $(patsubst %.c,%.o,$(C_SRC))
> +MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>
> -CFLAGS += $(CFLAGS_xeninclude)
> +# Sources to be generated
> +C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c
> +H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h $(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
Use $(addprefix ) to limit line length?
> vpath iasl $(PATH)
> -all: acpi.a
> +all: $(C_SRC) $(H_SRC)
>
> -ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> +$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> + cd $(ACPI_BUILD_DIR)
> iasl -vs -p $* -tc $<
> sed -e 's/AmlCode/$*/g' $*.hex >$@
> rm -f $*.hex $*.aml
> + cd $(CURDIR)
cd in a make rule feel wrong. Could you prefix most of the $* with
$(ACPI_BUILD_DIR)/ instead?
> @@ -56,14 +61,8 @@ iasl:
> @echo
> @exit 1
>
> -build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
> -
> -acpi.a: $(OBJS)
> - $(AR) rc $@ $(OBJS)
> -
> clean:
> - rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
> - rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
> + rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
It seems to me that this would better done in from the consumer's
clean rule.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly
2016-07-08 14:51 ` Jan Beulich
@ 2016-07-08 15:41 ` Boris Ostrovsky
0 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 15:41 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
On 07/08/2016 10:51 AM, Jan Beulich wrote:
>
>> +ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c static_tables.c
>> +ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
>> +$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
> What is the -I. needed for? The ACPI files shouldn't be referencing
> other hvmloader files, and generated .h files should be included
> using "" instead of <>.
That's because we are building in tools/firmware/hvmloader (not
tools/firmware/hvmloader/acpi) and, for example, build.c includes header
files generated into tools/firmware/hvmloader. I also don't like adding
this but couldn't come up with a better solution.
>
> -
> clean:
> - rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
> - rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
> + rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
> It seems to me that this would better done in from the consumer's
> clean rule.
How does the consumer know what to clean? For example, some generated
header files are not directly used by the consumer.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (11 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-08 15:51 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi Boris Ostrovsky
` (7 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
In prepearation to moving acpi sources into generally available
libacpi:
1. Move certain x86-specific definitions into acpi's x86.h
2. Modify include files serach paths to point to acpi
3. Macro-ise include file for build.c that defines various
utilities used by that file. Users of libacpi will be expected
to define this macro when compiling build.c
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Pass build.c include file that declates all standard utilities (printf. strcmp etc)
as DSTDUTILS macro
x86-specific definitions are kept locally in x86.h. I wonder, however, whether this
should go somewhere in xen/include/public/<arch>. See, for example, patch 19
that demonstrates that having x86.h live in libacpi.h may not be such a great idea.
tools/firmware/hvmloader/Makefile | 3 +-
tools/firmware/hvmloader/acpi/README | 17 +++++++++++---
tools/firmware/hvmloader/acpi/build.c | 5 +--
tools/firmware/hvmloader/acpi/x86.h | 38 +++++++++++++++++++++++++++++++++
tools/firmware/hvmloader/config.h | 6 -----
tools/firmware/hvmloader/hvmloader.c | 3 +-
tools/firmware/hvmloader/mp_tables.c | 1 +
tools/firmware/hvmloader/ovmf.c | 2 +-
tools/firmware/hvmloader/pci.c | 1 +
tools/firmware/hvmloader/pir.c | 1 +
tools/firmware/hvmloader/rombios.c | 2 +-
tools/firmware/hvmloader/seabios.c | 4 +-
tools/firmware/hvmloader/smp.c | 1 +
tools/firmware/hvmloader/util.c | 5 ++-
14 files changed, 68 insertions(+), 21 deletions(-)
create mode 100644 tools/firmware/hvmloader/acpi/x86.h
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 043da50..920b0d0 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -99,7 +99,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c static_tables.c
ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
vpath build.c $(ACPI_PATH)/
vpath static_tables.c $(ACPI_PATH)/
OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README b/tools/firmware/hvmloader/acpi/README
index 210d5ba..1d603ea 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
-INSTALL
+BUILDING ACPI
-----------------
-Simply make is OK.
-# make
+Users of ACPI builder are expected to provide an include file that defines
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
+When compiling build.c, the name of this include file should be given to
+compiler as -DSTDUTILS=\"<filename>\". See tools/firmware/hvmloader/Makefile
+for an example.
Note on DSDT Table
------------------
@@ -22,3 +30,4 @@ DSDT compiler "iasl" is needed. By default, it will be downloaded
using wget in Makefile. if it failed, please download manually from
http://developer.intel.com/technology/iapc/acpi/downloads.htm.
then compile and install iasl
+
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 4b0302c..290f005 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -15,15 +15,14 @@
* this program; If not, see <http://www.gnu.org/licenses/>.
*/
+#include STDUTILS
#include "acpi2_0.h"
#include "libacpi.h"
#include "ssdt_s3.h"
#include "ssdt_s4.h"
#include "ssdt_tpm.h"
#include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
+#include "x86.h"
#include <xen/hvm/hvm_xs_strings.h>
#include <xen/hvm/params.h>
diff --git a/tools/firmware/hvmloader/acpi/x86.h b/tools/firmware/hvmloader/acpi/x86.h
new file mode 100644
index 0000000..21cad0d
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/x86.h
@@ -0,0 +1,38 @@
+/******************************************************************************
+ * x86.h
+ *
+ * x86-specific interfaces used by ACPI builder and its callers
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#ifndef __ACPI_X86_H__
+#define __ACPI_X86_H__
+
+#define IOAPIC_BASE_ADDRESS 0xfec00000
+#define IOAPIC_ID 0x01
+
+#define LAPIC_BASE_ADDRESS 0xfee00000
+#define LAPIC_ID(vcpu_id) ((vcpu_id) * 2)
+
+#define PCI_ISA_IRQ_MASK 0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
+
+#endif /* __ACPI_X86_H__ */
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index c7460fb..d847b86 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -42,15 +42,9 @@ extern struct bios_config ovmf_config;
#define PAGE_SHIFT 12
#define PAGE_SIZE (1ul << PAGE_SHIFT)
-#define IOAPIC_BASE_ADDRESS 0xfec00000
-#define IOAPIC_ID 0x01
#define IOAPIC_VERSION 0x11
-#define LAPIC_BASE_ADDRESS 0xfee00000
-#define LAPIC_ID(vcpu_id) ((vcpu_id) * 2)
-
#define PCI_ISA_DEVFN 0x08 /* dev 1, fn 0 */
-#define PCI_ISA_IRQ_MASK 0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
/* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
#define PCI_MEM_END 0xfc000000
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 716d03c..06a1665 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -24,8 +24,9 @@
#include "config.h"
#include "pci_regs.h"
#include "apic_regs.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
#include "vnuma.h"
+#include "x86.h"
#include <xen/version.h>
#include <xen/hvm/params.h>
diff --git a/tools/firmware/hvmloader/mp_tables.c b/tools/firmware/hvmloader/mp_tables.c
index 69c2885..4d21304 100644
--- a/tools/firmware/hvmloader/mp_tables.c
+++ b/tools/firmware/hvmloader/mp_tables.c
@@ -29,6 +29,7 @@
#include <stdint.h>
#include "config.h"
+#include "x86.h"
/* number of non-processor MP table entries */
#define NR_NONPROC_ENTRIES 18
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 74fec56..e7c48a5 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -23,7 +23,7 @@
#include "config.h"
#include "smbios_types.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
#include "apic_regs.h"
#include "../rombios/config.h"
#include "util.h"
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4eb1a31..d265109 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -23,6 +23,7 @@
#include "hypercall.h"
#include "config.h"
#include "pci_regs.h"
+#include "x86.h"
#include <xen/memory.h>
#include <xen/hvm/ioreq.h>
diff --git a/tools/firmware/hvmloader/pir.c b/tools/firmware/hvmloader/pir.c
index cc420dd..f95bcea 100644
--- a/tools/firmware/hvmloader/pir.c
+++ b/tools/firmware/hvmloader/pir.c
@@ -16,6 +16,7 @@
#include "config.h"
#include "pir_types.h"
#include "util.h"
+#include "x86.h"
/*
* The structure of these tables is described in
diff --git a/tools/firmware/hvmloader/rombios.c b/tools/firmware/hvmloader/rombios.c
index 1f8fc2d..863c1a7 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -24,7 +24,7 @@
#include "../rombios/config.h"
#include "smbios_types.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
#include "pci_regs.h"
#include "util.h"
#include "hypercall.h"
diff --git a/tools/firmware/hvmloader/seabios.c b/tools/firmware/hvmloader/seabios.c
index 2fbc3af..aadae30 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -25,8 +25,8 @@
#include "util.h"
#include "smbios_types.h"
-#include "acpi/acpi2_0.h"
-#include "acpi/libacpi.h"
+#include "acpi2_0.h"
+#include "libacpi.h"
#define ROM_INCLUDE_SEABIOS
#include "roms.inc"
diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
index 082b17f..4c6c3c6 100644
--- a/tools/firmware/hvmloader/smp.c
+++ b/tools/firmware/hvmloader/smp.c
@@ -22,6 +22,7 @@
#include "util.h"
#include "config.h"
#include "apic_regs.h"
+#include "x86.h"
#define AP_BOOT_EIP 0x1000
extern char ap_boot_start[], ap_boot_end[];
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9438571..b7c9ff2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,8 +22,9 @@
#include "hypercall.h"
#include "ctype.h"
#include "vnuma.h"
-#include "acpi/acpi2_0.h"
-#include "acpi/libacpi.h"
+#include "acpi2_0.h"
+#include "libacpi.h"
+#include "x86.h"
#include <stdint.h>
#include <xen/xen.h>
#include <xen/memory.h>
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments
2016-07-05 19:05 ` [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments Boris Ostrovsky
@ 2016-07-08 15:51 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-08 15:51 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> x86-specific definitions are kept locally in x86.h. I wonder, however, whether this
> should go somewhere in xen/include/public/<arch>. See, for example, patch 19
> that demonstrates that having x86.h live in libacpi.h may not be such a
> great idea.
None of what you put there in this patch looks like a candidate for
becoming part of the public interface.
> @@ -22,3 +30,4 @@ DSDT compiler "iasl" is needed. By default, it will be downloaded
> using wget in Makefile. if it failed, please download manually from
> http://developer.intel.com/technology/iapc/acpi/downloads.htm.
> then compile and install iasl
> +
Please don't.
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -24,8 +24,9 @@
> #include "config.h"
> #include "pci_regs.h"
> #include "apic_regs.h"
> -#include "acpi/acpi2_0.h"
> +#include "acpi2_0.h"
Is this really still needed here an in all of the further places where
you convert its path? I'd generally expect libacpi.h to be the only
interface needed now.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (12 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-08-03 16:00 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated Boris Ostrovsky
` (6 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
tools/firmware/hvmloader/Makefile | 14 ++++++++------
.../{firmware/hvmloader/acpi => libacpi}/Makefile | 2 +-
tools/{firmware/hvmloader/acpi => libacpi}/README | 0
.../{firmware/hvmloader/acpi => libacpi}/acpi2_0.h | 0
tools/{firmware/hvmloader/acpi => libacpi}/build.c | 0
.../{firmware/hvmloader/acpi => libacpi}/dsdt.asl | 0
.../{firmware/hvmloader/acpi => libacpi}/libacpi.h | 0
.../{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c | 0
.../hvmloader/acpi => libacpi}/ssdt_pm.asl | 0
.../hvmloader/acpi => libacpi}/ssdt_s3.asl | 0
.../hvmloader/acpi => libacpi}/ssdt_s4.asl | 0
.../hvmloader/acpi => libacpi}/ssdt_tpm.asl | 0
.../hvmloader/acpi => libacpi}/static_tables.c | 0
tools/{firmware/hvmloader/acpi => libacpi}/x86.h | 0
14 files changed, 9 insertions(+), 7 deletions(-)
rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)
rename tools/{firmware/hvmloader/acpi => libacpi}/x86.h (100%)
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 920b0d0..39a0156 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,9 +20,6 @@
XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/firmware/Rules.mk
-export ACPI_BUILD_DIR=$(shell pwd)
-SUBDIRS := acpi
-
# The HVM loader is started in 32-bit mode at the address below:
LOADADDR = 0x100000
@@ -90,16 +87,20 @@ ROMS += $(SEABIOS_ROM)
endif
.PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
+.PHONY: acpi
+acpi:
+ $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)
+
ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
-ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+ACPI_PATH = $(XEN_ROOT)/tools/libacpi
ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c static_tables.c
ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
-$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/util.h\"
CFLAGS += -I$(ACPI_PATH)
vpath build.c $(ACPI_PATH)/
vpath static_tables.c $(ACPI_PATH)/
@@ -153,6 +154,7 @@ endif
clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+ $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd) clean
.PHONY: distclean
distclean: clean
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/libacpi/Makefile
similarity index 98%
rename from tools/firmware/hvmloader/acpi/Makefile
rename to tools/libacpi/Makefile
index 4866912..cc0dc31 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -14,7 +14,7 @@
# this program; If not, see <http://www.gnu.org/licenses/>.
#
-XEN_ROOT = $(CURDIR)/../../../..
+XEN_ROOT = $(CURDIR)/../../
include $(XEN_ROOT)/tools/firmware/Rules.mk
MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
diff --git a/tools/firmware/hvmloader/acpi/README b/tools/libacpi/README
similarity index 100%
rename from tools/firmware/hvmloader/acpi/README
rename to tools/libacpi/README
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/acpi2_0.h
rename to tools/libacpi/acpi2_0.h
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/libacpi/build.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/build.c
rename to tools/libacpi/build.c
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/libacpi/dsdt.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/dsdt.asl
rename to tools/libacpi/dsdt.asl
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/libacpi/libacpi.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/libacpi.h
rename to tools/libacpi/libacpi.h
diff --git a/tools/firmware/hvmloader/acpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/mk_dsdt.c
rename to tools/libacpi/mk_dsdt.c
diff --git a/tools/firmware/hvmloader/acpi/ssdt_pm.asl b/tools/libacpi/ssdt_pm.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_pm.asl
rename to tools/libacpi/ssdt_pm.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_s3.asl b/tools/libacpi/ssdt_s3.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_s3.asl
rename to tools/libacpi/ssdt_s3.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_s4.asl b/tools/libacpi/ssdt_s4.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_s4.asl
rename to tools/libacpi/ssdt_s4.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_tpm.asl b/tools/libacpi/ssdt_tpm.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_tpm.asl
rename to tools/libacpi/ssdt_tpm.asl
diff --git a/tools/firmware/hvmloader/acpi/static_tables.c b/tools/libacpi/static_tables.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/static_tables.c
rename to tools/libacpi/static_tables.c
diff --git a/tools/firmware/hvmloader/acpi/x86.h b/tools/libacpi/x86.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/x86.h
rename to tools/libacpi/x86.h
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi
2016-07-05 19:05 ` [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi Boris Ostrovsky
@ 2016-08-03 16:00 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-08-03 16:00 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
with a suggestion and a minor remark:
> @@ -90,16 +87,20 @@ ROMS += $(SEABIOS_ROM)
> endif
>
> .PHONY: all
> -all: subdirs-all
> +all: acpi subdirs-all
> $(MAKE) hvmloader
>
> +.PHONY: acpi
> +acpi:
> + $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)
$(CURDIR) ?
> @@ -153,6 +154,7 @@ endif
> clean: subdirs-clean
> rm -f roms.inc roms.inc.new acpi.h
> rm -f hvmloader hvmloader.tmp *.o $(DEPS)
> + $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd) clean
Again.
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -14,7 +14,7 @@
> # this program; If not, see <http://www.gnu.org/licenses/>.
> #
>
> -XEN_ROOT = $(CURDIR)/../../../..
> +XEN_ROOT = $(CURDIR)/../../
Not how the original does not end in a slash.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (13 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-08-03 16:04 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
` (5 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* More checks, in more approriate places
xen/arch/x86/hvm/vlapic.c | 12 ++++++++++--
xen/arch/x86/hvm/vpt.c | 2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index e2f4450..a3855c8 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1115,7 +1115,12 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
struct domain *d = v->domain;
struct vlapic *vlapic = vcpu_vlapic(v);
uint32_t lvt0 = vlapic_get_reg(vlapic, APIC_LVT0);
- union vioapic_redir_entry redir0 = domain_vioapic(d)->redirtbl[0];
+ union vioapic_redir_entry redir0;
+
+ if ( !has_vioapic(d) || !has_vpic(d) )
+ return 0;
+
+ redir0 = domain_vioapic(d)->redirtbl[0];
/* We deliver 8259 interrupts to the appropriate CPU as follows. */
return ((/* IOAPIC pin0 is unmasked and routing to this LAPIC? */
@@ -1131,7 +1136,7 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
int vlapic_accept_pic_intr(struct vcpu *v)
{
- if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+ if ( vlapic_hw_disabled(vcpu_vlapic(v)) || !has_vpic(v->domain) )
return 0;
TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR,
@@ -1146,6 +1151,9 @@ void vlapic_adjust_i8259_target(struct domain *d)
{
struct vcpu *v;
+ if ( !has_vpic(d) )
+ return;
+
for_each_vcpu ( d, v )
if ( __vlapic_accept_pic_intr(v) )
goto found;
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index 358ec57..c90aa95 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -496,7 +496,7 @@ void pt_adjust_global_vcpu_target(struct vcpu *v)
struct pl_time *pl_time;
int i;
- if ( v == NULL )
+ if ( v == NULL || !has_vpit(v->domain) )
return;
vpit = &v->domain->arch.vpit;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated
2016-07-05 19:05 ` [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated Boris Ostrovsky
@ 2016-08-03 16:04 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-08-03 16:04 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1115,7 +1115,12 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
> struct domain *d = v->domain;
> struct vlapic *vlapic = vcpu_vlapic(v);
> uint32_t lvt0 = vlapic_get_reg(vlapic, APIC_LVT0);
> - union vioapic_redir_entry redir0 = domain_vioapic(d)->redirtbl[0];
> + union vioapic_redir_entry redir0;
> +
> + if ( !has_vioapic(d) || !has_vpic(d) )
The has_vpic() part should really be an ASSERT(), as both callers
already do that check afaics. With that adjusted
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (14 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-08-03 16:11 ` Jan Beulich
2016-07-05 19:05 ` [PATCH v1 17/20] libacpi: Build DSDT for PVH guests Boris Ostrovsky
` (4 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
PVHv2 guests may request LAPIC emulation (and nothing else)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Refer to PVHv2 (not hvmlite)
xen/arch/x86/domain.c | 26 ++++++++++++++++----------
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 989bc74..c495a29 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags,
}
else
{
- if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+ uint32_t emflags;
+
+ if ( is_hardware_domain(d) )
+ config->emulation_flags |= XEN_X86_EMU_PIT;
+
+ emflags = config->emulation_flags;
+ if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )
{
printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
- d->domain_id, config->emulation_flags);
+ d->domain_id, emflags);
return -EINVAL;
}
- if ( is_hardware_domain(d) )
- config->emulation_flags |= XEN_X86_EMU_PIT;
- if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
- (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+ /* PVHv2 guests can request emulated APIC */
+ if ( emflags &&
+ (is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+ (emflags != XEN_X86_EMU_PIT)) )
{
printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
- d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
- config->emulation_flags);
+ d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
return -EOPNOTSUPP;
}
- d->arch.emulation_flags = config->emulation_flags;
+ d->arch.emulation_flags = emflags;
}
if ( has_hvm_container_domain(d) )
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests
2016-07-05 19:05 ` [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
@ 2016-08-03 16:11 ` Jan Beulich
2016-08-03 16:15 ` Andrew Cooper
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-08-03 16:11 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong, roger.pau
>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> }
> else
> {
> - if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
> + uint32_t emflags;
> +
> + if ( is_hardware_domain(d) )
> + config->emulation_flags |= XEN_X86_EMU_PIT;
> +
> + emflags = config->emulation_flags;
> + if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )
In cases like this please consider dropping the pointless != 0.
> {
> printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
> - d->domain_id, config->emulation_flags);
> + d->domain_id, emflags);
> return -EINVAL;
> }
> - if ( is_hardware_domain(d) )
> - config->emulation_flags |= XEN_X86_EMU_PIT;
> - if ( config->emulation_flags != 0 &&
> - (config->emulation_flags !=
> - (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
> +
> + /* PVHv2 guests can request emulated APIC */
Comment style. With at least this one fixed
Reviewed-by: Jan Beulich <jbeulich@suse.com>
> + if ( emflags &&
> + (is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
> + (emflags != XEN_X86_EMU_LAPIC)) :
> + (emflags != XEN_X86_EMU_PIT)) )
I guess sooner or later this will need re-arranging so that it's easier
to maintain when more variations are permitted for HVM, but for
now I think it's fine.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests
2016-08-03 16:11 ` Jan Beulich
@ 2016-08-03 16:15 ` Andrew Cooper
0 siblings, 0 replies; 104+ messages in thread
From: Andrew Cooper @ 2016-08-03 16:15 UTC (permalink / raw)
To: Jan Beulich, Boris Ostrovsky
Cc: wei.liu2, ian.jackson, xen-devel, julien.grall, zhaoshenglong,
Roger Pau Monne
On 03/08/16 17:11, Jan Beulich wrote:
>>>> On 05.07.16 at 21:05, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags,
>> }
>> else
>> {
>> - if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
>> + uint32_t emflags;
>> +
>> + if ( is_hardware_domain(d) )
>> + config->emulation_flags |= XEN_X86_EMU_PIT;
>> +
>> + emflags = config->emulation_flags;
>> + if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )
> In cases like this please consider dropping the pointless != 0.
>
>> {
>> printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
>> - d->domain_id, config->emulation_flags);
>> + d->domain_id, emflags);
>> return -EINVAL;
>> }
>> - if ( is_hardware_domain(d) )
>> - config->emulation_flags |= XEN_X86_EMU_PIT;
>> - if ( config->emulation_flags != 0 &&
>> - (config->emulation_flags !=
>> - (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
>> +
>> + /* PVHv2 guests can request emulated APIC */
> Comment style. With at least this one fixed
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>
>> + if ( emflags &&
>> + (is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
>> + (emflags != XEN_X86_EMU_LAPIC)) :
>> + (emflags != XEN_X86_EMU_PIT)) )
> I guess sooner or later this will need re-arranging so that it's easier
> to maintain when more variations are permitted for HVM, but for
> now I think it's fine.
Roger already did this at my request on a different thread.
Message: <20160801112343.7ndtre6tfzxk3xjd@mac>, subject "[PATCH RFC
03/12] xen/x86: allow the emulated APICs to be enbled for the hardware
domain"
And on that note, Roger: you have a typo in your patch subject.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 17/20] libacpi: Build DSDT for PVH guests
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (15 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-05 19:05 ` [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry Boris Ostrovsky
` (3 subsequent siblings)
20 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
New patch
tools/libacpi/Makefile | 24 ++++++++++++++++++++----
tools/libacpi/dsdt.asl | 20 --------------------
tools/libacpi/dsdt_acpi_info.asl | 23 +++++++++++++++++++++++
tools/libacpi/mk_dsdt.c | 10 ++++++++++
4 files changed, 53 insertions(+), 24 deletions(-)
create mode 100644 tools/libacpi/dsdt_acpi_info.asl
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index cc0dc31..4068d9a 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -20,7 +20,8 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
# Sources to be generated
-C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c
+C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c
+C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c $(ACPI_BUILD_DIR)/dsdt_pvh.c
H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h $(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
vpath iasl $(PATH)
@@ -36,13 +37,15 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
-$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+ cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
# NB. awk invocation is a portable alternative to 'head -n -1'
-$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+ cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --maxcpu $* >> $@
$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
@@ -53,6 +56,19 @@ $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
rm -f $*.aml $*.hex
cd $(CURDIR)
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+ printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 2, \"Xen\", \"HVM\", 0)\n{" > $@
+ cat dsdt_acpi_info.asl >> $@
+ $(MK_DSDT) --debug=$(debug) --maxcpu any --no-dm >> $@
+
+$(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+ cd $(ACPI_BUILD_DIR)
+ iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+ sed -e 's/AmlCode/dsdt_pvh/g' $*.hex >$@
+ echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
+ rm -f $*.aml $*.hex
+ cd $(CURDIR)
+
iasl:
@echo
@echo "ACPI ASL compiler (iasl) is needed"
@@ -62,7 +78,7 @@ iasl:
@exit 1
clean:
- rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
+ rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC)) $(ACPI_BUILD_DIR)/dsdt_pvh.c
distclean: clean
diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index bd65823..b14f5d0 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -43,26 +43,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
Scope (\_SB)
{
- /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC000000 */
- OperationRegion(BIOS, SystemMemory, 0xFC000000, 40)
- Field(BIOS, ByteAcc, NoLock, Preserve) {
- UAR1, 1,
- UAR2, 1,
- LTP1, 1,
- HPET, 1,
- Offset(2),
- NCPU, 16,
- PMIN, 32,
- PLEN, 32,
- MSUA, 32, /* MADT checksum address */
- MAPA, 32, /* MADT LAPIC0 address */
- VGIA, 32, /* VM generation id address */
- LMIN, 32,
- HMIN, 32,
- LLEN, 32,
- HLEN, 32
- }
-
/* Fix HCT test for 0x400 pci memory:
* - need to report low 640 MB mem as motherboard resource
*/
diff --git a/tools/libacpi/dsdt_acpi_info.asl b/tools/libacpi/dsdt_acpi_info.asl
new file mode 100644
index 0000000..eeecd49
--- /dev/null
+++ b/tools/libacpi/dsdt_acpi_info.asl
@@ -0,0 +1,23 @@
+
+ Scope (\_SB)
+ {
+ /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC000000 */
+ OperationRegion(BIOS, SystemMemory, 0xFC000000, 40)
+ Field(BIOS, ByteAcc, NoLock, Preserve) {
+ UAR1, 1,
+ UAR2, 1,
+ LTP1, 1,
+ HPET, 1,
+ Offset(2),
+ NCPU, 16,
+ PMIN, 32,
+ PLEN, 32,
+ MSUA, 32, /* MADT checksum address */
+ MAPA, 32, /* MADT LAPIC0 address */
+ VGIA, 32, /* VM generation id address */
+ LMIN, 32,
+ HMIN, 32,
+ LLEN, 32,
+ HLEN, 32
+ }
+ }
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index b2ade89..1322510 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -86,6 +86,7 @@ static struct option options[] = {
{ "maxcpu", 1, 0, 'c' },
{ "dm-version", 1, 0, 'q' },
{ "debug", 1, 0, 'd' },
+ { "no-dm", 0, 0, 'n' },
{ 0, 0, 0, 0 }
};
@@ -93,6 +94,7 @@ int main(int argc, char **argv)
{
unsigned int slot, dev, intx, link, cpu, max_cpus = HVM_MAX_VCPUS;
dm_version dm_version = QEMU_XEN_TRADITIONAL;
+ bool no_dm = 0;
for ( ; ; )
{
@@ -128,6 +130,9 @@ int main(int argc, char **argv)
return -1;
}
break;
+ case 'n':
+ no_dm = 1;
+ break;
case 'd':
if (*optarg == 'y')
debug = true;
@@ -240,6 +245,11 @@ int main(int argc, char **argv)
pop_block();
+ if (no_dm) {
+ pop_block();
+ return 0;
+ }
+
/* Define GPE control method. */
push_block("Scope", "\\_GPE");
push_block("Method",
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (16 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 17/20] libacpi: Build DSDT for PVH guests Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-06 10:00 ` Julien Grall
2016-07-05 19:05 ` [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests Boris Ostrovsky
` (2 subsequent siblings)
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Add entry for ACPI tables created for PVHv2 guests to e820 map.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
New patch
tools/libxc/include/xc_dom.h | 4 ++++
tools/libxl/libxl_dom.c | 8 ++++----
tools/libxl/libxl_x86.c | 11 +++++++++++
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..ec2da14 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -102,6 +102,10 @@ struct xc_dom_image {
xen_vaddr_t virt_alloc_end;
xen_vaddr_t bsd_symtab_start;
+ /* ACPI tables (PVHv2 only) */
+ xen_pfn_t acpi_pfn;
+ xen_pfn_t acpi_pages;
+
/*
* initrd parameters as specified in start_info page
* Depending on capabilities of the booted kernel this may be a virtual
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ec29060..ccc41b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1063,16 +1063,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
}
+ rc = libxl__build_dom(gc, domid, info, state, dom);
+ if (rc != 0)
+ goto out;
+
rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
if (rc != 0) {
LOG(ERROR, "setting domain memory map failed");
goto out;
}
- rc = libxl__build_dom(gc, domid, info, state, dom);
- if (rc != 0)
- goto out;
-
rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
&state->store_mfn, state->console_port,
&state->console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..32ce1d2 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -503,6 +503,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
if (highmem_size)
e820_entries++;
+ /* PVHv2's ACPI tables */
+ if (dom->acpi_pages)
+ e820_entries++;
+
if (e820_entries >= E820MAX) {
LOG(ERROR, "Ooops! Too many entries in the memory map!");
rc = ERROR_INVAL;
@@ -528,6 +532,13 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
nr++;
}
+ if (dom->acpi_pages) {
+ e820[nr].addr = dom->acpi_pfn << XC_DOM_PAGE_SHIFT(dom);
+ e820[nr].size = dom->acpi_pages << XC_DOM_PAGE_SHIFT(dom);
+ e820[nr].type = E820_ACPI;
+ nr++;
+ }
+
/* High memory */
if (highmem_size) {
e820[nr].addr = ((uint64_t)1 << 32);
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry
2016-07-05 19:05 ` [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry Boris Ostrovsky
@ 2016-07-06 10:00 ` Julien Grall
2016-07-06 15:43 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-06 10:00 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
(CC Stefano)
Hi Boris,
On 05/07/16 20:05, Boris Ostrovsky wrote:
> Add entry for ACPI tables created for PVHv2 guests to e820 map.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> New patch
>
> tools/libxc/include/xc_dom.h | 4 ++++
> tools/libxl/libxl_dom.c | 8 ++++----
> tools/libxl/libxl_x86.c | 11 +++++++++++
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6cb10c4..ec2da14 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -102,6 +102,10 @@ struct xc_dom_image {
> xen_vaddr_t virt_alloc_end;
> xen_vaddr_t bsd_symtab_start;
>
> + /* ACPI tables (PVHv2 only) */
> + xen_pfn_t acpi_pfn;
> + xen_pfn_t acpi_pages;
> +
It would be good if we can share the fields with ARM (see [1]).
Regards,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00301.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry
2016-07-06 10:00 ` Julien Grall
@ 2016-07-06 15:43 ` Boris Ostrovsky
0 siblings, 0 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-06 15:43 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
On 07/06/2016 06:00 AM, Julien Grall wrote:
> (CC Stefano)
>
> Hi Boris,
>
> On 05/07/16 20:05, Boris Ostrovsky wrote:
>> Add entry for ACPI tables created for PVHv2 guests to e820 map.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>
>> New patch
>>
>> tools/libxc/include/xc_dom.h | 4 ++++
>> tools/libxl/libxl_dom.c | 8 ++++----
>> tools/libxl/libxl_x86.c | 11 +++++++++++
>> 3 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
>> index 6cb10c4..ec2da14 100644
>> --- a/tools/libxc/include/xc_dom.h
>> +++ b/tools/libxc/include/xc_dom.h
>> @@ -102,6 +102,10 @@ struct xc_dom_image {
>> xen_vaddr_t virt_alloc_end;
>> xen_vaddr_t bsd_symtab_start;
>>
>> + /* ACPI tables (PVHv2 only) */
>> + xen_pfn_t acpi_pfn;
>> + xen_pfn_t acpi_pages;
>> +
>
> It would be good if we can share the fields with ARM (see [1]).
This is slightly different: acpi_pfn is address in guest physical space
(and is used for building guest's e820 map) and acpitable_blob is a
pointer to virtual address in the toolstack (or is it not?).
acpi_pages and acpitable_size could be used interchangeably though so
that could be shared.
-boris
>
> Regards,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00301.html
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (17 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-07 16:47 ` Wei Liu
2016-07-05 19:05 ` [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
2016-07-06 16:04 ` [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Roger Pau Monné
20 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
New patch
tools/libxl/Makefile | 2 ++
tools/libxl/libxl_dom.c | 22 ++++++++++++++++++----
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9fee752..3a2d64a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -165,6 +165,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
$(XL_OBJS): CFLAGS += $(CFLAGS_XL)
$(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools # include libacpi/x86.h
+
SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ccc41b4..ba3472e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -24,6 +24,9 @@
#include <xen/hvm/hvm_info_table.h>
#include <xen/hvm/hvm_xs_strings.h>
#include <xen/hvm/e820.h>
+#if defined(__i386__) || defined(__x86_64__)
+#include <libacpi/x86.h>
+#endif
#include "_paths.h"
@@ -1006,10 +1009,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
dom->target_pages = mem_size >> XC_PAGE_SHIFT;
if (dom->mmio_size == 0 && device_model)
dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
- else if (dom->mmio_size == 0 && !device_model)
- dom->mmio_size = GB(4) -
- ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
- << XC_PAGE_SHIFT);
+ else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+ if (libxl_defbool_val(info->u.hvm.apic)) {
+ /* Make sure LAPIC_BASE_ADDRESS is below special pages */
+ assert(((((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= XC_PAGE_SIZE);
+ dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+ } else
+ dom->mmio_size = GB(4) -
+ ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+ assert(1);
+#endif
+ }
lowmem_end = mem_size;
highmem_end = 0;
mmio_start = (1ull << 32) - dom->mmio_size;
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
2016-07-05 19:05 ` [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests Boris Ostrovsky
@ 2016-07-07 16:47 ` Wei Liu
2016-07-07 17:02 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-07 16:47 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Tue, Jul 05, 2016 at 03:05:18PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> New patch
>
> tools/libxl/Makefile | 2 ++
> tools/libxl/libxl_dom.c | 22 ++++++++++++++++++----
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 9fee752..3a2d64a 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -165,6 +165,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
> $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
> $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
>
> +libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools # include libacpi/x86.h
> +
> SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
> $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index ccc41b4..ba3472e 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -24,6 +24,9 @@
> #include <xen/hvm/hvm_info_table.h>
> #include <xen/hvm/hvm_xs_strings.h>
> #include <xen/hvm/e820.h>
> +#if defined(__i386__) || defined(__x86_64__)
> +#include <libacpi/x86.h>
> +#endif
>
> #include "_paths.h"
>
> @@ -1006,10 +1009,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> dom->target_pages = mem_size >> XC_PAGE_SHIFT;
> if (dom->mmio_size == 0 && device_model)
> dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
> - else if (dom->mmio_size == 0 && !device_model)
> - dom->mmio_size = GB(4) -
> - ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> - << XC_PAGE_SHIFT);
> + else if (dom->mmio_size == 0 && !device_model) {
> +#if defined(__i386__) || defined(__x86_64__)
> + if (libxl_defbool_val(info->u.hvm.apic)) {
> + /* Make sure LAPIC_BASE_ADDRESS is below special pages */
> + assert(((((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> + << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= XC_PAGE_SIZE);
> + dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
> + } else
> + dom->mmio_size = GB(4) -
> + ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> + << XC_PAGE_SHIFT);
> +#else
> + assert(1);
This looks a bit odd. Do you want to avoid "if {}" (nothing in braces)?
If this branch doesn't nothing on ARM, maybe you can just do
#if defined(x86)
else if () {
}
#endif
?
> +#endif
> + }
> lowmem_end = mem_size;
> highmem_end = 0;
> mmio_start = (1ull << 32) - dom->mmio_size;
> --
> 1.7.1
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
2016-07-07 16:47 ` Wei Liu
@ 2016-07-07 17:02 ` Boris Ostrovsky
2016-07-07 17:16 ` Wei Liu
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-07 17:02 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
On 07/07/2016 12:47 PM, Wei Liu wrote:
> On Tue, Jul 05, 2016 at 03:05:18PM -0400, Boris Ostrovsky wrote:
>>
>> @@ -1006,10 +1009,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
>> dom->target_pages = mem_size >> XC_PAGE_SHIFT;
>> if (dom->mmio_size == 0 && device_model)
>> dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
>> - else if (dom->mmio_size == 0 && !device_model)
>> - dom->mmio_size = GB(4) -
>> - ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
>> - << XC_PAGE_SHIFT);
>> + else if (dom->mmio_size == 0 && !device_model) {
>> +#if defined(__i386__) || defined(__x86_64__)
>> + if (libxl_defbool_val(info->u.hvm.apic)) {
>> + /* Make sure LAPIC_BASE_ADDRESS is below special pages */
>> + assert(((((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
>> + << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= XC_PAGE_SIZE);
>> + dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
>> + } else
>> + dom->mmio_size = GB(4) -
>> + ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
>> + << XC_PAGE_SHIFT);
>> +#else
>> + assert(1);
> This looks a bit odd. Do you want to avoid "if {}" (nothing in braces)?
>
> If this branch doesn't nothing on ARM, maybe you can just do
>
> #if defined(x86)
> else if () {
> }
> #endif
>
> ?
Sure, I could do that. I was trying to flag a case on ARM when we show
up here without device model. Which (the flagging) we haven't done
before so perhaps it's not needed.
-boris
>
>> +#endif
>> + }
>> lowmem_end = mem_size;
>> highmem_end = 0;
>> mmio_start = (1ull << 32) - dom->mmio_size;
>> --
>> 1.7.1
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
2016-07-07 17:02 ` Boris Ostrovsky
@ 2016-07-07 17:16 ` Wei Liu
0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-07-07 17:16 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Thu, Jul 07, 2016 at 01:02:12PM -0400, Boris Ostrovsky wrote:
> On 07/07/2016 12:47 PM, Wei Liu wrote:
> > On Tue, Jul 05, 2016 at 03:05:18PM -0400, Boris Ostrovsky wrote:
> >>
> >> @@ -1006,10 +1009,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> >> dom->target_pages = mem_size >> XC_PAGE_SHIFT;
> >> if (dom->mmio_size == 0 && device_model)
> >> dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
> >> - else if (dom->mmio_size == 0 && !device_model)
> >> - dom->mmio_size = GB(4) -
> >> - ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> >> - << XC_PAGE_SHIFT);
> >> + else if (dom->mmio_size == 0 && !device_model) {
> >> +#if defined(__i386__) || defined(__x86_64__)
> >> + if (libxl_defbool_val(info->u.hvm.apic)) {
> >> + /* Make sure LAPIC_BASE_ADDRESS is below special pages */
> >> + assert(((((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> >> + << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= XC_PAGE_SIZE);
> >> + dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
> >> + } else
> >> + dom->mmio_size = GB(4) -
> >> + ((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
> >> + << XC_PAGE_SHIFT);
> >> +#else
> >> + assert(1);
> > This looks a bit odd. Do you want to avoid "if {}" (nothing in braces)?
> >
> > If this branch doesn't nothing on ARM, maybe you can just do
> >
> > #if defined(x86)
> > else if () {
> > }
> > #endif
> >
> > ?
>
> Sure, I could do that. I was trying to flag a case on ARM when we show
> up here without device model. Which (the flagging) we haven't done
> before so perhaps it's not needed.
>
Ah, I'm fine with the original code then -- if ARM change is
anticipated.
Wei.
> -boris
>
> >
> >> +#endif
> >> + }
> >> lowmem_end = mem_size;
> >> highmem_end = 0;
> >> mmio_start = (1ull << 32) - dom->mmio_size;
> >> --
> >> 1.7.1
> >>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (18 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests Boris Ostrovsky
@ 2016-07-05 19:05 ` Boris Ostrovsky
2016-07-06 11:05 ` Julien Grall
2016-07-08 10:55 ` Wei Liu
2016-07-06 16:04 ` [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Roger Pau Monné
20 siblings, 2 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-05 19:05 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, julien.grall, jbeulich,
zhaoshenglong, boris.ostrovsky, roger.pau
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v1:
* Move to libxl
* Added populate_acpi_pages()
* Stash location/size of tables in xc_dom_image (to be used in constructing e820 map)
* Use libxl allocator
* Only set XEN_X86_EMU_LAPIC flag if 'apic' option is set.
* Make acpi_build_tables() return error code
.gitignore | 4 +
tools/libacpi/build.c | 7 +-
tools/libacpi/libacpi.h | 15 ++-
tools/libxl/Makefile | 17 +++-
tools/libxl/libxl_arch.h | 3 +
tools/libxl/libxl_dom.c | 1 +
tools/libxl/libxl_x86.c | 29 +++--
tools/libxl/libxl_x86_acpi.c | 292 ++++++++++++++++++++++++++++++++++++++++++
tools/libxl/libxl_x86_acpi.h | 21 +++
9 files changed, 373 insertions(+), 16 deletions(-)
create mode 100644 tools/libxl/libxl_x86_acpi.c
create mode 100644 tools/libxl/libxl_x86_acpi.h
diff --git a/.gitignore b/.gitignore
index 9dd2086..d4da37f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -179,6 +179,10 @@ tools/libxl/testenum.c
tools/libxl/tmp.*
tools/libxl/_libxl.api-for-check
tools/libxl/*.api-ok
+tools/libxl/mk_dsdt
+tools/libxl/dsdt*.c
+tools/libxl/dsdt_*.asl
+tools/libxl/ssdt_*.h
tools/misc/cpuperf/cpuperf-perfcntr
tools/misc/cpuperf/cpuperf-xen
tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 290f005..a6ddf53 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -23,6 +23,7 @@
#include "ssdt_tpm.h"
#include "ssdt_pm.h"
#include "x86.h"
+#include <xen/hvm/hvm_info_table.h>
#include <xen/hvm/hvm_xs_strings.h>
#include <xen/hvm/params.h>
@@ -473,7 +474,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
return 1;
}
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
{
struct acpi_20_rsdp *rsdp;
struct acpi_20_rsdt *rsdt;
@@ -594,11 +595,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
*(struct acpi_info *)config->ainfop = config->ainfo;
- return;
+ return 0;
oom:
printf("unable to build ACPI tables: out of memory\n");
-
+ return -1;
}
/*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 87a2937..791ebac 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -69,6 +69,15 @@ struct acpi_ctxt {
void *(*alloc)(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align);
unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
} mem_ops;
+
+ unsigned int page_size;
+ unsigned int page_shift;
+
+ /* Memory allocator */
+ unsigned long alloc_base_paddr;
+ unsigned long alloc_base_vaddr;
+ unsigned long alloc_currp;
+ unsigned long alloc_end;
};
struct acpi_config {
@@ -98,13 +107,13 @@ struct acpi_config {
* This must match the OperationRegion(BIOS, SystemMemory, ....)
* definition in the DSDT
*/
- unsigned int ainfop;
+ unsigned long ainfop;
/* RSDP address */
- unsigned int rsdp;
+ unsigned long rsdp;
};
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
#endif /* __LIBACPI_H__ */
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3a2d64a..18be2e7 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,20 @@ else
LIBXL_OBJS-y += libxl_no_colo.o
endif
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c build.c static_tables.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+ $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o libxl_x86_acpi.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
ifeq ($(CONFIG_NetBSD),y)
@@ -166,6 +179,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
$(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs it.
libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
$(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
@@ -308,6 +322,7 @@ clean:
$(RM) -f testidl.c.new testidl.c *.api-ok
$(RM) -f xenlight.pc
$(RM) -f xlutil.pc
+ $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd) clean
distclean: clean
$(RM) -f xenlight.pc.in xlutil.pc.in
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 34a853c..7c6536b 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -62,4 +62,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
uint32_t domid,
struct xc_dom_image *dom);
+int libxl__dom_load_acpi(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom);
#endif
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ba3472e..7e4e289 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -657,6 +657,7 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
LOGE(ERROR, "xc_dom_build_image failed");
goto out;
}
+
if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
LOGE(ERROR, "xc_dom_boot_image failed");
goto out;
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 32ce1d2..7201dbb 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -8,15 +8,18 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
xc_domain_configuration_t *xc_config)
{
- if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
- d_config->b_info.device_model_version !=
- LIBXL_DEVICE_MODEL_VERSION_NONE) {
- /* HVM domains with a device model. */
- xc_config->emulation_flags = XEN_X86_EMU_ALL;
- } else {
- /* PV or HVM domains without a device model. */
+ if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
+ if (d_config->b_info.device_model_version !=
+ LIBXL_DEVICE_MODEL_VERSION_NONE)
+ xc_config->emulation_flags = XEN_X86_EMU_ALL;
+ else if (libxl_defbool_val(d_config->b_info.u.hvm.apic))
+ /*
+ * HVM guests without device model may want
+ * to have LAPIC emulation.
+ */
+ xc_config->emulation_flags = XEN_X86_EMU_LAPIC;
+ } else
xc_config->emulation_flags = 0;
- }
return 0;
}
@@ -366,7 +369,15 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
libxl_domain_build_info *info,
struct xc_dom_image *dom)
{
- return 0;
+ int ret = 0;
+
+ if ((info->type == LIBXL_DOMAIN_TYPE_HVM) &&
+ (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE)) {
+ if ( (ret = libxl__dom_load_acpi(gc, info, dom)) != 0 )
+ LOGE(ERROR, "libxl_dom_load_acpi failed");
+ }
+
+ return ret;
}
/* Return 0 on success, ERROR_* on failure. */
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
new file mode 100644
index 0000000..144f063
--- /dev/null
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -0,0 +1,292 @@
+/******************************************************************************
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include "libxl_internal.h"
+#include "libxl_arch.h"
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/e820.h>
+#include "libacpi/libacpi.h"
+
+#include <xc_dom.h>
+
+#define NUM_ACPI_PAGES 16 /* Number of pages holding ACPI tables */
+#define RSDP_ADDRESS (0xffffful - 64) /* Last doubleword of BIOS RO memory */
+#define ACPI_INFO_PHYSICAL_ADDRESS 0xfc000000
+
+extern const unsigned char dsdt_pvh[];
+extern const unsigned int dsdt_pvh_len;
+
+/* Assumes contiguous physical space */
+static unsigned long virt_to_phys(struct acpi_ctxt *ctxt, void *v)
+{
+ return (((unsigned long)v - ctxt->alloc_base_vaddr) +
+ ctxt->alloc_base_paddr);
+}
+
+static void *mem_alloc(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align)
+{
+ unsigned long s, e;
+
+ /* Align to at least 16 bytes. */
+ if (align < 16)
+ align = 16;
+
+ s = (ctxt->alloc_currp + align) & ~((unsigned long)align - 1);
+ e = s + size - 1;
+
+ /* TODO: Reallocate memory */
+ if ((e < s) || (e >= ctxt->alloc_end)) return NULL;
+
+ while (ctxt->alloc_currp >> ctxt->page_shift !=
+ e >> ctxt->page_shift)
+ ctxt->alloc_currp += ctxt->page_size;
+
+ ctxt->alloc_currp = e;
+
+ return (void *)s;
+}
+
+static int init_acpi_config(libxl__gc *gc,
+ struct xc_dom_image *dom,
+ libxl_domain_build_info *b_info,
+ struct acpi_config *config)
+{
+ xc_interface *xch = dom->xch;
+ uint32_t domid = dom->guest_domid;
+ xc_dominfo_t info;
+ int i, rc;
+
+ config->dsdt_anycpu = config->dsdt_15cpu = dsdt_pvh;
+ config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_pvh_len;
+
+ rc = xc_domain_getinfo(xch, domid, 1, &info);
+ if (rc < 0) {
+ LOG(ERROR, "%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
+ return rc;
+ }
+
+ config->hvminfo = libxl__zalloc(gc, sizeof(*config->hvminfo));
+
+ config->hvminfo->apic_mode = libxl_defbool_val(b_info->u.hvm.apic);
+
+ if (dom->nr_vnodes) {
+ struct acpi_numa *numa = &config->numa;
+
+ rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
+ &numa->nr_vmemranges,
+ &config->hvminfo->nr_vcpus, NULL, NULL, NULL);
+ if (rc) {
+ LOG(ERROR, "%s: xc_domain_getvnuma failed (rc=%d)",
+ __FUNCTION__, rc);
+ return rc;
+ }
+
+ numa->vmemrange = libxl__zalloc(gc, dom->nr_vmemranges *
+ sizeof(*numa->vmemrange));
+ numa->vdistance = libxl__zalloc(gc, dom->nr_vnodes *
+ sizeof(*numa->vdistance));
+ numa->vcpu_to_vnode = libxl__zalloc(gc, config->hvminfo->nr_vcpus *
+ sizeof(*numa->vcpu_to_vnode));
+ rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
+ &numa->nr_vmemranges,
+ &config->hvminfo->nr_vcpus, numa->vmemrange,
+ numa->vdistance, numa->vcpu_to_vnode);
+ if (rc) {
+ LOG(ERROR, "%s: xc_domain_getvnuma failed (rc=%d)",
+ __FUNCTION__, rc);
+ return rc;
+ }
+ }
+ else
+ config->hvminfo->nr_vcpus = info.max_vcpu_id + 1;
+
+ for (i=0; i<config->hvminfo->nr_vcpus; i++)
+ config->hvminfo->vcpu_online[i / 8] |= 1 << (i & 7);
+
+ return 0;
+}
+
+static int populate_acpi_pages(struct xc_dom_image *dom,
+ xen_pfn_t *extents,
+ unsigned int num_pages,
+ struct acpi_ctxt *ctxt)
+{
+ int rc;
+ xc_interface *xch = dom->xch;
+ uint32_t domid = dom->guest_domid;
+ unsigned long idx, first_high_idx = (1ull << (32 - ctxt->page_shift));
+
+ for (; num_pages; num_pages--, extents++) {
+
+ if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1)
+ continue;
+
+ if (dom->highmem_end) {
+ idx = --dom->highmem_end;
+ if ( idx == first_high_idx )
+ dom->highmem_end = 0;
+ } else
+ idx = --dom->lowmem_end;
+
+ rc = xc_domain_add_to_physmap(xch, domid,
+ XENMAPSPACE_gmfn,
+ idx, *extents);
+ if (rc)
+ return rc;
+ }
+
+ return 0;
+}
+
+int libxl__dom_load_acpi(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom)
+{
+ struct acpi_config config = {0};
+ struct acpi_ctxt ctxt;
+ uint32_t domid = dom->guest_domid;
+ xc_interface *xch = dom->xch;
+ int rc, i, acpi_pages_num;
+ xen_pfn_t extent, *extents;
+ void *acpi_pages, *guest_acpi_pages = NULL;
+ unsigned long page_mask;
+
+ if ((info->type != LIBXL_DOMAIN_TYPE_HVM) ||
+ (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE))
+ return 0;
+
+ ctxt.page_size = XC_DOM_PAGE_SIZE(dom);
+ ctxt.page_shift = XC_DOM_PAGE_SHIFT(dom);
+ page_mask = (1UL << ctxt.page_shift) - 1;
+
+ ctxt.mem_ops.alloc = mem_alloc;
+ ctxt.mem_ops.v2p = virt_to_phys;
+
+ rc = init_acpi_config(gc, dom, info, &config);
+ if (rc) {
+ LOG(ERROR, "%s: init_acpi_config failed (rc=%d)", __FUNCTION__, rc);
+ return rc;
+ }
+
+ /* Map page that will hold RSDP */
+ extent = RSDP_ADDRESS >> ctxt.page_shift;
+ rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
+ if (rc) {
+ LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
+ __FUNCTION__, rc);
+ goto out;
+ }
+ config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
+ ctxt.page_size,
+ PROT_READ | PROT_WRITE,
+ RSDP_ADDRESS >> ctxt.page_shift);
+ if (!config.rsdp) {
+ LOG(ERROR, "%s: Can't map acpi_physical", __FUNCTION__);
+ rc = -1;
+ goto out;
+ }
+
+ /* Map acpi_info page */
+ extent = ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift;
+ rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
+ if (rc) {
+ LOG(ERROR, "%s: populate_acpi_pages for acpi_info failed with %d",
+ __FUNCTION__, rc);
+ goto out;
+ }
+
+ config.ainfop = (unsigned long)xc_map_foreign_range(xch, domid,
+ ctxt.page_size,
+ PROT_READ | PROT_WRITE,
+ ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift);
+ if (!config.ainfop) {
+ LOG(ERROR, "%s: Can't map acpi_info_page", __FUNCTION__);
+ rc = -1;
+ goto out;
+ }
+
+ /* Pages to hold ACPI tables */
+ acpi_pages = libxl__malloc(gc, (NUM_ACPI_PAGES + 1) * ctxt.page_size);
+ while ((unsigned long)acpi_pages & page_mask)
+ acpi_pages++;
+
+ /*
+ * Set up allocator memory.
+ * Start next to acpi_info page to avoid fracturing e820.
+ */
+ ctxt.alloc_base_paddr = ACPI_INFO_PHYSICAL_ADDRESS + ctxt.page_size;
+ ctxt.alloc_base_vaddr = ctxt.alloc_currp = (unsigned long)acpi_pages;
+ ctxt.alloc_end = (unsigned long)acpi_pages +
+ (NUM_ACPI_PAGES * ctxt.page_size);
+
+ /* Build the tables */
+ rc = acpi_build_tables(&ctxt, &config);
+ if (rc) {
+ LOG(ERROR, "%s: acpi_build_tables failed with %d",
+ __FUNCTION__, rc);
+ goto out;
+ }
+
+ /* Copy ACPI tables into guest's memory */
+ acpi_pages_num =
+ ((ctxt.alloc_currp - (unsigned long)acpi_pages) >> ctxt.page_shift) +
+ ((ctxt.alloc_currp & page_mask) ? 1 : 0);
+ extents = libxl__malloc(gc, acpi_pages_num * sizeof(*extents));
+ for (i = 0; i < acpi_pages_num; i++)
+ extents[i] = (ctxt.alloc_base_paddr >> ctxt.page_shift) + i;
+ rc = populate_acpi_pages(dom, extents, acpi_pages_num, &ctxt);
+ if (rc) {
+ LOG(ERROR, "%s: populate_acpi_pages for APCI tables failed with %d",
+ __FUNCTION__, rc);
+ goto out;
+ }
+ guest_acpi_pages = xc_map_foreign_range(xch, domid,
+ ctxt.page_size * acpi_pages_num,
+ PROT_READ | PROT_WRITE,
+ ctxt.alloc_base_paddr >> ctxt.page_shift);
+ if (!guest_acpi_pages) {
+ LOG(ERROR, "%s Can't map guest_acpi_pages", __FUNCTION__);
+ rc = -1;
+ goto out;
+ }
+
+ memcpy(guest_acpi_pages, acpi_pages, acpi_pages_num * ctxt.page_size);
+
+ dom->acpi_pfn = ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift;
+ dom->acpi_pages = acpi_pages_num + 1;
+
+out:
+ munmap(guest_acpi_pages, acpi_pages_num * ctxt.page_size);
+ munmap((void *)config.ainfop, ctxt.page_size);
+ munmap((void *)config.rsdp, ctxt.page_size);
+
+ return rc;
+
+}
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_x86_acpi.h b/tools/libxl/libxl_x86_acpi.h
new file mode 100644
index 0000000..1899ec1
--- /dev/null
+++ b/tools/libxl/libxl_x86_acpi.h
@@ -0,0 +1,21 @@
+#ifndef LIBXL_X86_ACPI_H
+#define LIBXL_X86_ACPI_H
+
+#include "libxl_internal.h"
+
+#define ASSERT(x) assert(x)
+
+static inline int test_bit(unsigned int b, void *p)
+{
+ return !!(((uint8_t *)p)[b>>3] & (1u<<(b&7)));
+}
+
+#endif /* LIBXL_X_86_ACPI_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-05 19:05 ` [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
@ 2016-07-06 11:05 ` Julien Grall
2016-07-06 15:50 ` Boris Ostrovsky
2016-07-08 10:55 ` Wei Liu
1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-06 11:05 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, zhaoshenglong,
roger.pau
(CC Stefano)
Hi Boris,
On 05/07/16 20:05, Boris Ostrovsky wrote:
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> index 34a853c..7c6536b 100644
> --- a/tools/libxl/libxl_arch.h
> +++ b/tools/libxl/libxl_arch.h
> @@ -62,4 +62,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
> uint32_t domid,
> struct xc_dom_image *dom);
>
> +int libxl__dom_load_acpi(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + struct xc_dom_image *dom);
This file contains arch specific function with are called by the generic
libxl code.
I don't think this is the right file for an x86 specific function which
has a generic name. IHMO, this should go in libxl_x86_acpi.h with "x86"
in the name and with '_hidden' attribute.
> #endif
[...]
> +static int populate_acpi_pages(struct xc_dom_image *dom,
> + xen_pfn_t *extents,
> + unsigned int num_pages,
> + struct acpi_ctxt *ctxt)
> +{
> + int rc;
> + xc_interface *xch = dom->xch;
> + uint32_t domid = dom->guest_domid;
> + unsigned long idx, first_high_idx = (1ull << (32 - ctxt->page_shift));
> +
> + for (; num_pages; num_pages--, extents++) {
> +
> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1)
It looks like this is working because libxl is setting the maximum size
of the domain with some slack (1MB). You might get in trouble if the
slack is reduced or used by someone or the ACPI blob is increasing.
> + continue;
> +
> + if (dom->highmem_end) {
> + idx = --dom->highmem_end;
> + if ( idx == first_high_idx )
> + dom->highmem_end = 0;
> + } else
> + idx = --dom->lowmem_end;
> +
> + rc = xc_domain_add_to_physmap(xch, domid,
> + XENMAPSPACE_gmfn,
> + idx, *extents);
> + if (rc)
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> +int libxl__dom_load_acpi(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + struct xc_dom_image *dom)
> +{
> + struct acpi_config config = {0};
> + struct acpi_ctxt ctxt;
> + uint32_t domid = dom->guest_domid;
> + xc_interface *xch = dom->xch;
> + int rc, i, acpi_pages_num;
> + xen_pfn_t extent, *extents;
> + void *acpi_pages, *guest_acpi_pages = NULL;
> + unsigned long page_mask;
> +
> + if ((info->type != LIBXL_DOMAIN_TYPE_HVM) ||
> + (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE))
> + return 0;
> +
> + ctxt.page_size = XC_DOM_PAGE_SIZE(dom);
> + ctxt.page_shift = XC_DOM_PAGE_SHIFT(dom);
> + page_mask = (1UL << ctxt.page_shift) - 1;
> +
> + ctxt.mem_ops.alloc = mem_alloc;
> + ctxt.mem_ops.v2p = virt_to_phys;
> +
> + rc = init_acpi_config(gc, dom, info, &config);
> + if (rc) {
> + LOG(ERROR, "%s: init_acpi_config failed (rc=%d)", __FUNCTION__, rc);
> + return rc;
> + }
> +
> + /* Map page that will hold RSDP */
> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> + if (rc) {
> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> + __FUNCTION__, rc);
> + goto out;
> + }
> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> + ctxt.page_size,
> + PROT_READ | PROT_WRITE,
> + RSDP_ADDRESS >> ctxt.page_shift);
> + if (!config.rsdp) {
> + LOG(ERROR, "%s: Can't map acpi_physical", __FUNCTION__);
> + rc = -1;
> + goto out;
> + }
> +
> + /* Map acpi_info page */
> + extent = ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift;
> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> + if (rc) {
> + LOG(ERROR, "%s: populate_acpi_pages for acpi_info failed with %d",
> + __FUNCTION__, rc);
> + goto out;
> + }
> +
> + config.ainfop = (unsigned long)xc_map_foreign_range(xch, domid,
> + ctxt.page_size,
> + PROT_READ | PROT_WRITE,
> + ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift);
Loading the ACPI blob on ARM will be very similar except for the base
address. So it would be nice to share some code with it.
However, as mentioned in the ACPI thread [1], all the blobs are
generally loaded by libxc and not libxl. This is more true on ARM
because the guest address space is controlled by libxc (the position of
all the blob are decided by it).
Regards,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00040.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 11:05 ` Julien Grall
@ 2016-07-06 15:50 ` Boris Ostrovsky
2016-07-06 16:04 ` Julien Grall
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-06 15:50 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
On 07/06/2016 07:05 AM, Julien Grall wrote:
> (CC Stefano)
>
> Hi Boris,
>
> On 05/07/16 20:05, Boris Ostrovsky wrote:
>> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
>> index 34a853c..7c6536b 100644
>> --- a/tools/libxl/libxl_arch.h
>> +++ b/tools/libxl/libxl_arch.h
>> @@ -62,4 +62,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
>> uint32_t domid,
>> struct xc_dom_image *dom);
>>
>> +int libxl__dom_load_acpi(libxl__gc *gc,
>> + libxl_domain_build_info *info,
>> + struct xc_dom_image *dom);
>
> This file contains arch specific function with are called by the
> generic libxl code.
>
> I don't think this is the right file for an x86 specific function
> which has a generic name. IHMO, this should go in libxl_x86_acpi.h
> with "x86" in the name and with '_hidden' attribute.
Right. I used to call this routine from libxl_dom.c. I moved the call
site to libxl_x86.c (as you suggested earlier) but forgot to move the
declaration.
>
>> #endif
>
> [...]
>
>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>> + xen_pfn_t *extents,
>> + unsigned int num_pages,
>> + struct acpi_ctxt *ctxt)
>> +{
>> + int rc;
>> + xc_interface *xch = dom->xch;
>> + uint32_t domid = dom->guest_domid;
>> + unsigned long idx, first_high_idx = (1ull << (32 -
>> ctxt->page_shift));
>> +
>> + for (; num_pages; num_pages--, extents++) {
>> +
>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents)
>> == 1)
>
> It looks like this is working because libxl is setting the maximum
> size of the domain with some slack (1MB). You might get in trouble if
> the slack is reduced or used by someone or the ACPI blob is increasing.
I saw your conversation about slack with Stefano and I am not sure I
understood what it was about. If this was about padding guest's memory
to be able to put there some additional data (such ACPI tables) then
this is not my intention here: if I can't populate (because it is
already populated, I guess) then I try to move memory around with code
below. That's what mem_hole_populate_ram() does as well.
>
>> + continue;
>> +
>> + if (dom->highmem_end) {
>> + idx = --dom->highmem_end;
>> + if ( idx == first_high_idx )
>> + dom->highmem_end = 0;
>> + } else
>> + idx = --dom->lowmem_end;
>> +
>> + rc = xc_domain_add_to_physmap(xch, domid,
>> + XENMAPSPACE_gmfn,
>> + idx, *extents);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +int libxl__dom_load_acpi(libxl__gc *gc,
>> + libxl_domain_build_info *info,
>> + struct xc_dom_image *dom)
>> +{
>> + struct acpi_config config = {0};
>> + struct acpi_ctxt ctxt;
>> + uint32_t domid = dom->guest_domid;
>> + xc_interface *xch = dom->xch;
>> + int rc, i, acpi_pages_num;
>> + xen_pfn_t extent, *extents;
>> + void *acpi_pages, *guest_acpi_pages = NULL;
>> + unsigned long page_mask;
>> +
>> + if ((info->type != LIBXL_DOMAIN_TYPE_HVM) ||
>> + (info->device_model_version !=
>> LIBXL_DEVICE_MODEL_VERSION_NONE))
>> + return 0;
>> +
>> + ctxt.page_size = XC_DOM_PAGE_SIZE(dom);
>> + ctxt.page_shift = XC_DOM_PAGE_SHIFT(dom);
>> + page_mask = (1UL << ctxt.page_shift) - 1;
>> +
>> + ctxt.mem_ops.alloc = mem_alloc;
>> + ctxt.mem_ops.v2p = virt_to_phys;
>> +
>> + rc = init_acpi_config(gc, dom, info, &config);
>> + if (rc) {
>> + LOG(ERROR, "%s: init_acpi_config failed (rc=%d)",
>> __FUNCTION__, rc);
>> + return rc;
>> + }
>> +
>> + /* Map page that will hold RSDP */
>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>> + if (rc) {
>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>> + __FUNCTION__, rc);
>> + goto out;
>> + }
>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>> + ctxt.page_size,
>> + PROT_READ |
>> PROT_WRITE,
>> + RSDP_ADDRESS
>> >> ctxt.page_shift);
>> + if (!config.rsdp) {
>> + LOG(ERROR, "%s: Can't map acpi_physical", __FUNCTION__);
>> + rc = -1;
>> + goto out;
>> + }
>> +
>> + /* Map acpi_info page */
>> + extent = ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift;
>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>> + if (rc) {
>> + LOG(ERROR, "%s: populate_acpi_pages for acpi_info failed
>> with %d",
>> + __FUNCTION__, rc);
>> + goto out;
>> + }
>> +
>> + config.ainfop = (unsigned long)xc_map_foreign_range(xch, domid,
>> + ctxt.page_size,
>> + PROT_READ |
>> PROT_WRITE,
>> +
>> ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift);
>
> Loading the ACPI blob on ARM will be very similar except for the base
> address. So it would be nice to share some code with it.
>
> However, as mentioned in the ACPI thread [1], all the blobs are
> generally loaded by libxc and not libxl. This is more true on ARM
> because the guest address space is controlled by libxc (the position
> of all the blob are decided by it).
The difference is that I not only load the tables here but also build
them. Which may or may not be the right thing to do in libxc.
I suppose I can defer loading (and then keep pointer to tables in
acpitable_blob) but the then I need to keep RSDP descriptor somewhere
else (it is not part of the blob since it lives in lower MB of the guest).
-boris
>
> Regards,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00040.html
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 15:50 ` Boris Ostrovsky
@ 2016-07-06 16:04 ` Julien Grall
2016-07-06 16:30 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-06 16:04 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
Hi Boris,
On 06/07/16 16:50, Boris Ostrovsky wrote:
> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>> + xen_pfn_t *extents,
>>> + unsigned int num_pages,
>>> + struct acpi_ctxt *ctxt)
>>> +{
>>> + int rc;
>>> + xc_interface *xch = dom->xch;
>>> + uint32_t domid = dom->guest_domid;
>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>> ctxt->page_shift));
>>> +
>>> + for (; num_pages; num_pages--, extents++) {
>>> +
>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents)
>>> == 1)
>>
>> It looks like this is working because libxl is setting the maximum
>> size of the domain with some slack (1MB). You might get in trouble if
>> the slack is reduced or used by someone or the ACPI blob is increasing.
>
>
> I saw your conversation about slack with Stefano and I am not sure I
> understood what it was about. If this was about padding guest's memory
> to be able to put there some additional data (such ACPI tables) then
> this is not my intention here: if I can't populate (because it is
> already populated, I guess) then I try to move memory around with code
> below. That's what mem_hole_populate_ram() does as well.
The maximum amount of memory that could be assigned to a domain is fixed
per-domain. This maximum amount does not take into account the size of
the ACPI blob. So you may end up to fail because all the memory was
assigned somewhere else.
>
>>
>>> + continue;
>>> +
>>> + if (dom->highmem_end) {
>>> + idx = --dom->highmem_end;
>>> + if ( idx == first_high_idx )
>>> + dom->highmem_end = 0;
>>> + } else
>>> + idx = --dom->lowmem_end;
>>> +
>>> + rc = xc_domain_add_to_physmap(xch, domid,
>>> + XENMAPSPACE_gmfn,
>>> + idx, *extents);
>>> + if (rc)
>>> + return rc;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int libxl__dom_load_acpi(libxl__gc *gc,
>>> + libxl_domain_build_info *info,
>>> + struct xc_dom_image *dom)
>>> +{
>>> + struct acpi_config config = {0};
>>> + struct acpi_ctxt ctxt;
>>> + uint32_t domid = dom->guest_domid;
>>> + xc_interface *xch = dom->xch;
>>> + int rc, i, acpi_pages_num;
>>> + xen_pfn_t extent, *extents;
>>> + void *acpi_pages, *guest_acpi_pages = NULL;
>>> + unsigned long page_mask;
>>> +
>>> + if ((info->type != LIBXL_DOMAIN_TYPE_HVM) ||
>>> + (info->device_model_version !=
>>> LIBXL_DEVICE_MODEL_VERSION_NONE))
>>> + return 0;
>>> +
>>> + ctxt.page_size = XC_DOM_PAGE_SIZE(dom);
>>> + ctxt.page_shift = XC_DOM_PAGE_SHIFT(dom);
>>> + page_mask = (1UL << ctxt.page_shift) - 1;
>>> +
>>> + ctxt.mem_ops.alloc = mem_alloc;
>>> + ctxt.mem_ops.v2p = virt_to_phys;
>>> +
>>> + rc = init_acpi_config(gc, dom, info, &config);
>>> + if (rc) {
>>> + LOG(ERROR, "%s: init_acpi_config failed (rc=%d)",
>>> __FUNCTION__, rc);
>>> + return rc;
>>> + }
>>> +
>>> + /* Map page that will hold RSDP */
>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>> + if (rc) {
>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>> + __FUNCTION__, rc);
>>> + goto out;
>>> + }
>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>> + ctxt.page_size,
>>> + PROT_READ |
>>> PROT_WRITE,
>>> + RSDP_ADDRESS
>>>>> ctxt.page_shift);
>>> + if (!config.rsdp) {
>>> + LOG(ERROR, "%s: Can't map acpi_physical", __FUNCTION__);
>>> + rc = -1;
>>> + goto out;
>>> + }
>>> +
>>> + /* Map acpi_info page */
>>> + extent = ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift;
>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>> + if (rc) {
>>> + LOG(ERROR, "%s: populate_acpi_pages for acpi_info failed
>>> with %d",
>>> + __FUNCTION__, rc);
>>> + goto out;
>>> + }
>>> +
>>> + config.ainfop = (unsigned long)xc_map_foreign_range(xch, domid,
>>> + ctxt.page_size,
>>> + PROT_READ |
>>> PROT_WRITE,
>>> +
>>> ACPI_INFO_PHYSICAL_ADDRESS >> ctxt.page_shift);
>>
>> Loading the ACPI blob on ARM will be very similar except for the base
>> address. So it would be nice to share some code with it.
>>
>> However, as mentioned in the ACPI thread [1], all the blobs are
>> generally loaded by libxc and not libxl. This is more true on ARM
>> because the guest address space is controlled by libxc (the position
>> of all the blob are decided by it).
>
> The difference is that I not only load the tables here but also build
> them. Which may or may not be the right thing to do in libxc.
>
> I suppose I can defer loading (and then keep pointer to tables in
> acpitable_blob) but the then I need to keep RSDP descriptor somewhere
> else (it is not part of the blob since it lives in lower MB of the guest).
The device tree for ARM are built in libxl and loaded for libxc. IHMO,
it would be strange to have a different pattern for ACPI.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 16:04 ` Julien Grall
@ 2016-07-06 16:30 ` Boris Ostrovsky
2016-07-06 17:03 ` Julien Grall
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-06 16:30 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
On 07/06/2016 12:04 PM, Julien Grall wrote:
> Hi Boris,
>
> On 06/07/16 16:50, Boris Ostrovsky wrote:
>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>> + xen_pfn_t *extents,
>>>> + unsigned int num_pages,
>>>> + struct acpi_ctxt *ctxt)
>>>> +{
>>>> + int rc;
>>>> + xc_interface *xch = dom->xch;
>>>> + uint32_t domid = dom->guest_domid;
>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>> ctxt->page_shift));
>>>> +
>>>> + for (; num_pages; num_pages--, extents++) {
>>>> +
>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents)
>>>> == 1)
>>>
>>> It looks like this is working because libxl is setting the maximum
>>> size of the domain with some slack (1MB). You might get in trouble if
>>> the slack is reduced or used by someone or the ACPI blob is increasing.
>>
>>
>> I saw your conversation about slack with Stefano and I am not sure I
>> understood what it was about. If this was about padding guest's memory
>> to be able to put there some additional data (such ACPI tables) then
>> this is not my intention here: if I can't populate (because it is
>> already populated, I guess) then I try to move memory around with code
>> below. That's what mem_hole_populate_ram() does as well.
>
> The maximum amount of memory that could be assigned to a domain is
> fixed per-domain. This maximum amount does not take into account the
> size of the ACPI blob. So you may end up to fail because all the
> memory was assigned somewhere else.
Why shouldn't max amount of guest's memory include ACPI tables? I think
we should fail and not rely on this slack if no more memory is available.
...
>
>>
>>> However, as mentioned in the ACPI thread [1], all the blobs are
>>> generally loaded by libxc and not libxl. This is more true on ARM
>>> because the guest address space is controlled by libxc (the position
>>> of all the blob are decided by it).
>>
>> The difference is that I not only load the tables here but also build
>> them. Which may or may not be the right thing to do in libxc.
>>
>> I suppose I can defer loading (and then keep pointer to tables in
>> acpitable_blob) but the then I need to keep RSDP descriptor somewhere
>> else (it is not part of the blob since it lives in lower MB of the
>> guest).
>
> The device tree for ARM are built in libxl and loaded for libxc. IHMO,
> it would be strange to have a different pattern for ACPI.
Is RSDP part of the ACPI blob for ARM? If not, how do you load it?
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 16:30 ` Boris Ostrovsky
@ 2016-07-06 17:03 ` Julien Grall
2016-07-06 17:33 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-06 17:03 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
On 06/07/16 17:30, Boris Ostrovsky wrote:
> On 07/06/2016 12:04 PM, Julien Grall wrote:
>> Hi Boris,
>>
>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>> + xen_pfn_t *extents,
>>>>> + unsigned int num_pages,
>>>>> + struct acpi_ctxt *ctxt)
>>>>> +{
>>>>> + int rc;
>>>>> + xc_interface *xch = dom->xch;
>>>>> + uint32_t domid = dom->guest_domid;
>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>> ctxt->page_shift));
>>>>> +
>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>> +
>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents)
>>>>> == 1)
>>>>
>>>> It looks like this is working because libxl is setting the maximum
>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>> the slack is reduced or used by someone or the ACPI blob is increasing.
>>>
>>>
>>> I saw your conversation about slack with Stefano and I am not sure I
>>> understood what it was about. If this was about padding guest's memory
>>> to be able to put there some additional data (such ACPI tables) then
>>> this is not my intention here: if I can't populate (because it is
>>> already populated, I guess) then I try to move memory around with code
>>> below. That's what mem_hole_populate_ram() does as well.
>>
>> The maximum amount of memory that could be assigned to a domain is
>> fixed per-domain. This maximum amount does not take into account the
>> size of the ACPI blob. So you may end up to fail because all the
>> memory was assigned somewhere else.
>
> Why shouldn't max amount of guest's memory include ACPI tables? I think
> we should fail and not rely on this slack if no more memory is available.
>
> ...
Because, at least for ARM, the ACPI memory region is not part of the
"real" RAM. So this value is not taken into account into the current max
mem. My point is we need to add the size of the ACPI blob to max mem to
avoid any error here.
>
>>
>>>
>>>> However, as mentioned in the ACPI thread [1], all the blobs are
>>>> generally loaded by libxc and not libxl. This is more true on ARM
>>>> because the guest address space is controlled by libxc (the position
>>>> of all the blob are decided by it).
>>>
>>> The difference is that I not only load the tables here but also build
>>> them. Which may or may not be the right thing to do in libxc.
>>>
>>> I suppose I can defer loading (and then keep pointer to tables in
>>> acpitable_blob) but the then I need to keep RSDP descriptor somewhere
>>> else (it is not part of the blob since it lives in lower MB of the
>>> guest).
>>
>> The device tree for ARM are built in libxl and loaded for libxc. IHMO,
>> it would be strange to have a different pattern for ACPI.
>
> Is RSDP part of the ACPI blob for ARM? If not, how do you load it?
RSDP is part of the ACPI blob for ARM.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 17:03 ` Julien Grall
@ 2016-07-06 17:33 ` Boris Ostrovsky
2016-07-07 8:38 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-06 17:33 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
jbeulich, zhaoshenglong, roger.pau
On 07/06/2016 01:03 PM, Julien Grall wrote:
>
>
> On 06/07/16 17:30, Boris Ostrovsky wrote:
>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>> Hi Boris,
>>>
>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>> + xen_pfn_t *extents,
>>>>>> + unsigned int num_pages,
>>>>>> + struct acpi_ctxt *ctxt)
>>>>>> +{
>>>>>> + int rc;
>>>>>> + xc_interface *xch = dom->xch;
>>>>>> + uint32_t domid = dom->guest_domid;
>>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>> ctxt->page_shift));
>>>>>> +
>>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>>> +
>>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>> extents)
>>>>>> == 1)
>>>>>
>>>>> It looks like this is working because libxl is setting the maximum
>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>> increasing.
>>>>
>>>>
>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>> understood what it was about. If this was about padding guest's memory
>>>> to be able to put there some additional data (such ACPI tables) then
>>>> this is not my intention here: if I can't populate (because it is
>>>> already populated, I guess) then I try to move memory around with code
>>>> below. That's what mem_hole_populate_ram() does as well.
>>>
>>> The maximum amount of memory that could be assigned to a domain is
>>> fixed per-domain. This maximum amount does not take into account the
>>> size of the ACPI blob. So you may end up to fail because all the
>>> memory was assigned somewhere else.
>>
>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>> we should fail and not rely on this slack if no more memory is
>> available.
>>
>> ...
>
> Because, at least for ARM, the ACPI memory region is not part of the
> "real" RAM. So this value is not taken into account into the current
> max mem.
Hmm.. I've always assumed it is part of memory but marked as a special
type in e820 map on x86. Maybe Andrew or Jan can comment on this.
> My point is we need to add the size of the ACPI blob to max mem to
> avoid any error here.
So you (or Shannon) plan on doing this for ARM, right (it's not done
with the current version of patches)?
>
>>
>>>
>>>>
>>>>> However, as mentioned in the ACPI thread [1], all the blobs are
>>>>> generally loaded by libxc and not libxl. This is more true on ARM
>>>>> because the guest address space is controlled by libxc (the position
>>>>> of all the blob are decided by it).
>>>>
>>>> The difference is that I not only load the tables here but also build
>>>> them. Which may or may not be the right thing to do in libxc.
>>>>
>>>> I suppose I can defer loading (and then keep pointer to tables in
>>>> acpitable_blob) but the then I need to keep RSDP descriptor somewhere
>>>> else (it is not part of the blob since it lives in lower MB of the
>>>> guest).
>>>
>>> The device tree for ARM are built in libxl and loaded for libxc. IHMO,
>>> it would be strange to have a different pattern for ACPI.
>>
>> Is RSDP part of the ACPI blob for ARM? If not, how do you load it?
>
> RSDP is part of the ACPI blob for ARM.
And it's not for x86. So to separate building and loading the tables
would require two blobs.
I suppose we cal loop over blobs in xc_dom_load_acpi in
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00309.html
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-06 17:33 ` Boris Ostrovsky
@ 2016-07-07 8:38 ` Jan Beulich
2016-07-07 15:08 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-07 8:38 UTC (permalink / raw)
To: Julien Grall, xen-devel, Boris Ostrovsky
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
zhaoshenglong, roger.pau
>>> On 06.07.16 at 19:33, <boris.ostrovsky@oracle.com> wrote:
> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>
>>
>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>>> Hi Boris,
>>>>
>>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>>> + xen_pfn_t *extents,
>>>>>>> + unsigned int num_pages,
>>>>>>> + struct acpi_ctxt *ctxt)
>>>>>>> +{
>>>>>>> + int rc;
>>>>>>> + xc_interface *xch = dom->xch;
>>>>>>> + uint32_t domid = dom->guest_domid;
>>>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>>> ctxt->page_shift));
>>>>>>> +
>>>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>>>> +
>>>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>>> extents)
>>>>>>> == 1)
>>>>>>
>>>>>> It looks like this is working because libxl is setting the maximum
>>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>>> increasing.
>>>>>
>>>>>
>>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>>> understood what it was about. If this was about padding guest's memory
>>>>> to be able to put there some additional data (such ACPI tables) then
>>>>> this is not my intention here: if I can't populate (because it is
>>>>> already populated, I guess) then I try to move memory around with code
>>>>> below. That's what mem_hole_populate_ram() does as well.
>>>>
>>>> The maximum amount of memory that could be assigned to a domain is
>>>> fixed per-domain. This maximum amount does not take into account the
>>>> size of the ACPI blob. So you may end up to fail because all the
>>>> memory was assigned somewhere else.
>>>
>>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>>> we should fail and not rely on this slack if no more memory is
>>> available.
>>>
>>> ...
>>
>> Because, at least for ARM, the ACPI memory region is not part of the
>> "real" RAM. So this value is not taken into account into the current
>> max mem.
>
>
> Hmm.. I've always assumed it is part of memory but marked as a special
> type in e820 map on x86. Maybe Andrew or Jan can comment on this.
I guess you both mean the same - note how Julien says _"real" RAM_.
So from a hypervisor resource consumption view this ought to be
considered RAM; from a guest view it wouldn't be.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-07 8:38 ` Jan Beulich
@ 2016-07-07 15:08 ` Boris Ostrovsky
2016-07-07 15:12 ` Julien Grall
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-07 15:08 UTC (permalink / raw)
To: Jan Beulich, Julien Grall, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
zhaoshenglong, roger.pau
On 07/07/2016 04:38 AM, Jan Beulich wrote:
>>>> On 06.07.16 at 19:33, <boris.ostrovsky@oracle.com> wrote:
>> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>>
>>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>>>> Hi Boris,
>>>>>
>>>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>>>> + xen_pfn_t *extents,
>>>>>>>> + unsigned int num_pages,
>>>>>>>> + struct acpi_ctxt *ctxt)
>>>>>>>> +{
>>>>>>>> + int rc;
>>>>>>>> + xc_interface *xch = dom->xch;
>>>>>>>> + uint32_t domid = dom->guest_domid;
>>>>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>>>> ctxt->page_shift));
>>>>>>>> +
>>>>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>>>>> +
>>>>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>>>> extents)
>>>>>>>> == 1)
>>>>>>> It looks like this is working because libxl is setting the maximum
>>>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>>>> increasing.
>>>>>>
>>>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>>>> understood what it was about. If this was about padding guest's memory
>>>>>> to be able to put there some additional data (such ACPI tables) then
>>>>>> this is not my intention here: if I can't populate (because it is
>>>>>> already populated, I guess) then I try to move memory around with code
>>>>>> below. That's what mem_hole_populate_ram() does as well.
>>>>> The maximum amount of memory that could be assigned to a domain is
>>>>> fixed per-domain. This maximum amount does not take into account the
>>>>> size of the ACPI blob. So you may end up to fail because all the
>>>>> memory was assigned somewhere else.
>>>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>>>> we should fail and not rely on this slack if no more memory is
>>>> available.
>>>>
>>>> ...
>>> Because, at least for ARM, the ACPI memory region is not part of the
>>> "real" RAM. So this value is not taken into account into the current
>>> max mem.
>>
>> Hmm.. I've always assumed it is part of memory but marked as a special
>> type in e820 map on x86. Maybe Andrew or Jan can comment on this.
> I guess you both mean the same - note how Julien says _"real" RAM_.
> So from a hypervisor resource consumption view this ought to be
> considered RAM; from a guest view it wouldn't be.
In which case we shouldn't pad maxmem specified by guest's config file.
Space to put ACPI tables must come from requested resources. If the
tables don't fit then more memory should have been asked for.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-07 15:08 ` Boris Ostrovsky
@ 2016-07-07 15:12 ` Julien Grall
2016-07-07 15:24 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-07 15:12 UTC (permalink / raw)
To: Boris Ostrovsky, Jan Beulich, xen-devel
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
zhaoshenglong, roger.pau
On 07/07/16 16:08, Boris Ostrovsky wrote:
> On 07/07/2016 04:38 AM, Jan Beulich wrote:
>>>>> On 06.07.16 at 19:33, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>>>
>>>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>>>>> Hi Boris,
>>>>>>
>>>>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>>>>> + xen_pfn_t *extents,
>>>>>>>>> + unsigned int num_pages,
>>>>>>>>> + struct acpi_ctxt *ctxt)
>>>>>>>>> +{
>>>>>>>>> + int rc;
>>>>>>>>> + xc_interface *xch = dom->xch;
>>>>>>>>> + uint32_t domid = dom->guest_domid;
>>>>>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>>>>> ctxt->page_shift));
>>>>>>>>> +
>>>>>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>>>>>> +
>>>>>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>>>>> extents)
>>>>>>>>> == 1)
>>>>>>>> It looks like this is working because libxl is setting the maximum
>>>>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>>>>> increasing.
>>>>>>>
>>>>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>>>>> understood what it was about. If this was about padding guest's memory
>>>>>>> to be able to put there some additional data (such ACPI tables) then
>>>>>>> this is not my intention here: if I can't populate (because it is
>>>>>>> already populated, I guess) then I try to move memory around with code
>>>>>>> below. That's what mem_hole_populate_ram() does as well.
>>>>>> The maximum amount of memory that could be assigned to a domain is
>>>>>> fixed per-domain. This maximum amount does not take into account the
>>>>>> size of the ACPI blob. So you may end up to fail because all the
>>>>>> memory was assigned somewhere else.
>>>>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>>>>> we should fail and not rely on this slack if no more memory is
>>>>> available.
>>>>>
>>>>> ...
>>>> Because, at least for ARM, the ACPI memory region is not part of the
>>>> "real" RAM. So this value is not taken into account into the current
>>>> max mem.
>>>
>>> Hmm.. I've always assumed it is part of memory but marked as a special
>>> type in e820 map on x86. Maybe Andrew or Jan can comment on this.
>> I guess you both mean the same - note how Julien says _"real" RAM_.
>> So from a hypervisor resource consumption view this ought to be
>> considered RAM; from a guest view it wouldn't be.
>
> In which case we shouldn't pad maxmem specified by guest's config file.
> Space to put ACPI tables must come from requested resources. If the
> tables don't fit then more memory should have been asked for.
Why? In the case of ARM, the ACPI tables lives outside the guest RAM in
a special region. I would have expect to be the same in x86.
If so, I don't think this should be part of the maxmem requested by the
user. IIRC, it is the same of the PCI ROM. The maxmem is incremented by
the toolstack.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-07 15:12 ` Julien Grall
@ 2016-07-07 15:24 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-07 15:24 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, wei.liu2, andrew.cooper3, ian.jackson,
xen-devel, zhaoshenglong, Boris Ostrovsky, roger.pau
>>> On 07.07.16 at 17:12, <julien.grall@arm.com> wrote:
>
> On 07/07/16 16:08, Boris Ostrovsky wrote:
>> On 07/07/2016 04:38 AM, Jan Beulich wrote:
>>>>>> On 06.07.16 at 19:33, <boris.ostrovsky@oracle.com> wrote:
>>>> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>>>>
>>>>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>>>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
>>>>>>> Hi Boris,
>>>>>>>
>>>>>>> On 06/07/16 16:50, Boris Ostrovsky wrote:
>>>>>>>> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>>>>>>>> +static int populate_acpi_pages(struct xc_dom_image *dom,
>>>>>>>>>> + xen_pfn_t *extents,
>>>>>>>>>> + unsigned int num_pages,
>>>>>>>>>> + struct acpi_ctxt *ctxt)
>>>>>>>>>> +{
>>>>>>>>>> + int rc;
>>>>>>>>>> + xc_interface *xch = dom->xch;
>>>>>>>>>> + uint32_t domid = dom->guest_domid;
>>>>>>>>>> + unsigned long idx, first_high_idx = (1ull << (32 -
>>>>>>>>>> ctxt->page_shift));
>>>>>>>>>> +
>>>>>>>>>> + for (; num_pages; num_pages--, extents++) {
>>>>>>>>>> +
>>>>>>>>>> + if (xc_domain_populate_physmap(xch, domid, 1, 0, 0,
>>>>>>>>>> extents)
>>>>>>>>>> == 1)
>>>>>>>>> It looks like this is working because libxl is setting the maximum
>>>>>>>>> size of the domain with some slack (1MB). You might get in trouble if
>>>>>>>>> the slack is reduced or used by someone or the ACPI blob is
>>>>>>>>> increasing.
>>>>>>>>
>>>>>>>> I saw your conversation about slack with Stefano and I am not sure I
>>>>>>>> understood what it was about. If this was about padding guest's memory
>>>>>>>> to be able to put there some additional data (such ACPI tables) then
>>>>>>>> this is not my intention here: if I can't populate (because it is
>>>>>>>> already populated, I guess) then I try to move memory around with code
>>>>>>>> below. That's what mem_hole_populate_ram() does as well.
>>>>>>> The maximum amount of memory that could be assigned to a domain is
>>>>>>> fixed per-domain. This maximum amount does not take into account the
>>>>>>> size of the ACPI blob. So you may end up to fail because all the
>>>>>>> memory was assigned somewhere else.
>>>>>> Why shouldn't max amount of guest's memory include ACPI tables? I think
>>>>>> we should fail and not rely on this slack if no more memory is
>>>>>> available.
>>>>>>
>>>>>> ...
>>>>> Because, at least for ARM, the ACPI memory region is not part of the
>>>>> "real" RAM. So this value is not taken into account into the current
>>>>> max mem.
>>>>
>>>> Hmm.. I've always assumed it is part of memory but marked as a special
>>>> type in e820 map on x86. Maybe Andrew or Jan can comment on this.
>>> I guess you both mean the same - note how Julien says _"real" RAM_.
>>> So from a hypervisor resource consumption view this ought to be
>>> considered RAM; from a guest view it wouldn't be.
>>
>> In which case we shouldn't pad maxmem specified by guest's config file.
>> Space to put ACPI tables must come from requested resources. If the
>> tables don't fit then more memory should have been asked for.
>
> Why? In the case of ARM, the ACPI tables lives outside the guest RAM in
> a special region. I would have expect to be the same in x86.
This is still RAM from a host resource accounting POV.
> If so, I don't think this should be part of the maxmem requested by the
> user. IIRC, it is the same of the PCI ROM. The maxmem is incremented by
> the toolstack.
For some parts iirc, and not for others. See also (for example) the
recent discussion George had with PGNet Dev
(https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00353.html).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-05 19:05 ` [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
2016-07-06 11:05 ` Julien Grall
@ 2016-07-08 10:55 ` Wei Liu
2016-07-08 14:48 ` Boris Ostrovsky
1 sibling, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-08 10:55 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Tue, Jul 05, 2016 at 03:05:19PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>
> Changes in v1:
> * Move to libxl
> * Added populate_acpi_pages()
> * Stash location/size of tables in xc_dom_image (to be used in constructing e820 map)
> * Use libxl allocator
> * Only set XEN_X86_EMU_LAPIC flag if 'apic' option is set.
> * Make acpi_build_tables() return error code
>
> .gitignore | 4 +
> tools/libacpi/build.c | 7 +-
> tools/libacpi/libacpi.h | 15 ++-
> tools/libxl/Makefile | 17 +++-
> tools/libxl/libxl_arch.h | 3 +
> tools/libxl/libxl_dom.c | 1 +
> tools/libxl/libxl_x86.c | 29 +++--
> tools/libxl/libxl_x86_acpi.c | 292 ++++++++++++++++++++++++++++++++++++++++++
> tools/libxl/libxl_x86_acpi.h | 21 +++
> 9 files changed, 373 insertions(+), 16 deletions(-)
> create mode 100644 tools/libxl/libxl_x86_acpi.c
> create mode 100644 tools/libxl/libxl_x86_acpi.h
>
> diff --git a/.gitignore b/.gitignore
> index 9dd2086..d4da37f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -179,6 +179,10 @@ tools/libxl/testenum.c
> tools/libxl/tmp.*
> tools/libxl/_libxl.api-for-check
> tools/libxl/*.api-ok
> +tools/libxl/mk_dsdt
> +tools/libxl/dsdt*.c
> +tools/libxl/dsdt_*.asl
> +tools/libxl/ssdt_*.h
Please sort these alphabetically.
> tools/misc/cpuperf/cpuperf-perfcntr
> tools/misc/cpuperf/cpuperf-xen
> tools/misc/xc_shadow
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index 290f005..a6ddf53 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -23,6 +23,7 @@
> #include "ssdt_tpm.h"
> #include "ssdt_pm.h"
> #include "x86.h"
> +#include <xen/hvm/hvm_info_table.h>
> #include <xen/hvm/hvm_xs_strings.h>
> #include <xen/hvm/params.h>
>
[...]
> +int libxl__dom_load_acpi(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + struct xc_dom_image *dom);
Indentation.
> #endif
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index ba3472e..7e4e289 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -657,6 +657,7 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
> LOGE(ERROR, "xc_dom_build_image failed");
> goto out;
> }
> +
Stray blank line.
> if ( (ret = xc_dom_boot_image(dom)) != 0 ) {
> LOGE(ERROR, "xc_dom_boot_image failed");
> goto out;
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index 32ce1d2..7201dbb 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
[...]
> +int libxl__dom_load_acpi(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + struct xc_dom_image *dom)
> +{
> + struct acpi_config config = {0};
> + struct acpi_ctxt ctxt;
> + uint32_t domid = dom->guest_domid;
> + xc_interface *xch = dom->xch;
> + int rc, i, acpi_pages_num;
> + xen_pfn_t extent, *extents;
> + void *acpi_pages, *guest_acpi_pages = NULL;
> + unsigned long page_mask;
> +
> + if ((info->type != LIBXL_DOMAIN_TYPE_HVM) ||
> + (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_NONE))
> + return 0;
> +
> + ctxt.page_size = XC_DOM_PAGE_SIZE(dom);
> + ctxt.page_shift = XC_DOM_PAGE_SHIFT(dom);
> + page_mask = (1UL << ctxt.page_shift) - 1;
> +
> + ctxt.mem_ops.alloc = mem_alloc;
> + ctxt.mem_ops.v2p = virt_to_phys;
> +
> + rc = init_acpi_config(gc, dom, info, &config);
> + if (rc) {
> + LOG(ERROR, "%s: init_acpi_config failed (rc=%d)", __FUNCTION__, rc);
> + return rc;
> + }
> +
> + /* Map page that will hold RSDP */
> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> + if (rc) {
> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> + __FUNCTION__, rc);
> + goto out;
> + }
> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> + ctxt.page_size,
> + PROT_READ | PROT_WRITE,
> + RSDP_ADDRESS >> ctxt.page_shift);
I think with Anthony's on-going work you should be more flexible for all
you tables.
I haven't really looked into details for this patch. Let's sort out
the linkage issue between GPLv2 cod and LGPL code first.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-08 10:55 ` Wei Liu
@ 2016-07-08 14:48 ` Boris Ostrovsky
2016-07-08 16:07 ` Wei Liu
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 14:48 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, roger.pau
On 07/08/2016 06:55 AM, Wei Liu wrote:
>
>> +
>> + /* Map page that will hold RSDP */
>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>> + if (rc) {
>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>> + __FUNCTION__, rc);
>> + goto out;
>> + }
>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>> + ctxt.page_size,
>> + PROT_READ | PROT_WRITE,
>> + RSDP_ADDRESS >> ctxt.page_shift);
> I think with Anthony's on-going work you should be more flexible for all
> you tables.
Not sure I understand what you mean here. You want the address
(RSDP_ADDRESS) to be a variable as opposed to a macro?
>
> I haven't really looked into details for this patch. Let's sort out
> the linkage issue between GPLv2 cod and LGPL code first.
Ugh.. Yes, this one didn't even cross my mind until you brought it up
yesterday.
What are the options? Can we dual-license those files as GPLv2/LGPL,
assuming copyright holders --- Keir (or Citrix?) and Intel --- agree?
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-08 14:48 ` Boris Ostrovsky
@ 2016-07-08 16:07 ` Wei Liu
2016-07-08 17:20 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-08 16:07 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, Anthony PERARD, roger.pau
On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> On 07/08/2016 06:55 AM, Wei Liu wrote:
> >
> >> +
> >> + /* Map page that will hold RSDP */
> >> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> >> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> >> + if (rc) {
> >> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> >> + __FUNCTION__, rc);
> >> + goto out;
> >> + }
> >> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> >> + ctxt.page_size,
> >> + PROT_READ | PROT_WRITE,
> >> + RSDP_ADDRESS >> ctxt.page_shift);
> > I think with Anthony's on-going work you should be more flexible for all
> > you tables.
>
> Not sure I understand what you mean here. You want the address
> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>
I'm still trying to wrap my head around the possible interaction between
Anthony's work and your work.
Anthony's work allows dynamically loading of firmware blobs. If you use
a fixed address, theoretically it can clash with firmware blobs among
other things libxc can load. The high address is a safe bet so that
probably won't happen in practice.
Anthony's work allows loading arbitrary blobs actually. Can you take
advantage of that mechanism as well? That is, to specify all your tables
as modules and let libxc handle actually loading them into guest
memory.
Does this make sense?
Also CC Anthony here.
> >
> > I haven't really looked into details for this patch. Let's sort out
> > the linkage issue between GPLv2 cod and LGPL code first.
>
>
> Ugh.. Yes, this one didn't even cross my mind until you brought it up
> yesterday.
>
> What are the options? Can we dual-license those files as GPLv2/LGPL,
> assuming copyright holders --- Keir (or Citrix?) and Intel --- agree?
>
I don't claim I know much about licenses. Let's discuss this issue in
the other thread instead of having two threads.
I think what Ian said makes sense FWIW.
Wei.
> -boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-08 16:07 ` Wei Liu
@ 2016-07-08 17:20 ` Boris Ostrovsky
2016-07-11 10:47 ` Wei Liu
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-08 17:20 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, Anthony PERARD, roger.pau
On 07/08/2016 12:07 PM, Wei Liu wrote:
> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
>> On 07/08/2016 06:55 AM, Wei Liu wrote:
>>>> +
>>>> + /* Map page that will hold RSDP */
>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>>> + if (rc) {
>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>>> + __FUNCTION__, rc);
>>>> + goto out;
>>>> + }
>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>>> + ctxt.page_size,
>>>> + PROT_READ | PROT_WRITE,
>>>> + RSDP_ADDRESS >> ctxt.page_shift);
>>> I think with Anthony's on-going work you should be more flexible for all
>>> you tables.
>> Not sure I understand what you mean here. You want the address
>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>>
> I'm still trying to wrap my head around the possible interaction between
> Anthony's work and your work.
>
> Anthony's work allows dynamically loading of firmware blobs. If you use
> a fixed address, theoretically it can clash with firmware blobs among
> other things libxc can load. The high address is a safe bet so that
> probably won't happen in practice.
>
> Anthony's work allows loading arbitrary blobs actually. Can you take
> advantage of that mechanism as well? That is, to specify all your tables
> as modules and let libxc handle actually loading them into guest
> memory.
>
> Does this make sense?
>
> Also CC Anthony here.
My understanding of Anthony's series is that its goal was to provide an
interface to pass DSDT (and maybe some other tables) from the toolstack
to hvmloader.
Here we don't have hvmloader, we are loading the tables directly into
guest's memory.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-08 17:20 ` Boris Ostrovsky
@ 2016-07-11 10:47 ` Wei Liu
2016-07-11 13:33 ` Boris Ostrovsky
0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-11 10:47 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, Anthony PERARD, roger.pau
On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
> On 07/08/2016 12:07 PM, Wei Liu wrote:
> > On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> >> On 07/08/2016 06:55 AM, Wei Liu wrote:
> >>>> +
> >>>> + /* Map page that will hold RSDP */
> >>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> >>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> >>>> + if (rc) {
> >>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> >>>> + __FUNCTION__, rc);
> >>>> + goto out;
> >>>> + }
> >>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> >>>> + ctxt.page_size,
> >>>> + PROT_READ | PROT_WRITE,
> >>>> + RSDP_ADDRESS >> ctxt.page_shift);
> >>> I think with Anthony's on-going work you should be more flexible for all
> >>> you tables.
> >> Not sure I understand what you mean here. You want the address
> >> (RSDP_ADDRESS) to be a variable as opposed to a macro?
> >>
> > I'm still trying to wrap my head around the possible interaction between
> > Anthony's work and your work.
> >
> > Anthony's work allows dynamically loading of firmware blobs. If you use
> > a fixed address, theoretically it can clash with firmware blobs among
> > other things libxc can load. The high address is a safe bet so that
> > probably won't happen in practice.
> >
> > Anthony's work allows loading arbitrary blobs actually. Can you take
> > advantage of that mechanism as well? That is, to specify all your tables
> > as modules and let libxc handle actually loading them into guest
> > memory.
> >
> > Does this make sense?
> >
> > Also CC Anthony here.
>
>
> My understanding of Anthony's series is that its goal was to provide an
> interface to pass DSDT (and maybe some other tables) from the toolstack
> to hvmloader.
>
> Here we don't have hvmloader, we are loading the tables directly into
> guest's memory.
>
Do you use the same hvm_start_info structure? I don't think that
structure is restricted to hvmloader.
Wei.
> -boris
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 10:47 ` Wei Liu
@ 2016-07-11 13:33 ` Boris Ostrovsky
2016-07-11 13:39 ` Julien Grall
` (2 more replies)
0 siblings, 3 replies; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-11 13:33 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, Anthony PERARD, roger.pau
On 07/11/2016 06:47 AM, Wei Liu wrote:
> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
>> On 07/08/2016 12:07 PM, Wei Liu wrote:
>>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
>>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
>>>>>> +
>>>>>> + /* Map page that will hold RSDP */
>>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>>>>> + if (rc) {
>>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>>>>> + __FUNCTION__, rc);
>>>>>> + goto out;
>>>>>> + }
>>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>>>>> + ctxt.page_size,
>>>>>> + PROT_READ | PROT_WRITE,
>>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
>>>>> I think with Anthony's on-going work you should be more flexible for all
>>>>> you tables.
>>>> Not sure I understand what you mean here. You want the address
>>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>>>>
>>> I'm still trying to wrap my head around the possible interaction between
>>> Anthony's work and your work.
>>>
>>> Anthony's work allows dynamically loading of firmware blobs. If you use
>>> a fixed address, theoretically it can clash with firmware blobs among
>>> other things libxc can load. The high address is a safe bet so that
>>> probably won't happen in practice.
>>>
>>> Anthony's work allows loading arbitrary blobs actually. Can you take
>>> advantage of that mechanism as well? That is, to specify all your tables
>>> as modules and let libxc handle actually loading them into guest
>>> memory.
>>>
>>> Does this make sense?
>>>
>>> Also CC Anthony here.
>>
>> My understanding of Anthony's series is that its goal was to provide an
>> interface to pass DSDT (and maybe some other tables) from the toolstack
>> to hvmloader.
>>
>> Here we don't have hvmloader, we are loading the tables directly into
>> guest's memory.
>>
> Do you use the same hvm_start_info structure? I don't think that
> structure is restricted to hvmloader.
Yes, we do. However, in PVH(v2) case it will be seen next by the guest
who will expect the tables to already be in memory. I.e. there is no
intermediate Xen component, such as hvmloader, who can load the blobs.
Having said that, I wonder whether we (both x86 and ARM) could use
Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
Shannon's series added. (even if we can't, I think
xc_hvm_firmware_module is the right datastructure to store the blob
since it has both toolstack's virtual and guest's physical addresses).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:33 ` Boris Ostrovsky
@ 2016-07-11 13:39 ` Julien Grall
2016-07-11 13:42 ` Wei Liu
2016-07-11 13:41 ` Wei Liu
2016-07-11 14:00 ` Anthony PERARD
2 siblings, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-11 13:39 UTC (permalink / raw)
To: Boris Ostrovsky, Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, jbeulich, zhaoshenglong,
Anthony PERARD, roger.pau
On 11/07/16 14:33, Boris Ostrovsky wrote:
> On 07/11/2016 06:47 AM, Wei Liu wrote:
>> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
>>> On 07/08/2016 12:07 PM, Wei Liu wrote:
>>>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
>>>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
>>>>>>> +
>>>>>>> + /* Map page that will hold RSDP */
>>>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>>>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>>>>>> + if (rc) {
>>>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>>>>>> + __FUNCTION__, rc);
>>>>>>> + goto out;
>>>>>>> + }
>>>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>>>>>> + ctxt.page_size,
>>>>>>> + PROT_READ | PROT_WRITE,
>>>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
>>>>>> I think with Anthony's on-going work you should be more flexible for all
>>>>>> you tables.
>>>>> Not sure I understand what you mean here. You want the address
>>>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>>>>>
>>>> I'm still trying to wrap my head around the possible interaction between
>>>> Anthony's work and your work.
>>>>
>>>> Anthony's work allows dynamically loading of firmware blobs. If you use
>>>> a fixed address, theoretically it can clash with firmware blobs among
>>>> other things libxc can load. The high address is a safe bet so that
>>>> probably won't happen in practice.
>>>>
>>>> Anthony's work allows loading arbitrary blobs actually. Can you take
>>>> advantage of that mechanism as well? That is, to specify all your tables
>>>> as modules and let libxc handle actually loading them into guest
>>>> memory.
>>>>
>>>> Does this make sense?
>>>>
>>>> Also CC Anthony here.
>>>
>>> My understanding of Anthony's series is that its goal was to provide an
>>> interface to pass DSDT (and maybe some other tables) from the toolstack
>>> to hvmloader.
>>>
>>> Here we don't have hvmloader, we are loading the tables directly into
>>> guest's memory.
>>>
>> Do you use the same hvm_start_info structure? I don't think that
>> structure is restricted to hvmloader.
>
>
> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> who will expect the tables to already be in memory. I.e. there is no
> intermediate Xen component, such as hvmloader, who can load the blobs.
>
> Having said that, I wonder whether we (both x86 and ARM) could use
> Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
> Shannon's series added. (even if we can't, I think
> xc_hvm_firmware_module is the right datastructure to store the blob
> since it has both toolstack's virtual and guest's physical addresses).
In this case, xc_hvm_firmware_module would need to be renamed as ARM
guests are neither HVM nor PV.
FWIW, from the toolstack point of view, ARM guests is considered as PV
guest.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:39 ` Julien Grall
@ 2016-07-11 13:42 ` Wei Liu
2016-07-11 13:58 ` Julien Grall
0 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-11 13:42 UTC (permalink / raw)
To: Julien Grall
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, jbeulich,
zhaoshenglong, Anthony PERARD, Boris Ostrovsky, roger.pau
On Mon, Jul 11, 2016 at 02:39:05PM +0100, Julien Grall wrote:
> >Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> >who will expect the tables to already be in memory. I.e. there is no
> >intermediate Xen component, such as hvmloader, who can load the blobs.
> >
> >Having said that, I wonder whether we (both x86 and ARM) could use
> >Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
> >Shannon's series added. (even if we can't, I think
> >xc_hvm_firmware_module is the right datastructure to store the blob
> >since it has both toolstack's virtual and guest's physical addresses).
>
> In this case, xc_hvm_firmware_module would need to be renamed as ARM guests
> are neither HVM nor PV.
>
That's trivial. It's an internal structure that we can rename at will.
> FWIW, from the toolstack point of view, ARM guests is considered as PV
> guest.
... while at the same time utilises HVM param...
Not complaining, just this makes me chuckle a bit. :-)
Wei.
>
> Regards,
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:42 ` Wei Liu
@ 2016-07-11 13:58 ` Julien Grall
0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-07-11 13:58 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, jbeulich, zhaoshenglong,
Anthony PERARD, Boris Ostrovsky, roger.pau
On 11/07/16 14:42, Wei Liu wrote:
> On Mon, Jul 11, 2016 at 02:39:05PM +0100, Julien Grall wrote:
>>> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
>>> who will expect the tables to already be in memory. I.e. there is no
>>> intermediate Xen component, such as hvmloader, who can load the blobs.
>>>
>>> Having said that, I wonder whether we (both x86 and ARM) could use
>>> Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
>>> Shannon's series added. (even if we can't, I think
>>> xc_hvm_firmware_module is the right datastructure to store the blob
>>> since it has both toolstack's virtual and guest's physical addresses).
>>
>> In this case, xc_hvm_firmware_module would need to be renamed as ARM guests
>> are neither HVM nor PV.
>>
>
> That's trivial. It's an internal structure that we can rename at will.
>
>> FWIW, from the toolstack point of view, ARM guests is considered as PV
>> guest.
>
> ... while at the same time utilises HVM param...
>
> Not complaining, just this makes me chuckle a bit. :-)
ARM guests is a combination of HVM and PV features. I agree it is a bit
a mess, but there is code in the hypervisor/toolstack/Linux which rely
on the type of guests (e.g LIBXL_DOMAIN_TYPE_* in libxl) and not a set
of available features.
In the hypervisor, we are trying to move towards a set of features (i.e
dropping is_pv_domain/is_hvm_domain in common code) as none suit ARM
guests.
I think it will benefit for both ARM and x86 to move available features
rather than type. However this is requiring a lot of rework which cannot
be done quickly.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:33 ` Boris Ostrovsky
2016-07-11 13:39 ` Julien Grall
@ 2016-07-11 13:41 ` Wei Liu
2016-07-11 14:40 ` Boris Ostrovsky
2016-07-11 14:00 ` Anthony PERARD
2 siblings, 1 reply; 104+ messages in thread
From: Wei Liu @ 2016-07-11 13:41 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, Anthony PERARD, roger.pau
On Mon, Jul 11, 2016 at 09:33:21AM -0400, Boris Ostrovsky wrote:
> On 07/11/2016 06:47 AM, Wei Liu wrote:
> > On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
> >> On 07/08/2016 12:07 PM, Wei Liu wrote:
> >>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> >>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
> >>>>>> +
> >>>>>> + /* Map page that will hold RSDP */
> >>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> >>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> >>>>>> + if (rc) {
> >>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> >>>>>> + __FUNCTION__, rc);
> >>>>>> + goto out;
> >>>>>> + }
> >>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> >>>>>> + ctxt.page_size,
> >>>>>> + PROT_READ | PROT_WRITE,
> >>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
> >>>>> I think with Anthony's on-going work you should be more flexible for all
> >>>>> you tables.
> >>>> Not sure I understand what you mean here. You want the address
> >>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
> >>>>
> >>> I'm still trying to wrap my head around the possible interaction between
> >>> Anthony's work and your work.
> >>>
> >>> Anthony's work allows dynamically loading of firmware blobs. If you use
> >>> a fixed address, theoretically it can clash with firmware blobs among
> >>> other things libxc can load. The high address is a safe bet so that
> >>> probably won't happen in practice.
> >>>
> >>> Anthony's work allows loading arbitrary blobs actually. Can you take
> >>> advantage of that mechanism as well? That is, to specify all your tables
> >>> as modules and let libxc handle actually loading them into guest
> >>> memory.
> >>>
> >>> Does this make sense?
> >>>
> >>> Also CC Anthony here.
> >>
> >> My understanding of Anthony's series is that its goal was to provide an
> >> interface to pass DSDT (and maybe some other tables) from the toolstack
> >> to hvmloader.
> >>
> >> Here we don't have hvmloader, we are loading the tables directly into
> >> guest's memory.
> >>
> > Do you use the same hvm_start_info structure? I don't think that
> > structure is restricted to hvmloader.
>
>
> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> who will expect the tables to already be in memory. I.e. there is no
> intermediate Xen component, such as hvmloader, who can load the blobs.
>
Maybe you misunderstood. Anthony's work will load the blobs into guest
memory -- all fields in hvm_start_info points to guest physical address
IIRC. Hvmloader might want to relocate them, but that's a different
matter.
> Having said that, I wonder whether we (both x86 and ARM) could use
> Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
> Shannon's series added. (even if we can't, I think
> xc_hvm_firmware_module is the right datastructure to store the blob
> since it has both toolstack's virtual and guest's physical addresses).
>
Yes, that's along the line I'm thinking about.
Wei.
> -boris
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:41 ` Wei Liu
@ 2016-07-11 14:40 ` Boris Ostrovsky
2016-07-12 14:30 ` Wei Liu
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-11 14:40 UTC (permalink / raw)
To: Wei Liu
Cc: andrew.cooper3, ian.jackson, xen-devel, julien.grall, jbeulich,
zhaoshenglong, Anthony PERARD, roger.pau
On 07/11/2016 09:41 AM, Wei Liu wrote:
> On Mon, Jul 11, 2016 at 09:33:21AM -0400, Boris Ostrovsky wrote:
>> On 07/11/2016 06:47 AM, Wei Liu wrote:
>>> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
>>>> On 07/08/2016 12:07 PM, Wei Liu wrote:
>>>>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
>>>>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
>>>>>>>> +
>>>>>>>> + /* Map page that will hold RSDP */
>>>>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
>>>>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>>>>>>>> + if (rc) {
>>>>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
>>>>>>>> + __FUNCTION__, rc);
>>>>>>>> + goto out;
>>>>>>>> + }
>>>>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>>>>>>>> + ctxt.page_size,
>>>>>>>> + PROT_READ | PROT_WRITE,
>>>>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
>>>>>>> I think with Anthony's on-going work you should be more flexible for all
>>>>>>> you tables.
>>>>>> Not sure I understand what you mean here. You want the address
>>>>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
>>>>>>
>>>>> I'm still trying to wrap my head around the possible interaction between
>>>>> Anthony's work and your work.
>>>>>
>>>>> Anthony's work allows dynamically loading of firmware blobs. If you use
>>>>> a fixed address, theoretically it can clash with firmware blobs among
>>>>> other things libxc can load. The high address is a safe bet so that
>>>>> probably won't happen in practice.
>>>>>
>>>>> Anthony's work allows loading arbitrary blobs actually. Can you take
>>>>> advantage of that mechanism as well? That is, to specify all your tables
>>>>> as modules and let libxc handle actually loading them into guest
>>>>> memory.
>>>>>
>>>>> Does this make sense?
>>>>>
>>>>> Also CC Anthony here.
>>>> My understanding of Anthony's series is that its goal was to provide an
>>>> interface to pass DSDT (and maybe some other tables) from the toolstack
>>>> to hvmloader.
>>>>
>>>> Here we don't have hvmloader, we are loading the tables directly into
>>>> guest's memory.
>>>>
>>> Do you use the same hvm_start_info structure? I don't think that
>>> structure is restricted to hvmloader.
>>
>> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
>> who will expect the tables to already be in memory. I.e. there is no
>> intermediate Xen component, such as hvmloader, who can load the blobs.
>>
> Maybe you misunderstood. Anthony's work will load the blobs into guest
> memory -- all fields in hvm_start_info points to guest physical address
> IIRC. Hvmloader might want to relocate them, but that's a different
> matter.
What's the status on Anthony's series? I can rebase on top of his tree
(I might indeed be able to reuse some of his code) but if this is way
off the dependencies become problematic (because Shannon's series would
also be delayed).
>
>> Having said that, I wonder whether we (both x86 and ARM) could use
>> Anthony's xc_dom_image.full_acpi_module instead
(no full_acpi_module anymore, I was looking at an earlier series
version. I guess it's system_firmware_module now)
>> of acpitables_blob that
>> Shannon's series added. (even if we can't, I think
>> xc_hvm_firmware_module is the right datastructure to store the blob
>> since it has both toolstack's virtual and guest's physical addresses).
>>
> Yes, that's along the line I'm thinking about.
So I am confused about xc_hvm_firmware_mode: is guest_addr_out meant to
be guest's physical or virtual?
One one hand it looks like virtual:
in
https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02901.html
+ module->guest_addr_out = seg.vstart;
but then in
https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02902.html
+ modlist[index].paddr = module->guest_addr_out;
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 14:40 ` Boris Ostrovsky
@ 2016-07-12 14:30 ` Wei Liu
0 siblings, 0 replies; 104+ messages in thread
From: Wei Liu @ 2016-07-12 14:30 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, Anthony PERARD, roger.pau
On Mon, Jul 11, 2016 at 10:40:17AM -0400, Boris Ostrovsky wrote:
> On 07/11/2016 09:41 AM, Wei Liu wrote:
> > On Mon, Jul 11, 2016 at 09:33:21AM -0400, Boris Ostrovsky wrote:
> >> On 07/11/2016 06:47 AM, Wei Liu wrote:
> >>> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
> >>>> On 07/08/2016 12:07 PM, Wei Liu wrote:
> >>>>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> >>>>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
> >>>>>>>> +
> >>>>>>>> + /* Map page that will hold RSDP */
> >>>>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> >>>>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> >>>>>>>> + if (rc) {
> >>>>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> >>>>>>>> + __FUNCTION__, rc);
> >>>>>>>> + goto out;
> >>>>>>>> + }
> >>>>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> >>>>>>>> + ctxt.page_size,
> >>>>>>>> + PROT_READ | PROT_WRITE,
> >>>>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
> >>>>>>> I think with Anthony's on-going work you should be more flexible for all
> >>>>>>> you tables.
> >>>>>> Not sure I understand what you mean here. You want the address
> >>>>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
> >>>>>>
> >>>>> I'm still trying to wrap my head around the possible interaction between
> >>>>> Anthony's work and your work.
> >>>>>
> >>>>> Anthony's work allows dynamically loading of firmware blobs. If you use
> >>>>> a fixed address, theoretically it can clash with firmware blobs among
> >>>>> other things libxc can load. The high address is a safe bet so that
> >>>>> probably won't happen in practice.
> >>>>>
> >>>>> Anthony's work allows loading arbitrary blobs actually. Can you take
> >>>>> advantage of that mechanism as well? That is, to specify all your tables
> >>>>> as modules and let libxc handle actually loading them into guest
> >>>>> memory.
> >>>>>
> >>>>> Does this make sense?
> >>>>>
> >>>>> Also CC Anthony here.
> >>>> My understanding of Anthony's series is that its goal was to provide an
> >>>> interface to pass DSDT (and maybe some other tables) from the toolstack
> >>>> to hvmloader.
> >>>>
> >>>> Here we don't have hvmloader, we are loading the tables directly into
> >>>> guest's memory.
> >>>>
> >>> Do you use the same hvm_start_info structure? I don't think that
> >>> structure is restricted to hvmloader.
> >>
> >> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> >> who will expect the tables to already be in memory. I.e. there is no
> >> intermediate Xen component, such as hvmloader, who can load the blobs.
> >>
> > Maybe you misunderstood. Anthony's work will load the blobs into guest
> > memory -- all fields in hvm_start_info points to guest physical address
> > IIRC. Hvmloader might want to relocate them, but that's a different
> > matter.
>
> What's the status on Anthony's series? I can rebase on top of his tree
> (I might indeed be able to reuse some of his code) but if this is way
> off the dependencies become problematic (because Shannon's series would
> also be delayed).
>
His series is very close to get merged. I believe toolstack in his
series only require cosmetic changes and hvmloader patches are all
acked.
> >
> >> Having said that, I wonder whether we (both x86 and ARM) could use
> >> Anthony's xc_dom_image.full_acpi_module instead
>
>
> (no full_acpi_module anymore, I was looking at an earlier series
> version. I guess it's system_firmware_module now)
>
>
> >> of acpitables_blob that
> >> Shannon's series added. (even if we can't, I think
> >> xc_hvm_firmware_module is the right datastructure to store the blob
> >> since it has both toolstack's virtual and guest's physical addresses).
> >>
> > Yes, that's along the line I'm thinking about.
>
> So I am confused about xc_hvm_firmware_mode: is guest_addr_out meant to
> be guest's physical or virtual?
>
> One one hand it looks like virtual:
>
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02901.html
> + module->guest_addr_out = seg.vstart;
>
> but then in
> https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02902.html
>
> + modlist[index].paddr = module->guest_addr_out;
>
It should be guest physical.
Wei.
>
> -boris
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests
2016-07-11 13:33 ` Boris Ostrovsky
2016-07-11 13:39 ` Julien Grall
2016-07-11 13:41 ` Wei Liu
@ 2016-07-11 14:00 ` Anthony PERARD
2 siblings, 0 replies; 104+ messages in thread
From: Anthony PERARD @ 2016-07-11 14:00 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Wei Liu, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong, roger.pau
On Mon, Jul 11, 2016 at 09:33:21AM -0400, Boris Ostrovsky wrote:
> On 07/11/2016 06:47 AM, Wei Liu wrote:
> > On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
> >> On 07/08/2016 12:07 PM, Wei Liu wrote:
> >>> On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> >>>> On 07/08/2016 06:55 AM, Wei Liu wrote:
> >>>>>> +
> >>>>>> + /* Map page that will hold RSDP */
> >>>>>> + extent = RSDP_ADDRESS >> ctxt.page_shift;
> >>>>>> + rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
> >>>>>> + if (rc) {
> >>>>>> + LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with %d",
> >>>>>> + __FUNCTION__, rc);
> >>>>>> + goto out;
> >>>>>> + }
> >>>>>> + config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
> >>>>>> + ctxt.page_size,
> >>>>>> + PROT_READ | PROT_WRITE,
> >>>>>> + RSDP_ADDRESS >> ctxt.page_shift);
> >>>>> I think with Anthony's on-going work you should be more flexible for all
> >>>>> you tables.
If the tool stack already knows where it can (or should) load the rsdp,
there is not much reason to be flexible.
> >>>> Not sure I understand what you mean here. You want the address
> >>>> (RSDP_ADDRESS) to be a variable as opposed to a macro?
> >>>>
> >>> I'm still trying to wrap my head around the possible interaction between
> >>> Anthony's work and your work.
> >>>
> >>> Anthony's work allows dynamically loading of firmware blobs. If you use
> >>> a fixed address, theoretically it can clash with firmware blobs among
> >>> other things libxc can load. The high address is a safe bet so that
> >>> probably won't happen in practice.
> >>>
> >>> Anthony's work allows loading arbitrary blobs actually. Can you take
> >>> advantage of that mechanism as well? That is, to specify all your tables
> >>> as modules and let libxc handle actually loading them into guest
> >>> memory.
> >>>
> >>> Does this make sense?
> >>>
> >>> Also CC Anthony here.
> >>
> >> My understanding of Anthony's series is that its goal was to provide an
> >> interface to pass DSDT (and maybe some other tables) from the toolstack
> >> to hvmloader.
Not anymore. The only new functionality provided by the patch series is
to load the BIOS (or OVMF) from the filesystem (instead of having this
blob embedded into hvmloader).
It does also change the way an extra acpi tables or a smbios is loaded
into guest memory for consumption by hvmloader. But that just make the
libxc code a bit cleaner.
> >> Here we don't have hvmloader, we are loading the tables directly into
> >> guest's memory.
> >>
> > Do you use the same hvm_start_info structure? I don't think that
> > structure is restricted to hvmloader.
>
>
> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> who will expect the tables to already be in memory. I.e. there is no
> intermediate Xen component, such as hvmloader, who can load the blobs.
>
> Having said that, I wonder whether we (both x86 and ARM) could use
> Anthony's xc_dom_image.full_acpi_module instead of acpitables_blob that
I don't have full_acpi_module anymore in my patch series. But that does
not prevent you from introducing one.
> Shannon's series added. (even if we can't, I think
> xc_hvm_firmware_module is the right datastructure to store the blob
> since it has both toolstack's virtual and guest's physical addresses).
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-05 19:04 [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
` (19 preceding siblings ...)
2016-07-05 19:05 ` [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
@ 2016-07-06 16:04 ` Roger Pau Monné
2016-07-06 16:32 ` Boris Ostrovsky
20 siblings, 1 reply; 104+ messages in thread
From: Roger Pau Monné @ 2016-07-06 16:04 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong
Hello,
Thanks for the refresh! Do you have this series in some git tree I can pull
from?
On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
> This is V1 of the series posted earlier as an RFC
>
> The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing existing
> hvmloader's ACPI builder code. The builder is provided as a library in tools/libacpi.
>
> Main changes from RFC are:
> * Move toolstack code that loads the tables into PVHv2 guest from libxc to libxl
> * Don't provide the builder to hypervisor as we didn't find a user for that (at least so far)
> * Update e820 map for PVHv2 guests when ACPI tables are loaded
> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
Hm, I still think HW_REDUCED_ACPI should be set for the time being,
considering that we don't provide PM timer or RTC for example. Not setting
this would be a violation of the ACPI specification, and would mean
introducing Xen specific hacks yet again to guest OSes, in order to disable
those devices.
Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-06 16:04 ` [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader Roger Pau Monné
@ 2016-07-06 16:32 ` Boris Ostrovsky
2016-07-07 8:35 ` Jan Beulich
0 siblings, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-06 16:32 UTC (permalink / raw)
To: Roger Pau Monné
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
jbeulich, zhaoshenglong
On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
> Hello,
>
> Thanks for the refresh! Do you have this series in some git tree I can pull
> from?
Sorry, forgot to include this in the message:
git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1
>
> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>> This is V1 of the series posted earlier as an RFC
>>
>> The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing existing
>> hvmloader's ACPI builder code. The builder is provided as a library in tools/libacpi.
>>
>> Main changes from RFC are:
>> * Move toolstack code that loads the tables into PVHv2 guest from libxc to libxl
>> * Don't provide the builder to hypervisor as we didn't find a user for that (at least so far)
>> * Update e820 map for PVHv2 guests when ACPI tables are loaded
>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
> considering that we don't provide PM timer or RTC for example. Not setting
> this would be a violation of the ACPI specification, and would mean
> introducing Xen specific hacks yet again to guest OSes, in order to disable
> those devices.
>
> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
Yes, because we build v2 tables and they are somewhat different.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-06 16:32 ` Boris Ostrovsky
@ 2016-07-07 8:35 ` Jan Beulich
2016-07-07 9:14 ` Julien Grall
2016-07-07 15:04 ` Boris Ostrovsky
0 siblings, 2 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-07 8:35 UTC (permalink / raw)
To: roger.pau, Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong
>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>> considering that we don't provide PM timer or RTC for example. Not setting
>> this would be a violation of the ACPI specification, and would mean
>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>> those devices.
>>
>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>
> Yes, because we build v2 tables and they are somewhat different.
So couldn't we switch to building v5 tables (or even v6) for PVH
(and perhaps re-using the "acpi=" config setting to allow specifying a
version - with any value above 1 indicating the requested version)? I
certainly agree that setting a v5 flag in a v2 table is bad (best we can
hope for is that any consumer would ignore such a flag).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-07 8:35 ` Jan Beulich
@ 2016-07-07 9:14 ` Julien Grall
2016-07-07 9:20 ` Jan Beulich
2016-07-07 15:04 ` Boris Ostrovsky
1 sibling, 1 reply; 104+ messages in thread
From: Julien Grall @ 2016-07-07 9:14 UTC (permalink / raw)
To: Jan Beulich, roger.pau, Boris Ostrovsky
Cc: andrew.cooper3, xen-devel, wei.liu2, ian.jackson, zhaoshenglong
On 07/07/16 09:35, Jan Beulich wrote:
>>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
>>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>>> considering that we don't provide PM timer or RTC for example. Not setting
>>> this would be a violation of the ACPI specification, and would mean
>>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>>> those devices.
>>>
>>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>>
>> Yes, because we build v2 tables and they are somewhat different.
>
> So couldn't we switch to building v5 tables (or even v6) for PVH
> (and perhaps re-using the "acpi=" config setting to allow specifying a
> version - with any value above 1 indicating the requested version)? I
> certainly agree that setting a v5 flag in a v2 table is bad (best we can
> hope for is that any consumer would ignore such a flag).
FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the
ACPI building code with ARM.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-07 9:14 ` Julien Grall
@ 2016-07-07 9:20 ` Jan Beulich
2016-07-07 9:29 ` Julien Grall
0 siblings, 1 reply; 104+ messages in thread
From: Jan Beulich @ 2016-07-07 9:20 UTC (permalink / raw)
To: Julien Grall
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, zhaoshenglong,
Boris Ostrovsky, roger.pau
>>> On 07.07.16 at 11:14, <julien.grall@arm.com> wrote:
> On 07/07/16 09:35, Jan Beulich wrote:
>>>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>>>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
>>>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>>>> considering that we don't provide PM timer or RTC for example. Not setting
>>>> this would be a violation of the ACPI specification, and would mean
>>>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>>>> those devices.
>>>>
>>>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>>>
>>> Yes, because we build v2 tables and they are somewhat different.
>>
>> So couldn't we switch to building v5 tables (or even v6) for PVH
>> (and perhaps re-using the "acpi=" config setting to allow specifying a
>> version - with any value above 1 indicating the requested version)? I
>> certainly agree that setting a v5 flag in a v2 table is bad (best we can
>> hope for is that any consumer would ignore such a flag).
>
> FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the
> ACPI building code with ARM.
I don't think we can outright switch to v5 or newer on x86 - old
guests (say WinXP) may not be able to deal with that.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-07 9:20 ` Jan Beulich
@ 2016-07-07 9:29 ` Julien Grall
0 siblings, 0 replies; 104+ messages in thread
From: Julien Grall @ 2016-07-07 9:29 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, zhaoshenglong,
Boris Ostrovsky, roger.pau
On 07/07/16 10:20, Jan Beulich wrote:
>>>> On 07.07.16 at 11:14, <julien.grall@arm.com> wrote:
>> On 07/07/16 09:35, Jan Beulich wrote:
>>>>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
>>>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>>>>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>>>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
>>>>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>>>>> considering that we don't provide PM timer or RTC for example. Not setting
>>>>> this would be a violation of the ACPI specification, and would mean
>>>>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>>>>> those devices.
>>>>>
>>>>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>>>>
>>>> Yes, because we build v2 tables and they are somewhat different.
>>>
>>> So couldn't we switch to building v5 tables (or even v6) for PVH
>>> (and perhaps re-using the "acpi=" config setting to allow specifying a
>>> version - with any value above 1 indicating the requested version)? I
>>> certainly agree that setting a v5 flag in a v2 table is bad (best we can
>>> hope for is that any consumer would ignore such a flag).
>>
>> FWIW, if we switch to ACPI v5.1 or later, it will be easier to merge the
>> ACPI building code with ARM.
>
> I don't think we can outright switch to v5 or newer on x86 - old
> guests (say WinXP) may not be able to deal with that.
Right. I meant that if you add support for ACPI v5 (or later) for PVH.
It will also help to get a common ACPI build code with ARM.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-07 8:35 ` Jan Beulich
2016-07-07 9:14 ` Julien Grall
@ 2016-07-07 15:04 ` Boris Ostrovsky
2016-07-07 15:10 ` Jan Beulich
1 sibling, 1 reply; 104+ messages in thread
From: Boris Ostrovsky @ 2016-07-07 15:04 UTC (permalink / raw)
To: Jan Beulich, roger.pau
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong
On 07/07/2016 04:35 AM, Jan Beulich wrote:
>>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with ACPI v5
>>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>>> considering that we don't provide PM timer or RTC for example. Not setting
>>> this would be a violation of the ACPI specification, and would mean
>>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>>> those devices.
>>>
>>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>> Yes, because we build v2 tables and they are somewhat different.
> So couldn't we switch to building v5 tables (or even v6) for PVH
> (and perhaps re-using the "acpi=" config setting to allow specifying a
> version - with any value above 1 indicating the requested version)? I
> certainly agree that setting a v5 flag in a v2 table is bad (best we can
> hope for is that any consumer would ignore such a flag).
Hmm... I thought earlier that v2 and v5(+) tables are different but now
that I went back this doesn't seem to be the case. It's v1 vs v2 that
changed formats.
If that's the case (I'll check more carefully) then yes, we can provide
PVH guests with higher versions.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader
2016-07-07 15:04 ` Boris Ostrovsky
@ 2016-07-07 15:10 ` Jan Beulich
0 siblings, 0 replies; 104+ messages in thread
From: Jan Beulich @ 2016-07-07 15:10 UTC (permalink / raw)
To: roger.pau, Boris Ostrovsky
Cc: wei.liu2, andrew.cooper3, ian.jackson, xen-devel, julien.grall,
zhaoshenglong
>>> On 07.07.16 at 17:04, <boris.ostrovsky@oracle.com> wrote:
> On 07/07/2016 04:35 AM, Jan Beulich wrote:
>>>>> On 06.07.16 at 18:32, <boris.ostrovsky@oracle.com> wrote:
>>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
>>>> On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
>>>>> * Don't set HW_REDUCED_ACPI flags: this flag is only available starting with
> ACPI v5
>>>> Hm, I still think HW_REDUCED_ACPI should be set for the time being,
>>>> considering that we don't provide PM timer or RTC for example. Not setting
>>>> this would be a violation of the ACPI specification, and would mean
>>>> introducing Xen specific hacks yet again to guest OSes, in order to disable
>>>> those devices.
>>>>
>>>> Is the fact that HW_REDUCED_ACPI was introduced in ACPI v5 a problem?
>>> Yes, because we build v2 tables and they are somewhat different.
>> So couldn't we switch to building v5 tables (or even v6) for PVH
>> (and perhaps re-using the "acpi=" config setting to allow specifying a
>> version - with any value above 1 indicating the requested version)? I
>> certainly agree that setting a v5 flag in a v2 table is bad (best we can
>> hope for is that any consumer would ignore such a flag).
>
> Hmm... I thought earlier that v2 and v5(+) tables are different but now
> that I went back this doesn't seem to be the case. It's v1 vs v2 that
> changed formats.
Yeah, they didn't repeat that mistake again.
Jan
> If that's the case (I'll check more carefully) then yes, we can provide
> PVH guests with higher versions.
>
> -boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 104+ messages in thread