xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
@ 2016-04-06  1:25 Boris Ostrovsky
  2016-04-06  1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
                   ` (21 more replies)
  0 siblings, 22 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel; +Cc: Boris Ostrovsky, roger.pau

This is an RFC for making hvmloader's ACPI builder available to both the
toolstack and the hypervisor, as discussed in
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html

The series
* Removes dependency of today's builder on hvmloader interfaces
* Makes many of the tables built optionally.
* Moves tools/hvmloader/acpi directory to xen/common/libacpi
* Builds tables for PVHv2 domU guests in libxc

There is still a number of questions about this implementation, thus it's
an RFC. Examples of things that need to be discussed are

* ACPI tables are built for PVHv2 guests unconditionally. We probably want
  to make this an option.
* Not sure about header files, especially xen/common/libacpi/x86.h and 
  tools/firmware/hvmloader/{stdio.h,string.h} 
* The builder is compiled into the hypervisor even though currently
  there are no users (PVHv2 dom0 will be the one)
* Patch 19 is somewhat of a spec violation
* Makefiles are questionable
* May need changes to guests' e820 map

This is also available from git://oss.oracle.com/git/bostrovs/xen.git:acpi_rfc.

It has been tested with Linux PVHv2 (and I believe Roger tested an earlier
version with FreeBSD). No passthrough testing has been done.

(I realize that many people are busy because of Friday's freeze but I figured I'd
post it now in the hope that this may get some reading so that we can talk about
it at the hackathon)


Boris Ostrovsky (20):
  hvmloader: Provide hvmloader_acpi_build_tables()
  acpi/hvmloader: Move acpi_info initialization out of ACPI code
  acpi/hvmloader: Initialize vm_gid data outside ACPI code
  acpi/hvmloader: Decide which SSDTs to build in hvmloader
  acpi/hvmloader: Move passthrough initialization from ACPI code
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Provide address of acpi_info as an argument to ACPI
    code
  acpi/hvmloader: Translate all addresses when assigning addresses in
    ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Add stdio.h, string.h and x86.h
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  acpi: Move ACPI code to xen/common/libacpi
  x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic()
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libxc/acpi: Build ACPI tables for HVMlite guests
  acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  acpi: Make ACPI builder available to hypervisor code

 .gitignore                                         |   8 +-
 tools/firmware/hvmloader/Makefile                  |  16 +-
 tools/firmware/hvmloader/config.h                  |  13 +-
 tools/firmware/hvmloader/hvmloader.c               |   3 +-
 tools/firmware/hvmloader/mp_tables.c               |   1 +
 tools/firmware/hvmloader/ovmf.c                    |   4 +-
 tools/firmware/hvmloader/pci.c                     |   1 +
 tools/firmware/hvmloader/pir.c                     |   1 +
 tools/firmware/hvmloader/rombios.c                 |   4 +-
 tools/firmware/hvmloader/seabios.c                 |   4 +-
 tools/firmware/hvmloader/smbios.c                  |   1 +
 tools/firmware/hvmloader/smp.c                     |   1 +
 tools/firmware/hvmloader/stdio.h                   |   7 +
 tools/firmware/hvmloader/string.h                  |   7 +
 tools/firmware/hvmloader/util.c                    |  85 +++++
 tools/firmware/hvmloader/util.h                    |   6 +-
 tools/firmware/rombios/32bit/Makefile              |   2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile      |   2 +-
 tools/firmware/rombios/32bit/util.h                |   2 +-
 tools/libxc/Makefile                               |  22 +-
 tools/libxc/include/xc_dom.h                       |   1 +
 tools/libxc/xc_acpi.c                              | 268 +++++++++++++
 tools/libxc/xc_dom_x86.c                           |   7 +
 tools/libxl/libxl_x86.c                            |  19 +-
 xen/arch/x86/domain.c                              |  26 +-
 xen/arch/x86/hvm/vlapic.c                          |   3 +
 xen/common/Makefile                                |   2 +-
 .../hvmloader/acpi => xen/common/libacpi}/Makefile |  33 +-
 .../hvmloader/acpi => xen/common/libacpi}/README   |   0
 .../acpi => xen/common/libacpi}/acpi2_0.h          |  66 +++-
 .../hvmloader/acpi => xen/common/libacpi}/build.c  | 415 ++++++++++-----------
 .../hvmloader/acpi => xen/common/libacpi}/dsdt.asl |   0
 xen/common/libacpi/dsdt_empty.asl                  |  22 ++
 .../acpi => xen/common/libacpi}/mk_dsdt.c          |   4 +
 .../acpi => xen/common/libacpi}/ssdt_pm.asl        |   0
 .../acpi => xen/common/libacpi}/ssdt_s3.asl        |   0
 .../acpi => xen/common/libacpi}/ssdt_s4.asl        |   0
 .../acpi => xen/common/libacpi}/ssdt_tpm.asl       |   0
 .../acpi => xen/common/libacpi}/static_tables.c    |   1 -
 xen/common/libacpi/x86.h                           |  14 +
 40 files changed, 794 insertions(+), 277 deletions(-)
 create mode 100644 tools/firmware/hvmloader/stdio.h
 create mode 100644 tools/firmware/hvmloader/string.h
 create mode 100644 tools/libxc/xc_acpi.c
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile (70%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h (84%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c (58%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl (100%)
 create mode 100644 xen/common/libacpi/dsdt_empty.asl
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c (99%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/static_tables.c (99%)
 create mode 100644 xen/common/libacpi/x86.h

-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 12:42   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
                   ` (20 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 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__ */
 
 /*
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
  2016-04-06  1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 12:54   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
                   ` (19 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h | 18 ++++++++++++++
 tools/firmware/hvmloader/acpi/build.c   | 44 ++++++---------------------------
 tools/firmware/hvmloader/util.c         | 15 +++++++++++
 3 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 78eb43d..24f86c9 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -451,11 +451,29 @@ struct acpi_20_slit {
 
 #pragma pack ()
 
+/*
+ * 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? */
+    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 {
     unsigned char *dsdt_anycpu;
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    struct acpi_info acpi_info;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 503648c..e039d9e 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -38,23 +38,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? */
-    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 */
-};
-
 /* Number of processor objects in the chosen DSDT. */
 static unsigned int nr_processor_objects;
 
@@ -360,7 +343,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;
@@ -497,7 +480,6 @@ static int new_vm_gid(struct acpi_info *acpi_info)
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
-    struct acpi_info *acpi_info;
     struct acpi_20_rsdp *rsdp;
     struct acpi_20_rsdt *rsdt;
     struct acpi_20_xsdt *xsdt;
@@ -508,11 +490,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.
      */
@@ -574,7 +551,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->acpi_info);
     if ( nr_secondaries < 0 )
         goto oom;
 
@@ -619,20 +597,12 @@ 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->acpi_info) )
         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;
-    }
+    memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
+           &config->acpi_info,
+           sizeof(config->acpi_info));
 
     return;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9af29b1..7ce5f5d 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -860,6 +860,21 @@ int hpet_exists(unsigned long hpet_base)
 void hvmloader_acpi_build_tables(struct acpi_config *config,
                                  unsigned int physical)
 {
+    /* Allocate and initialise the acpi info area. */
+    mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
+
+    config->acpi_info.com1_present = uart_exists(0x3f8);
+    config->acpi_info.com2_present = uart_exists(0x2f8);
+    config->acpi_info.lpt1_present = lpt_exists(0x378);
+    config->acpi_info.hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
+    config->acpi_info.pci_min = pci_mem_start;
+    config->acpi_info.pci_len = pci_mem_end - pci_mem_start;
+    if ( pci_hi_mem_end > pci_hi_mem_start )
+    {
+        config->acpi_info.pci_hi_min = pci_hi_mem_start;
+        config->acpi_info.pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
+    }
+
     acpi_build_tables(config, physical);
 }
 
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
  2016-04-06  1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
  2016-04-06  1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 13:03   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
                   ` (18 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |  1 +
 tools/firmware/hvmloader/acpi/build.c   | 30 +++++++++++-------------------
 tools/firmware/hvmloader/util.c         | 15 +++++++++++++++
 3 files changed, 27 insertions(+), 19 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 24f86c9..275981e 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -474,6 +474,7 @@ struct acpi_config {
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
     struct acpi_info acpi_info;
+    uint64_t vm_gid[2];
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index e039d9e..e3e8b05 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -448,32 +448,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->acpi_info.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->acpi_info.vm_gid_addr = virt_to_phys(buf);
 
     return 1;
 }
@@ -597,7 +589,7 @@ 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(&config->acpi_info) )
+    if ( !new_vm_gid(config) )
         goto oom;
 
     memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 7ce5f5d..e4c188c 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -26,6 +26,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.
@@ -860,6 +861,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);
 
@@ -875,7 +878,19 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
         config->acpi_info.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);
+    }
+
     acpi_build_tables(config, physical);
+
+    hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->acpi_info.vm_gid_addr);
 }
 
 /*
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (2 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 13:07   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
                   ` (17 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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/acpi2_0.h |  6 ++++++
 tools/firmware/hvmloader/acpi/build.c   | 20 +++++++-------------
 tools/firmware/hvmloader/util.c         | 12 ++++++++++++
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 275981e..1ed0d44 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -451,6 +451,11 @@ struct acpi_20_slit {
 
 #pragma pack ()
 
+/* 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)
+
 /*
  * Located at ACPI_INFO_PHYSICAL_ADDRESS.
  *
@@ -475,6 +480,7 @@ struct acpi_config {
     int dsdt_15cpu_len;
     struct acpi_info acpi_info;
     uint64_t vm_gid[2];
+    uint32_t table_flags;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index e3e8b05..9f45f26 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -56,11 +56,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;
@@ -322,7 +317,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;
@@ -337,13 +332,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->acpi_info);
         if (!madt) return -1;
         table_ptrs[nr_tables++] = (unsigned long)madt;
     }
 
     /* HPET. */
-    if ( info->hpet_present )
+    if ( config->acpi_info.hpet_present )
     {
         hpet = construct_hpet();
         if (!hpet) return -1;
@@ -355,7 +350,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;
@@ -363,7 +358,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;
@@ -373,7 +368,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;
@@ -543,8 +538,7 @@ 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,
-                                                &config->acpi_info);
+    nr_secondaries = construct_secondary_tables(secondary_tables, config);
     if ( nr_secondaries < 0 )
         goto oom;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index e4c188c..54261ae 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -858,6 +858,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)
 {
@@ -888,6 +893,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;
+
     acpi_build_tables(config, physical);
 
     hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->acpi_info.vm_gid_addr);
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (3 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 13:52   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
                   ` (16 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

Initiale it in hvmloader, avoiding ACPI code's use of xenstore_read()

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |  4 ++++
 tools/firmware/hvmloader/acpi/build.c   | 22 +++++++---------------
 tools/firmware/hvmloader/util.c         | 10 ++++++++++
 3 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 1ed0d44..2617762 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -481,6 +481,10 @@ struct acpi_config {
     struct acpi_info acpi_info;
     uint64_t vm_gid[2];
     uint32_t table_flags;
+    struct {
+        unsigned long acpi_pt_addr;
+        uint32_t acpi_pt_length;
+    } pt;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 9f45f26..8a05c7c 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -271,10 +271,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;
@@ -282,19 +282,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.acpi_pt_addr == 0 )
         return 0;
 
-    acpi_pt_length = (uint32_t)strtoll(s, NULL, 0);
+    acpi_pt_addr = config->pt.acpi_pt_addr;
+    acpi_pt_length = config->pt.acpi_pt_length;
 
     for ( nr_added = 0; nr_added < nr_max; nr_added++ )
     {        
@@ -430,7 +422,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/util.c b/tools/firmware/hvmloader/util.c
index 54261ae..230e14a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -26,6 +26,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>
 
 /*
@@ -893,6 +894,15 @@ 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.acpi_pt_addr = strtoll(s, NULL, 0);
+
+        s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
+        if ( s  )
+            config->pt.acpi_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)  )
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (4 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 14:05   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
                   ` (15 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

No need for ACPI code to rely on hvm_info.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h | 13 +++++++++
 tools/firmware/hvmloader/acpi/build.c   | 49 +++++++++++++++++----------------
 tools/firmware/hvmloader/util.c         | 11 ++++++++
 3 files changed, 49 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 2617762..c52315a 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -20,6 +20,7 @@
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/hvm/ioreq.h>
+#include <xen/memory.h>
 
 #define ASCII32(a,b,c,d)         \
     (((a) <<  0) | ((b) <<  8) | ((c) << 16) | ((d) << 24))
@@ -473,6 +474,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 {
     unsigned char *dsdt_anycpu;
     int dsdt_anycpu_len;
@@ -485,6 +494,10 @@ struct acpi_config {
         unsigned long acpi_pt_addr;
         uint32_t acpi_pt_length;
     } pt;
+    uint32_t nr_vcpus;
+    uint8_t  *vcpu_online;
+    int apic_mode;
+    struct acpi_numa numa;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 8a05c7c..1bccca3 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -56,7 +56,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;
@@ -120,7 +120,7 @@ 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->madt_lapic0_addr = (uint32_t)lapic;
+    config->acpi_info.madt_lapic0_addr = (uint32_t)lapic;
     for ( i = 0; i < nr_processor_objects; i++ )
     {
         memset(lapic, 0, sizeof(*lapic));
@@ -129,8 +129,8 @@ 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 = ((i < hvm_info->nr_vcpus) &&
-                        test_bit(i, hvm_info->vcpu_online)
+        lapic->flags = ((i < config->nr_vcpus) &&
+                        test_bit(i, config->vcpu_online)
                         ? ACPI_LOCAL_APIC_ENABLED : 0);
         lapic++;
     }
@@ -138,7 +138,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->acpi_info.madt_csum_addr = (uint32_t)&madt->header.checksum;
 
     return madt;
 }
@@ -181,7 +181,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;
@@ -190,8 +190,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->nr_vcpus +
+           sizeof(*memory) * config->numa.nr_vmemranges;
 
     p = mem_alloc(size, 16);
     if ( !p )
@@ -208,25 +208,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->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++;
     }
 
@@ -238,12 +239,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);
@@ -260,9 +261,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);
@@ -322,9 +323,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->nr_vcpus > 1) || config->apic_mode )
     {
-        madt = construct_madt(&config->acpi_info);
+        madt = construct_madt(config);
         if (!madt) return -1;
         table_ptrs[nr_tables++] = (unsigned long)madt;
     }
@@ -406,10 +407,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;
@@ -485,7 +486,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
      * 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->nr_vcpus <= 15 && config->dsdt_15cpu)
     {
         dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
         if (!dsdt) goto oom;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 230e14a..b56f4e6 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 <stdint.h>
 #include <xen/xen.h>
@@ -910,6 +911,16 @@ 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->nr_vcpus = hvm_info->nr_vcpus;
+    config->vcpu_online = hvm_info->vcpu_online;
+    config->apic_mode = 1;
+
+    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;
+
     acpi_build_tables(config, physical);
 
     hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->acpi_info.vm_gid_addr);
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address in hvmloader
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (5 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 14:09   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
                   ` (14 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |  4 ++
 tools/firmware/hvmloader/acpi/build.c   | 65 +++++++++++++++++----------------
 tools/firmware/hvmloader/util.c         |  4 ++
 3 files changed, 41 insertions(+), 32 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index c52315a..2628a2f 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -304,6 +304,8 @@ struct acpi_20_waet {
     uint32_t           flags;
 };
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 /*
  * Multiple APIC Flags.
  */
@@ -456,6 +458,7 @@ struct acpi_20_slit {
 #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)
 
 /*
  * Located at ACPI_INFO_PHYSICAL_ADDRESS.
@@ -498,6 +501,7 @@ struct acpi_config {
     uint8_t  *vcpu_online;
     int apic_mode;
     struct acpi_numa numa;
+    uint16_t *tis_hdr;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 1bccca3..c56a6a6 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -319,7 +319,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. */
@@ -371,41 +370,43 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         printf("S4 disabled\n");
     }
 
-    /* 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 )
     {
-        ssdt = mem_alloc(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);
-        if (!tcpa) return -1;
-        memset(tcpa, 0, sizeof(*tcpa));
-        table_ptrs[nr_tables++] = (unsigned long)tcpa;
-
-        tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
-        tcpa->header.length    = sizeof(*tcpa);
-        tcpa->header.revision  = ACPI_2_0_TCPA_REVISION;
-        fixed_strcpy(tcpa->header.oem_id, ACPI_OEM_ID);
-        fixed_strcpy(tcpa->header.oem_table_id, ACPI_OEM_TABLE_ID);
-        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 )
+        /* TPM TCPA and SSDT. */
+        if ( (config->tis_hdr[0] == tis_signature[0]) &&
+             (config->tis_hdr[1] == tis_signature[1]) &&
+             (config->tis_hdr[2] == tis_signature[2]) )
         {
-            tcpa->lasa = virt_to_phys(lasa);
-            tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
-            memset(lasa, 0, tcpa->laml);
-            set_checksum(tcpa,
-                         offsetof(struct acpi_header, checksum),
-                         tcpa->header.length);
+            ssdt = mem_alloc(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);
+            if (!tcpa) return -1;
+            memset(tcpa, 0, sizeof(*tcpa));
+            table_ptrs[nr_tables++] = (unsigned long)tcpa;
+
+            tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
+            tcpa->header.length    = sizeof(*tcpa);
+            tcpa->header.revision  = ACPI_2_0_TCPA_REVISION;
+            fixed_strcpy(tcpa->header.oem_id, ACPI_OEM_ID);
+            fixed_strcpy(tcpa->header.oem_table_id, ACPI_OEM_TABLE_ID);
+            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 )
+            {
+                tcpa->lasa = virt_to_phys(lasa);
+                tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
+                memset(lasa, 0, tcpa->laml);
+                set_checksum(tcpa,
+                             offsetof(struct acpi_header, checksum),
+                             tcpa->header.length);
+            }
         }
     }
-
+    
     /* SRAT and SLIT */
     if ( config->numa.nr_vnodes > 0 )
     {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index b56f4e6..ce74fe2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -911,6 +911,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;
+
     config->nr_vcpus = hvm_info->nr_vcpus;
     config->vcpu_online = hvm_info->vcpu_online;
     config->apic_mode = 1;
@@ -921,6 +923,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
     config->numa.vdistance = vdistance;
     config->numa.vmemrange = vmemrange;
 
+    config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
     acpi_build_tables(config, physical);
 
     hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->acpi_info.vm_gid_addr);
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (6 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-04-06  1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
                   ` (13 subsequent siblings)
  21 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |  1 +
 tools/firmware/hvmloader/acpi/build.c   | 68 ++++++++++++++++++---------------
 tools/firmware/hvmloader/util.c         |  2 +-
 3 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 2628a2f..6c762e0 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -459,6 +459,7 @@ struct acpi_20_slit {
 #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)
 
 /*
  * Located at ACPI_INFO_PHYSICAL_ADDRESS.
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index c56a6a6..08cf78b 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -83,43 +83,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->acpi_info.madt_lapic0_addr = (uint32_t)lapic;
     for ( i = 0; i < nr_processor_objects; i++ )
     {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index ce74fe2..982d023 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -911,7 +911,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->nr_vcpus = hvm_info->nr_vcpus;
     config->vcpu_online = hvm_info->vcpu_online;
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (7 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 14:32   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
                   ` (12 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h | 1 +
 tools/firmware/hvmloader/acpi/build.c   | 9 ++++++---
 tools/firmware/hvmloader/util.c         | 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 6c762e0..cf707b8 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -460,6 +460,7 @@ struct acpi_20_slit {
 #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)
 
 /*
  * Located at ACPI_INFO_PHYSICAL_ADDRESS.
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 08cf78b..2bf89e4 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -344,9 +344,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/util.c b/tools/firmware/hvmloader/util.c
index 982d023..c2145f6 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -911,7 +911,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->nr_vcpus = hvm_info->nr_vcpus;
     config->vcpu_online = hvm_info->vcpu_online;
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (8 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-03 16:03   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
                   ` (11 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

Some users of ACPI builder may be building tables in virtual address space.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h | 4 ++++
 tools/firmware/hvmloader/acpi/build.c   | 3 +--
 tools/firmware/hvmloader/config.h       | 3 +--
 tools/firmware/hvmloader/util.c         | 1 +
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index cf707b8..0bfd3ed 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -306,6 +306,9 @@ struct acpi_20_waet {
 
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
+/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
+#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000UL
+
 /*
  * Multiple APIC Flags.
  */
@@ -504,6 +507,7 @@ struct acpi_config {
     int apic_mode;
     struct acpi_numa numa;
     uint16_t *tis_hdr;
+    void *acpi_info_page;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 2bf89e4..991a73f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -589,8 +589,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     if ( !new_vm_gid(config) )
         goto oom;
 
-    memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
-           &config->acpi_info,
+    memcpy(config->acpi_info_page, &config->acpi_info,
            sizeof(config->acpi_info));
 
     return;
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index b838cf9..6253155 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -65,8 +65,7 @@ extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 #define HVMLOADER_PHYSICAL_ADDRESS    0x00100000
 /* Special BIOS mappings, etc. are allocated from here upwards... */
 #define RESERVED_MEMBASE              0xFC000000
-/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
-#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
+
 #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
 #define RESERVED_MEMORY_DYNAMIC_END   0xFE000000
 /*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index c2145f6..d099adb 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -925,6 +925,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
     config->numa.vmemrange = vmemrange;
 
     config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+    config->acpi_info_page = (void *)ACPI_INFO_PHYSICAL_ADDRESS;
 
     acpi_build_tables(config, physical);
 
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (9 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 10:48   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
                   ` (10 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 991a73f..941dd0b 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_config *config)
     else
         lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-    config->acpi_info.madt_lapic0_addr = (uint32_t)lapic;
+    config->acpi_info.madt_lapic0_addr = virt_to_phys(lapic);
     for ( i = 0; i < nr_processor_objects; i++ )
     {
         memset(lapic, 0, sizeof(*lapic));
@@ -144,7 +144,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
     madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
     set_checksum(madt, offsetof(struct acpi_header, checksum),
                  madt->header.length);
-    config->acpi_info.madt_csum_addr = (uint32_t)&madt->header.checksum;
+    config->acpi_info.madt_csum_addr =
+        virt_to_phys(&madt->header.checksum);
 
     return madt;
 }
@@ -307,7 +308,7 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
             break;
         memcpy(buffer, header, header->length);
 
-        table_ptrs[nr_tables++] = (unsigned long)buffer;
+        table_ptrs[nr_tables++] = virt_to_phys(buffer);
         total += header->length;
         acpi_pt_addr += header->length;
     }
@@ -332,7 +333,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     {
         madt = construct_madt(config);
         if (!madt) return -1;
-        table_ptrs[nr_tables++] = (unsigned long)madt;
+        table_ptrs[nr_tables++] = virt_to_phys(madt);
     }
 
     /* HPET. */
@@ -340,7 +341,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     {
         hpet = construct_hpet();
         if (!hpet) return -1;
-        table_ptrs[nr_tables++] = (unsigned long)hpet;
+        table_ptrs[nr_tables++] = virt_to_phys(hpet);
     }
 
     /* WAET. */
@@ -348,7 +349,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     {
         waet = construct_waet();
         if (!waet) return -1;
-        table_ptrs[nr_tables++] = (unsigned long)waet;
+        table_ptrs[nr_tables++] = virt_to_phys(waet);
     }
 
     if ( config->table_flags & ACPI_BUILD_SSDT_PM )
@@ -356,7 +357,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         ssdt = mem_alloc(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++] = virt_to_phys(ssdt);
     }
 
     if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
@@ -364,7 +365,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         ssdt = mem_alloc(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++] = virt_to_phys(ssdt);
     } else {
         printf("S3 disabled\n");
     }
@@ -374,7 +375,7 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         ssdt = mem_alloc(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++] = virt_to_phys(ssdt);
     } else {
         printf("S4 disabled\n");
     }
@@ -389,12 +390,12 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
             ssdt = mem_alloc(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++] = virt_to_phys(ssdt);
 
             tcpa = mem_alloc(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++] = virt_to_phys(tcpa);
 
             tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
             tcpa->header.length    = sizeof(*tcpa);
@@ -423,11 +424,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         struct acpi_20_slit *slit = construct_slit(config);
 
         if ( srat )
-            table_ptrs[nr_tables++] = (unsigned long)srat;
+            table_ptrs[nr_tables++] = virt_to_phys(srat);
         else
             printf("Failed to build SRAT, skipping...\n");
         if ( slit )
-            table_ptrs[nr_tables++] = (unsigned long)slit;
+            table_ptrs[nr_tables++] = virt_to_phys(slit);
         else
             printf("Failed to build SLIT, skipping...\n");
     }
@@ -524,8 +525,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     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          = virt_to_phys(dsdt);
+    fadt_10->firmware_ctrl = virt_to_phys(facs);
     set_checksum(fadt_10,
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_10_fadt));
@@ -533,10 +534,10 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     fadt = mem_alloc(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   = virt_to_phys(dsdt);
+    fadt->x_dsdt = virt_to_phys(dsdt);
+    fadt->firmware_ctrl   = virt_to_phys(facs);
+    fadt->x_firmware_ctrl = virt_to_phys(facs);
     set_checksum(fadt,
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
@@ -550,7 +551,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                      16);
     if (!xsdt) goto oom;
     memcpy(xsdt, &Xsdt, sizeof(struct acpi_header));
-    xsdt->entry[0] = (unsigned long)fadt;
+    xsdt->entry[0] = virt_to_phys(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);
@@ -563,7 +564,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                      16);
     if (!rsdt) goto oom;
     memcpy(rsdt, &Rsdt, sizeof(struct acpi_header));
-    rsdt->entry[0] = (unsigned long)fadt_10;
+    rsdt->entry[0] = virt_to_phys(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);
@@ -577,8 +578,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     rsdp = (struct acpi_20_rsdp *)physical;
 
     memcpy(rsdp, &Rsdp, sizeof(struct acpi_20_rsdp));
-    rsdp->rsdt_address = (unsigned long)rsdt;
-    rsdp->xsdt_address = (unsigned long)xsdt;
+    rsdp->rsdt_address = virt_to_phys(rsdt);
+    rsdp->xsdt_address = virt_to_phys(xsdt);
     set_checksum(rsdp,
                  offsetof(struct acpi_10_rsdp, checksum),
                  sizeof(struct acpi_10_rsdp));
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (10 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 11:04   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
                   ` (9 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, Boris Ostrovsky, roger.pau

ACPI sources will be available to various component which will build
them according to their own rules. ACPI directory will only build
sources.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/Makefile             | 17 ++++++++++++++---
 tools/firmware/hvmloader/acpi/Makefile        |  9 ++-------
 tools/firmware/hvmloader/hvmloader.c          |  2 +-
 tools/firmware/hvmloader/ovmf.c               |  2 +-
 tools/firmware/hvmloader/rombios.c            |  2 +-
 tools/firmware/hvmloader/seabios.c            |  2 +-
 tools/firmware/hvmloader/util.c               |  2 +-
 tools/firmware/rombios/32bit/Makefile         |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile |  2 +-
 tools/firmware/rombios/32bit/util.h           |  2 +-
 10 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index f2f4791..ef66019 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,8 +20,6 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-SUBDIRS := acpi
-
 # The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x100000
 
@@ -33,10 +31,18 @@ CFLAGS += $(CFLAGS_xeninclude)
 # We mustn't use tools-only public interfaces.
 CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
 
+# ACPI table builder
+ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+vpath %.c $(ACPI_PATH)
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c static_tables.c dsdt_anycpu_qemu_xen.c build.c
+ACPI_SRC = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
+CFLAGS += -I$(ACPI_PATH)
+
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
+OBJS += $(patsubst %.c,%.o,$(ACPI_FILES))
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
@@ -95,7 +101,11 @@ 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
+.NOTPARALLEL: $(ACPI_SRC)
+$(ACPI_SRC):
+	$(MAKE) -C $(ACPI_PATH)
+
+hvmloader: $(OBJS)
 	$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
 	$(OBJCOPY) hvmloader.tmp hvmloader
 	rm -f hvmloader.tmp
@@ -143,6 +153,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) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..4d84e4c 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -23,7 +23,7 @@ OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 CFLAGS += $(CFLAGS_xeninclude)
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
@@ -56,13 +56,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 *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
 	rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
 
 distclean: clean
diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 716d03c..c8311a1 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -24,7 +24,7 @@
 #include "config.h"
 #include "pci_regs.h"
 #include "apic_regs.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
 #include "vnuma.h"
 #include <xen/version.h>
 #include <xen/hvm/params.h>
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/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 9f66a79..5184275 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -25,7 +25,7 @@
 #include "util.h"
 
 #include "smbios_types.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
 
 #define ROM_INCLUDE_SEABIOS
 #include "roms.inc"
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d099adb..a21d3cb 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,7 +22,7 @@
 #include "hypercall.h"
 #include "ctype.h"
 #include "vnuma.h"
-#include "acpi/acpi2_0.h"
+#include "acpi2_0.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
diff --git a/tools/firmware/rombios/32bit/Makefile b/tools/firmware/rombios/32bit/Makefile
index 396906c..9b523bd 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET = 32bitbios_flat.h
 
-CFLAGS += $(CFLAGS_xeninclude) -I..
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I$(XEN_ROOT)/tools/firmware/hvmloader/acpi/
 
 SUBDIRS = tcgbios
 
diff --git a/tools/firmware/rombios/32bit/tcgbios/Makefile b/tools/firmware/rombios/32bit/tcgbios/Makefile
index f6f2649..6555028 100644
--- a/tools/firmware/rombios/32bit/tcgbios/Makefile
+++ b/tools/firmware/rombios/32bit/tcgbios/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET  = tcgbiosext.o
 
-CFLAGS += $(CFLAGS_xeninclude) -I.. -I../..
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I../.. -I$(XEN_ROOT)/tools/firmware/hvmloader/acpi/
 
 .PHONY: all
 all: $(TARGET)
diff --git a/tools/firmware/rombios/32bit/util.h b/tools/firmware/rombios/32bit/util.h
index e245be6..8f8ab35 100644
--- a/tools/firmware/rombios/32bit/util.h
+++ b/tools/firmware/rombios/32bit/util.h
@@ -1,7 +1,7 @@
 #ifndef UTIL_H
 #define UTIL_H
 
-#include "../hvmloader/acpi/acpi2_0.h"
+#include "acpi2_0.h"
 
 void outb(uint16_t addr, uint8_t val);
 void outw(uint16_t addr, uint16_t val);
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (11 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 11:31   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
                   ` (8 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Boris Ostrovsky, Stefano Stabellini, Wei Liu, roger.pau

Users of ACPI builder will need to provide their own implemetations of
strncpy(), memcpy, memset() and printf declared in stdio.h and string.h.
For hvmloader we provide those two as wrappers around utul.h.

Some x86-specific definitions move to ACPI builder's x86.h file so that
users won't have to re-define them themselves.

Explicitly define a few things that are currently available to to build.c
via util.h.

Remove unnecessary #include "../config.h" from static_tables.c

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/firmware/hvmloader/Makefile             |  2 +-
 tools/firmware/hvmloader/acpi/build.c         | 23 +++++++++++++++++------
 tools/firmware/hvmloader/acpi/static_tables.c |  1 -
 tools/firmware/hvmloader/acpi/x86.h           | 14 ++++++++++++++
 tools/firmware/hvmloader/config.h             | 10 ----------
 tools/firmware/hvmloader/hvmloader.c          |  1 +
 tools/firmware/hvmloader/mp_tables.c          |  1 +
 tools/firmware/hvmloader/pci.c                |  1 +
 tools/firmware/hvmloader/pir.c                |  1 +
 tools/firmware/hvmloader/smp.c                |  1 +
 tools/firmware/hvmloader/stdio.h              |  7 +++++++
 tools/firmware/hvmloader/string.h             |  7 +++++++
 tools/firmware/hvmloader/util.c               |  1 +
 13 files changed, 52 insertions(+), 18 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/x86.h
 create mode 100644 tools/firmware/hvmloader/stdio.h
 create mode 100644 tools/firmware/hvmloader/string.h

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index ef66019..c778174 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -36,7 +36,7 @@ ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
 vpath %.c $(ACPI_PATH)
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c static_tables.c dsdt_anycpu_qemu_xen.c build.c
 ACPI_SRC = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
-CFLAGS += -I$(ACPI_PATH)
+CFLAGS += -I$(ACPI_PATH) -I.
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += smp.o cacheattr.o xenbus.o vnuma.o
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 941dd0b..09c1ed3 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -15,14 +15,16 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <stdio.h>
+#include <string.h>
+
 #include "acpi2_0.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_info_table.h>
 #include <xen/hvm/hvm_xs_strings.h>
 #include <xen/hvm/params.h>
 
@@ -30,6 +32,12 @@
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
+#ifndef offsetof
+#define offsetof(t, m) ((unsigned long)&((t *)0)->m)
+#endif
+#ifndef NULL
+#define NULL ((void *)0)
+#endif
 
 extern struct acpi_20_rsdp Rsdp;
 extern struct acpi_20_rsdt Rsdt;
@@ -41,6 +49,11 @@ extern struct acpi_20_waet Waet;
 /* Number of processor objects in the chosen DSDT. */
 static unsigned int nr_processor_objects;
 
+static inline int __test_bit(unsigned int b, void *p)
+{
+    return !!(((uint8_t *)p)[b>>3] & (1u<<(b&7)));
+}
+
 static void set_checksum(
     void *table, uint32_t checksum_offset, uint32_t length)
 {
@@ -136,7 +149,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
         lapic->acpi_processor_id = i;
         lapic->apic_id = LAPIC_ID(i);
         lapic->flags = ((i < config->nr_vcpus) &&
-                        test_bit(i, config->vcpu_online)
+                        __test_bit(i, config->vcpu_online)
                         ? ACPI_LOCAL_APIC_ENABLED : 0);
         lapic++;
     }
@@ -238,8 +251,6 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
         memory++;
     }
 
-    ASSERT(((unsigned long)memory) - ((unsigned long)p) == size);
-
     srat->header.length = size;
     set_checksum(srat, offsetof(struct acpi_header, checksum), size);
 
diff --git a/tools/firmware/hvmloader/acpi/static_tables.c b/tools/firmware/hvmloader/acpi/static_tables.c
index f4d627b..d4db030 100644
--- a/tools/firmware/hvmloader/acpi/static_tables.c
+++ b/tools/firmware/hvmloader/acpi/static_tables.c
@@ -16,7 +16,6 @@
  */
 
 #include "acpi2_0.h"
-#include "../config.h"
 
 /*
  * Firmware ACPI Control Structure (FACS).
diff --git a/tools/firmware/hvmloader/acpi/x86.h b/tools/firmware/hvmloader/acpi/x86.h
new file mode 100644
index 0000000..99a2d5c
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/x86.h
@@ -0,0 +1,14 @@
+#ifndef __ACPI_X86_H__
+#define __ACPI_X86_H__
+
+#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 */
+
+#endif /* __ACPI_X86_H__ */
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 6253155..9d1eacb 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -42,16 +42,6 @@ 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 c8311a1..5fe8007 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -24,6 +24,7 @@
 #include "config.h"
 #include "pci_regs.h"
 #include "apic_regs.h"
+#include "x86.h"
 #include "acpi2_0.h"
 #include "vnuma.h"
 #include <xen/version.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/pci.c b/tools/firmware/hvmloader/pci.c
index 4eb1a31..1813ffa 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -22,6 +22,7 @@
 #include "util.h"
 #include "hypercall.h"
 #include "config.h"
+#include "x86.h"
 #include "pci_regs.h"
 
 #include <xen/memory.h>
diff --git a/tools/firmware/hvmloader/pir.c b/tools/firmware/hvmloader/pir.c
index cc420dd..d238a14 100644
--- a/tools/firmware/hvmloader/pir.c
+++ b/tools/firmware/hvmloader/pir.c
@@ -14,6 +14,7 @@
  */
 
 #include "config.h"
+#include "x86.h"
 #include "pir_types.h"
 #include "util.h"
 
diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
index 082b17f..ae309b3 100644
--- a/tools/firmware/hvmloader/smp.c
+++ b/tools/firmware/hvmloader/smp.c
@@ -21,6 +21,7 @@
 
 #include "util.h"
 #include "config.h"
+#include "x86.h"
 #include "apic_regs.h"
 
 #define AP_BOOT_EIP 0x1000
diff --git a/tools/firmware/hvmloader/stdio.h b/tools/firmware/hvmloader/stdio.h
new file mode 100644
index 0000000..6475ce8
--- /dev/null
+++ b/tools/firmware/hvmloader/stdio.h
@@ -0,0 +1,7 @@
+#ifndef __HVMLOADER_STDIO_H_
+#define __HVMLOADER_STDIO_H_
+
+/* Declaration for printf */
+#include "util.h"
+
+#endif
diff --git a/tools/firmware/hvmloader/string.h b/tools/firmware/hvmloader/string.h
new file mode 100644
index 0000000..a6085e2
--- /dev/null
+++ b/tools/firmware/hvmloader/string.h
@@ -0,0 +1,7 @@
+#ifndef __HVMLOADER_STRING_H_
+#define __HVMLOADER_STRING_H_
+
+/* Declarations for memset, memcpy, strcpy */
+#include "util.h"
+
+#endif
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index a21d3cb..c111f61 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,6 +22,7 @@
 #include "hypercall.h"
 #include "ctype.h"
 #include "vnuma.h"
+#include "x86.h"
 #include "acpi2_0.h"
 #include <stdint.h>
 #include <xen/xen.h>
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (12 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 12:58   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
                   ` (7 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	Jan Beulich, Wei Liu, 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>
---
 tools/firmware/hvmloader/acpi/acpi2_0.h |   6 ++
 tools/firmware/hvmloader/acpi/build.c   | 104 +++++++++++++++++---------------
 tools/firmware/hvmloader/util.c         |   8 +++
 tools/firmware/hvmloader/util.h         |   2 +-
 4 files changed, 70 insertions(+), 50 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 0bfd3ed..0525a1e 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -490,6 +490,11 @@ struct acpi_numa {
     xen_vmemrange_t *vmemrange;
 };
 
+struct acpi_mem_ops {
+    void *(*alloc)(uint32_t size, uint32_t align);
+    unsigned long (*v2p)(void *v);
+};
+
 struct acpi_config {
     unsigned char *dsdt_anycpu;
     int dsdt_anycpu_len;
@@ -508,6 +513,7 @@ struct acpi_config {
     struct acpi_numa numa;
     uint16_t *tis_hdr;
     void *acpi_info_page;
+    struct acpi_mem_ops mem_ops;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/firmware/hvmloader/acpi/build.c
index 09c1ed3..eb8c632 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -82,7 +82,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) * nr_processor_objects;
 
-    madt = mem_alloc(sz, 16);
+    madt = config->mem_ops.alloc(sz, 16);
     if (!madt) return NULL;
 
     memset(madt, 0, sizeof(*madt));
@@ -139,7 +139,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
     else
         lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-    config->acpi_info.madt_lapic0_addr = virt_to_phys(lapic);
+    config->acpi_info.madt_lapic0_addr = config->mem_ops.v2p(lapic);
     for ( i = 0; i < nr_processor_objects; i++ )
     {
         memset(lapic, 0, sizeof(*lapic));
@@ -158,16 +158,16 @@ static struct acpi_20_madt *construct_madt(struct acpi_config *config)
     set_checksum(madt, offsetof(struct acpi_header, checksum),
                  madt->header.length);
     config->acpi_info.madt_csum_addr =
-        virt_to_phys(&madt->header.checksum);
+        config->mem_ops.v2p(&madt->header.checksum);
 
     return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_config *config)
 {
     struct acpi_20_hpet *hpet;
 
-    hpet = mem_alloc(sizeof(*hpet), 16);
+    hpet = config->mem_ops.alloc(sizeof(*hpet), 16);
     if (!hpet) return NULL;
 
     memset(hpet, 0, sizeof(*hpet));
@@ -186,11 +186,11 @@ 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_config *config)
 {
     struct acpi_20_waet *waet;
 
-    waet = mem_alloc(sizeof(*waet), 16);
+    waet = config->mem_ops.alloc(sizeof(*waet), 16);
     if (!waet) return NULL;
 
     memcpy(waet, &Waet, sizeof(*waet));
@@ -213,7 +213,7 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
     size = sizeof(*srat) + sizeof(*processor) * config->nr_vcpus +
            sizeof(*memory) * config->numa.nr_vmemranges;
 
-    p = mem_alloc(size, 16);
+    p = config->mem_ops.alloc(size, 16);
     if ( !p )
         return NULL;
 
@@ -265,7 +265,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 = config->mem_ops.alloc(size, 16);
     if ( !slit )
         return NULL;
 
@@ -314,12 +314,12 @@ static int construct_passthrough_tables(unsigned long *table_ptrs,
 
         header = (struct acpi_header*)acpi_pt_addr;
 
-        buffer = mem_alloc(header->length, 16);
+        buffer = config->mem_ops.alloc(header->length, 16);
         if ( buffer == NULL )
             break;
         memcpy(buffer, header, header->length);
 
-        table_ptrs[nr_tables++] = virt_to_phys(buffer);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(buffer);
         total += header->length;
         acpi_pt_addr += header->length;
     }
@@ -344,49 +344,49 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
     {
         madt = construct_madt(config);
         if (!madt) return -1;
-        table_ptrs[nr_tables++] = virt_to_phys(madt);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(madt);
     }
 
     /* HPET. */
     if ( config->acpi_info.hpet_present )
     {
-        hpet = construct_hpet();
+        hpet = construct_hpet(config);
         if (!hpet) return -1;
-        table_ptrs[nr_tables++] = virt_to_phys(hpet);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(hpet);
     }
 
     /* WAET. */
     if ( config->table_flags & ACPI_BUILD_WAET )
     {
-        waet = construct_waet();
+        waet = construct_waet(config);
         if (!waet) return -1;
-        table_ptrs[nr_tables++] = virt_to_phys(waet);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(waet);
     }
 
     if ( config->table_flags & ACPI_BUILD_SSDT_PM )
     {
-        ssdt = mem_alloc(sizeof(ssdt_pm), 16);
+        ssdt = config->mem_ops.alloc(sizeof(ssdt_pm), 16);
         if (!ssdt) return -1;
         memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-        table_ptrs[nr_tables++] = virt_to_phys(ssdt);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(ssdt);
     }
 
     if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
     {
-        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        ssdt = config->mem_ops.alloc(sizeof(ssdt_s3), 16);
         if (!ssdt) return -1;
         memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-        table_ptrs[nr_tables++] = virt_to_phys(ssdt);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(ssdt);
     } else {
         printf("S3 disabled\n");
     }
 
     if ( config->table_flags & ACPI_BUILD_SSDT_S4 )
     {
-        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        ssdt = config->mem_ops.alloc(sizeof(ssdt_s4), 16);
         if (!ssdt) return -1;
         memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-        table_ptrs[nr_tables++] = virt_to_phys(ssdt);
+        table_ptrs[nr_tables++] = config->mem_ops.v2p(ssdt);
     } else {
         printf("S4 disabled\n");
     }
@@ -398,15 +398,15 @@ 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 = config->mem_ops.alloc(sizeof(ssdt_tpm), 16);
             if (!ssdt) return -1;
             memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-            table_ptrs[nr_tables++] = virt_to_phys(ssdt);
+            table_ptrs[nr_tables++] = config->mem_ops.v2p(ssdt);
 
-            tcpa = mem_alloc(sizeof(struct acpi_20_tcpa), 16);
+            tcpa = config->mem_ops.alloc(sizeof(struct acpi_20_tcpa), 16);
             if (!tcpa) return -1;
             memset(tcpa, 0, sizeof(*tcpa));
-            table_ptrs[nr_tables++] = virt_to_phys(tcpa);
+            table_ptrs[nr_tables++] = config->mem_ops.v2p(tcpa);
 
             tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
             tcpa->header.length    = sizeof(*tcpa);
@@ -416,9 +416,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 = config->mem_ops.alloc(ACPI_2_0_TCPA_LAML_SIZE, 16)) != NULL )
             {
-                tcpa->lasa = virt_to_phys(lasa);
+                tcpa->lasa = config->mem_ops.v2p(lasa);
                 tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
                 memset(lasa, 0, tcpa->laml);
                 set_checksum(tcpa,
@@ -435,11 +435,11 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
         struct acpi_20_slit *slit = construct_slit(config);
 
         if ( srat )
-            table_ptrs[nr_tables++] = virt_to_phys(srat);
+            table_ptrs[nr_tables++] = config->mem_ops.v2p(srat);
         else
             printf("Failed to build SRAT, skipping...\n");
         if ( slit )
-            table_ptrs[nr_tables++] = virt_to_phys(slit);
+            table_ptrs[nr_tables++] = config->mem_ops.v2p(slit);
         else
             printf("Failed to build SLIT, skipping...\n");
     }
@@ -469,13 +469,13 @@ 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 *) config->mem_ops.alloc(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->acpi_info.vm_gid_addr = virt_to_phys(buf);
+    config->acpi_info.vm_gid_addr = config->mem_ops.v2p(buf);
 
     return 1;
 }
@@ -492,11 +492,17 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     unsigned long        secondary_tables[ACPI_MAX_SECONDARY_TABLES];
     int                  nr_secondaries, i;
 
+    if ( !config->mem_ops.alloc || !config->mem_ops.v2p )
+    {
+        printf("unable to build ACPI tables: no memory ops\n");
+        return;
+    }
+
     /*
      * Fill in high-memory data structures, starting at @buf.
      */
 
-    facs = mem_alloc(sizeof(struct acpi_20_facs), 16);
+    facs = config->mem_ops.alloc(sizeof(struct acpi_20_facs), 16);
     if (!facs) goto oom;
     memcpy(facs, &Facs, sizeof(struct acpi_20_facs));
 
@@ -510,14 +516,14 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
      */
     if ( config->nr_vcpus <= 15 && config->dsdt_15cpu)
     {
-        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
+        dsdt = config->mem_ops.alloc(config->dsdt_15cpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
         nr_processor_objects = 15;
     }
     else
     {
-        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
+        dsdt = config->mem_ops.alloc(config->dsdt_anycpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
         nr_processor_objects = HVM_MAX_VCPUS;
@@ -531,24 +537,24 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
      * 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 = config->mem_ops.alloc(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);
     fadt_10->header.revision = ACPI_1_0_FADT_REVISION;
-    fadt_10->dsdt          = virt_to_phys(dsdt);
-    fadt_10->firmware_ctrl = virt_to_phys(facs);
+    fadt_10->dsdt          = config->mem_ops.v2p(dsdt);
+    fadt_10->firmware_ctrl = config->mem_ops.v2p(facs);
     set_checksum(fadt_10,
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_10_fadt));
 
-    fadt = mem_alloc(sizeof(struct acpi_20_fadt), 16);
+    fadt = config->mem_ops.alloc(sizeof(struct acpi_20_fadt), 16);
     if (!fadt) goto oom;
     memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
-    fadt->dsdt   = virt_to_phys(dsdt);
-    fadt->x_dsdt = virt_to_phys(dsdt);
-    fadt->firmware_ctrl   = virt_to_phys(facs);
-    fadt->x_firmware_ctrl = virt_to_phys(facs);
+    fadt->dsdt   = config->mem_ops.v2p(dsdt);
+    fadt->x_dsdt = config->mem_ops.v2p(dsdt);
+    fadt->firmware_ctrl   = config->mem_ops.v2p(facs);
+    fadt->x_firmware_ctrl = config->mem_ops.v2p(facs);
     set_checksum(fadt,
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
@@ -557,12 +563,12 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     if ( nr_secondaries < 0 )
         goto oom;
 
-    xsdt = mem_alloc(sizeof(struct acpi_20_xsdt)+
+    xsdt = config->mem_ops.alloc(sizeof(struct acpi_20_xsdt)+
                      sizeof(uint64_t)*nr_secondaries,
                      16);
     if (!xsdt) goto oom;
     memcpy(xsdt, &Xsdt, sizeof(struct acpi_header));
-    xsdt->entry[0] = virt_to_phys(fadt);
+    xsdt->entry[0] = config->mem_ops.v2p(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);
@@ -570,12 +576,12 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
                  offsetof(struct acpi_header, checksum),
                  xsdt->header.length);
 
-    rsdt = mem_alloc(sizeof(struct acpi_20_rsdt)+
+    rsdt = config->mem_ops.alloc(sizeof(struct acpi_20_rsdt)+
                      sizeof(uint32_t)*nr_secondaries,
                      16);
     if (!rsdt) goto oom;
     memcpy(rsdt, &Rsdt, sizeof(struct acpi_header));
-    rsdt->entry[0] = virt_to_phys(fadt_10);
+    rsdt->entry[0] = config->mem_ops.v2p(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);
@@ -589,8 +595,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned int physical)
     rsdp = (struct acpi_20_rsdp *)physical;
 
     memcpy(rsdp, &Rsdp, sizeof(struct acpi_20_rsdp));
-    rsdp->rsdt_address = virt_to_phys(rsdt);
-    rsdp->xsdt_address = virt_to_phys(xsdt);
+    rsdp->rsdt_address = config->mem_ops.v2p(rsdt);
+    rsdp->xsdt_address = config->mem_ops.v2p(xsdt);
     set_checksum(rsdp,
                  offsetof(struct acpi_10_rsdp, checksum),
                  sizeof(struct acpi_10_rsdp));
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index c111f61..9e6ee7d 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -866,6 +866,11 @@ static uint8_t battery_port_exists(void)
     return (inb(0x88) == 0x1F);
 }
 
+unsigned long virt_to_phys(void *v)
+{
+    return (unsigned long)v;
+}
+
 void hvmloader_acpi_build_tables(struct acpi_config *config,
                                  unsigned int physical)
 {
@@ -928,6 +933,9 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
     config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
     config->acpi_info_page = (void *)ACPI_INFO_PHYSICAL_ADDRESS;
 
+    config->mem_ops.alloc = mem_alloc;
+    config->mem_ops.v2p = virt_to_phys;
+
     acpi_build_tables(config, physical);
 
     hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->acpi_info.vm_gid_addr);
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index b226df4..91c210c 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -196,7 +196,7 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
 
 /* Allocate memory in a reserved region below 4GB. */
 void *mem_alloc(uint32_t size, uint32_t align);
-#define virt_to_phys(v) ((unsigned long)(v))
+unsigned long virt_to_phys(void *v);
 
 /* Allocate memory in a scratch region */
 void *scratch_alloc(uint32_t size, uint32_t align);
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (13 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 13:05   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
                   ` (6 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Boris Ostrovsky, Stefano Stabellini, Wei Liu, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 .gitignore                                                        | 8 ++++----
 tools/firmware/hvmloader/Makefile                                 | 3 +--
 tools/firmware/hvmloader/smbios.c                                 | 1 +
 tools/firmware/rombios/32bit/Makefile                             | 2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
 .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
 .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
 {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
 17 files changed, 11 insertions(+), 11 deletions(-)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile (94%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/static_tables.c (100%)
 rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h (100%)

diff --git a/.gitignore b/.gitignore
index 91f690c..15d3705 100644
--- a/.gitignore
+++ b/.gitignore
@@ -123,10 +123,6 @@ 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/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
@@ -259,6 +255,10 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/common/libacpi/mk_dsdt
+xen/common/libacpi/dsdt*.c
+xen/common/libacpi/dsdt_*cpu*.asl
+xen/common/libacpi/ssdt_*.h
 xen/tools/kconfig/.tmp_gtkcheck
 xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index c778174..cbc4ae0 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -32,7 +32,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
 
 # ACPI table builder
-ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+ACPI_PATH = $(XEN_ROOT)/xen/common/libacpi
 vpath %.c $(ACPI_PATH)
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c static_tables.c dsdt_anycpu_qemu_xen.c build.c
 ACPI_SRC = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
@@ -153,7 +153,6 @@ endif
 clean: subdirs-clean
 	rm -f roms.inc roms.inc.new acpi.h
 	rm -f hvmloader hvmloader.tmp *.o $(DEPS)
-	$(MAKE) -C $(ACPI_PATH) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/smbios.c b/tools/firmware/hvmloader/smbios.c
index 210c7b0..bfe8562 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -24,6 +24,7 @@
 #include <xen/version.h>
 #include "smbios_types.h"
 #include "util.h"
+#include "acpi2_0.h"
 #include "hypercall.h"
 #include <xen/hvm/hvm_xs_strings.h>
 
diff --git a/tools/firmware/rombios/32bit/Makefile b/tools/firmware/rombios/32bit/Makefile
index 9b523bd..9795960 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET = 32bitbios_flat.h
 
-CFLAGS += $(CFLAGS_xeninclude) -I.. -I$(XEN_ROOT)/tools/firmware/hvmloader/acpi/
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I$(XEN_ROOT)/xen/common/libacpi
 
 SUBDIRS = tcgbios
 
diff --git a/tools/firmware/rombios/32bit/tcgbios/Makefile b/tools/firmware/rombios/32bit/tcgbios/Makefile
index 6555028..4ce25e3 100644
--- a/tools/firmware/rombios/32bit/tcgbios/Makefile
+++ b/tools/firmware/rombios/32bit/tcgbios/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET  = tcgbiosext.o
 
-CFLAGS += $(CFLAGS_xeninclude) -I.. -I../.. -I$(XEN_ROOT)/tools/firmware/hvmloader/acpi/
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I../.. -I$(XEN_ROOT)/xen/common/libacpi
 
 .PHONY: all
 all: $(TARGET)
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/xen/common/libacpi/Makefile
similarity index 94%
rename from tools/firmware/hvmloader/acpi/Makefile
rename to xen/common/libacpi/Makefile
index 4d84e4c..efef589 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/xen/common/libacpi/Makefile
@@ -14,13 +14,13 @@
 # this program; If not, see <http://www.gnu.org/licenses/>.
 #
 
-XEN_ROOT = $(CURDIR)/../../../..
-include $(XEN_ROOT)/tools/firmware/Rules.mk
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/Config.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))
 
-CFLAGS += $(CFLAGS_xeninclude)
+CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
 
 vpath iasl $(PATH)
 all: $(C_SRC) ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
diff --git a/tools/firmware/hvmloader/acpi/README b/xen/common/libacpi/README
similarity index 100%
rename from tools/firmware/hvmloader/acpi/README
rename to xen/common/libacpi/README
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/xen/common/libacpi/acpi2_0.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/acpi2_0.h
rename to xen/common/libacpi/acpi2_0.h
diff --git a/tools/firmware/hvmloader/acpi/build.c b/xen/common/libacpi/build.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/build.c
rename to xen/common/libacpi/build.c
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/xen/common/libacpi/dsdt.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/dsdt.asl
rename to xen/common/libacpi/dsdt.asl
diff --git a/tools/firmware/hvmloader/acpi/mk_dsdt.c b/xen/common/libacpi/mk_dsdt.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/mk_dsdt.c
rename to xen/common/libacpi/mk_dsdt.c
diff --git a/tools/firmware/hvmloader/acpi/ssdt_pm.asl b/xen/common/libacpi/ssdt_pm.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_pm.asl
rename to xen/common/libacpi/ssdt_pm.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_s3.asl b/xen/common/libacpi/ssdt_s3.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_s3.asl
rename to xen/common/libacpi/ssdt_s3.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_s4.asl b/xen/common/libacpi/ssdt_s4.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_s4.asl
rename to xen/common/libacpi/ssdt_s4.asl
diff --git a/tools/firmware/hvmloader/acpi/ssdt_tpm.asl b/xen/common/libacpi/ssdt_tpm.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/ssdt_tpm.asl
rename to xen/common/libacpi/ssdt_tpm.asl
diff --git a/tools/firmware/hvmloader/acpi/static_tables.c b/xen/common/libacpi/static_tables.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/static_tables.c
rename to xen/common/libacpi/static_tables.c
diff --git a/tools/firmware/hvmloader/acpi/x86.h b/xen/common/libacpi/x86.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/x86.h
rename to xen/common/libacpi/x86.h
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic()
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (14 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-03 16:14   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
                   ` (5 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Boris Ostrovsky, Keir Fraser, Jan Beulich, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vlapic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 01a8430..d8b887c 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1133,6 +1133,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;
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (15 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-03 16:18   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
                   ` (4 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Boris Ostrovsky, Keir Fraser, Jan Beulich, roger.pau

PVH guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/domain.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a6d721b..3b614d7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -540,25 +540,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)) )
+
+        /* PVH 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) )
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (16 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-02 16:26   ` Roger Pau Monné
                     ` (2 more replies)
  2016-04-06  1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
                   ` (3 subsequent siblings)
  21 siblings, 3 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel; +Cc: Boris Ostrovsky, Stefano Stabellini, Wei Liu, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 tools/libxc/Makefile              |  22 +++-
 tools/libxc/include/xc_dom.h      |   1 +
 tools/libxc/xc_acpi.c             | 268 ++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_x86.c          |   7 +
 tools/libxl/libxl_x86.c           |  19 +--
 xen/common/libacpi/Makefile       |   5 +-
 xen/common/libacpi/acpi2_0.h      |   2 +-
 xen/common/libacpi/build.c        |   2 +-
 xen/common/libacpi/dsdt_empty.asl |  22 ++++
 9 files changed, 335 insertions(+), 13 deletions(-)
 create mode 100644 tools/libxc/xc_acpi.c
 create mode 100644 xen/common/libacpi/dsdt_empty.asl

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 608404f..9569e54 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -79,6 +79,26 @@ GUEST_SRCS-y += $(ELF_SRCS-y)
 $(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
 $(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
 
+ACPI_PATH = $(XEN_ROOT)/xen/common/libacpi
+vpath %.c $(ACPI_PATH)
+ACPI_FILES  = dsdt_anycpu.c dsdt_15cpu.c static_tables.c
+ACPI_FILES += dsdt_anycpu_qemu_xen.c dsdt_empty.c build.c
+ACPI_SRCS = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
+
+.NOTPARALLEL: $(ACPI_SRCS)
+$(ACPI_SRCS):
+	make -C $(ACPI_PATH)
+
+$(patsubst %.c,%.o,$(ACPI_SRCS)): CFLAGS += -I$(ACPI_PATH)
+$(patsubst %.c,%.opic,$(ACPI_SRCS)): CFLAGS += -I$(ACPI_PATH)
+xc_acpi.o: CFLAGS += -I$(ACPI_PATH)
+xc_acpi.opic: CFLAGS += -I$(ACPI_PATH)
+
+GUEST_SRCS-y += $(ACPI_FILES)
+
+$(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
+$(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
+
 # new domain builder
 GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y                 += xc_dom_elfloader.c
@@ -89,7 +109,7 @@ GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
 GUEST_SRCS-y                 += xc_dom_binloader.c
 GUEST_SRCS-y                 += xc_dom_compat_linux.c
 
-GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
+GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c xc_acpi.c
 GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
 GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
 
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ebe946..3842fb1 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -407,6 +407,7 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image *dom, xen_pfn_t first,
                                  xen_pfn_t count, xen_pfn_t *count_out);
 void xc_dom_unmap_one(struct xc_dom_image *dom, xen_pfn_t pfn);
 void xc_dom_unmap_all(struct xc_dom_image *dom);
+int xc_dom_build_acpi(struct xc_dom_image *dom);
 
 static inline void *xc_dom_seg_to_ptr_pages(struct xc_dom_image *dom,
                                       struct xc_dom_seg *seg,
diff --git a/tools/libxc/xc_acpi.c b/tools/libxc/xc_acpi.c
new file mode 100644
index 0000000..3173d49
--- /dev/null
+++ b/tools/libxc/xc_acpi.c
@@ -0,0 +1,268 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <inttypes.h>
+#include <assert.h>
+
+#include <xen/xen.h>
+#include <xen/foreign/x86_32.h>
+#include <xen/foreign/x86_64.h>
+#include <xen/hvm/hvm_info_table.h>
+#include <xen/io/protocols.h>
+
+#include "xg_private.h"
+#include "xc_dom.h"
+#include "xenctrl.h"
+
+#include "acpi2_0.h"
+
+#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
+#define ACPI_PHYSICAL_ADDRESS         0x000EA020
+
+/* Initial allocation for ACPI tables */
+#define NUM_ACPI_PAGES  16
+
+#define PFN(paddr)  ((paddr) >> PAGE_SHIFT)
+
+extern unsigned char dsdt_anycpu[], dsdt_15cpu[], dsdt_empty[];
+extern int dsdt_anycpu_len, dsdt_15cpu_len, dsdt_empty_len;
+
+static uint64_t alloc_up, alloc_down;
+static unsigned long base_addr;
+
+/* Assumes contiguous physical space */
+static unsigned long virt_to_phys(void *v)
+{
+	return (((unsigned long)v - base_addr) + RESERVED_MEMORY_DYNAMIC_START);
+}
+
+static void *mem_alloc(uint32_t size, uint32_t align)
+{
+    uint64_t s, e;
+
+    /* Align to at least 16 bytes. */
+    if ( align < 16 )
+        align = 16;
+
+    s = (alloc_up + align) & ~((uint64_t)align - 1);
+    e = s + size - 1;
+
+    /* TODO: Reallocate memory */
+    if ((e < s) || (e >= alloc_down)) return NULL;
+
+    while ( PFN(alloc_up) != PFN(e) )
+    {
+        alloc_up += PAGE_SIZE;
+    }
+
+    alloc_up = e;
+
+    return (void *)(unsigned long)s;
+}
+
+static int init_acpi_config(struct xc_dom_image *dom,
+                            struct acpi_config *config)
+{
+    xc_interface *xch = dom->xch;
+    uint32_t domid = dom->guest_domid;
+    xc_dominfo_t info;
+    int i, rc;
+
+    memset(config, 0, sizeof(*config));
+
+    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
+    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
+
+    rc = xc_domain_getinfo(xch, domid, 1, &info);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
+        return rc;
+    }
+
+    config->apic_mode = 1;
+
+    if ( dom->nr_vnodes )
+    {
+        struct acpi_numa *numa = &config->numa;
+
+        numa->vmemrange = calloc(dom->nr_vmemranges,
+                                 sizeof(*numa->vmemrange));
+        numa->vdistance = calloc(dom->nr_vnodes,
+                                 sizeof(*numa->vdistance));
+        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
+                                     sizeof(*numa->vcpu_to_vnode));
+        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
+        {
+            DOMPRINTF("%s: Out of memory", __FUNCTION__);
+            free(numa->vmemrange);
+            free(numa->vdistance);
+            free(numa->vcpu_to_vnode);
+            return -ENOMEM;
+        }
+
+        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
+                                &numa->nr_vmemranges,
+                                &config->nr_vcpus, numa->vmemrange,
+                                numa->vdistance, numa->vcpu_to_vnode);
+
+	    if ( rc )
+        {
+            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
+            return rc;
+        }
+    }
+    else
+        config->nr_vcpus = info.max_vcpu_id + 1;
+
+    config->vcpu_online = calloc((HVM_MAX_VCPUS + 7) / 8,
+                                 sizeof(*config->vcpu_online));
+    if ( config->vcpu_online == NULL )
+    {
+        DOMPRINTF("%s: Can't allocate vcpu_online", __FUNCTION__);
+        return -ENOMEM;
+    }
+
+    for (i=0; i<config->nr_vcpus; i++)
+        config->vcpu_online[i / 8] |= 1 << (i & 7);
+
+    config->mem_ops.alloc = mem_alloc;
+    config->mem_ops.v2p = virt_to_phys;
+
+    return 0;
+}
+
+int xc_dom_build_acpi(struct xc_dom_image *dom)
+{
+    struct acpi_config config;
+    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, *acpi_physical;
+    void *guest_info_page, *guest_acpi_pages;
+
+    rc = init_acpi_config(dom, &config);
+    if ( rc )
+    {
+        DOMPRINTF("%s: init_acpi_config failed (rc=%d)", __FUNCTION__, rc);
+        return rc;
+    }
+
+    /*
+     * Pages to hold ACPI tables and one page for acpi_info, which
+     * will be the first one in this region.
+     */
+    acpi_pages = xc_memalign(xch, PAGE_SIZE, NUM_ACPI_PAGES * PAGE_SIZE);
+    if ( !acpi_pages )
+    {
+        DOMPRINTF("%s: Can't allocate acpi pages", __FUNCTION__);
+        rc = -1;
+        goto out;
+    }
+
+    config.acpi_info_page = acpi_pages;
+
+    /* Set up allocator memory */
+    base_addr = alloc_up = (unsigned long)acpi_pages + PAGE_SIZE;
+    alloc_down = (unsigned long)acpi_pages + (NUM_ACPI_PAGES * PAGE_SIZE);
+
+    /* Map page that will hold RSDP */
+    extent = PFN(ACPI_PHYSICAL_ADDRESS);
+    rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &extent);
+    if ( rc )
+    {
+        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d",
+                  __FUNCTION__, rc);
+        goto out;
+    }
+    acpi_physical = xc_map_foreign_range(xch, domid, PAGE_SIZE,
+                                         PROT_READ | PROT_WRITE,
+                                         PFN(ACPI_PHYSICAL_ADDRESS));
+    if ( !acpi_physical )
+    {
+        DOMPRINTF("%s: Can't map acpi_physical", __FUNCTION__);
+        rc = -1;
+        goto out;
+    }
+
+    /* Build the tables */
+    acpi_build_tables(&config, (unsigned long)acpi_physical);
+
+    /* Copy acpi_info page into guest's memory */
+    extent = PFN(ACPI_INFO_PHYSICAL_ADDRESS);
+    rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &extent);
+    if ( rc )
+    {
+        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d\n",
+                  __FUNCTION__, rc);
+        goto out;
+    }
+    guest_info_page = xc_map_foreign_range(xch, domid, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE,
+                                           PFN(ACPI_INFO_PHYSICAL_ADDRESS));
+    if ( !guest_info_page )
+    {
+        DOMPRINTF("%s: Can't map acpi_info_page", __FUNCTION__);
+        rc = -1;
+        goto out;
+    }
+    memcpy(guest_info_page, acpi_pages, PAGE_SIZE);
+
+    /* Copy ACPI tables into guest's memory */
+    acpi_pages_num = ((alloc_up - (unsigned long)acpi_pages +
+                       (PAGE_SIZE - 1)) >> PAGE_SHIFT) - 1;
+    extents = malloc(acpi_pages_num * sizeof(*extents));
+    if ( !extents )
+    {
+        DOMPRINTF("%s: Can't allocate extents array", __FUNCTION__);
+        rc = -ENOMEM;
+        goto out;
+    }
+    for (i = 0; i < acpi_pages_num; i++)
+        extents[i] = PFN(RESERVED_MEMORY_DYNAMIC_START) + i;
+    rc = xc_domain_populate_physmap_exact(xch, domid, acpi_pages_num,
+                                          0, 0, extents);
+    if ( rc )
+    {
+        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d",
+                  __FUNCTION__, rc);
+        goto out;
+    }
+    guest_acpi_pages = xc_map_foreign_range(xch, domid,
+                                            PAGE_SIZE * acpi_pages_num,
+                                            PROT_READ | PROT_WRITE,
+                                            PFN(RESERVED_MEMORY_DYNAMIC_START));
+    if ( !guest_acpi_pages )
+    {
+        DOMPRINTF("%s Can't map guest_acpi_pages", __FUNCTION__);
+        rc = -1;
+        goto out;
+    }
+
+    memcpy(guest_acpi_pages, acpi_pages + PAGE_SIZE,
+           acpi_pages_num * PAGE_SIZE);
+
+out:
+    munmap(guest_acpi_pages, acpi_pages_num * PAGE_SIZE);
+    munmap(guest_info_page, PAGE_SIZE);
+    munmap(acpi_physical, PAGE_SIZE);
+    free(extents);
+    free(acpi_pages);
+    free(config.vcpu_online);
+    free(config.numa.vmemrange);
+    free(config.numa.vdistance);
+    free(config.numa.vcpu_to_vnode);
+
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bdec40a..8698b36 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -643,6 +643,13 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
             DOMPRINTF("Unable to reserve memory for the start info");
             goto out;
         }
+
+        rc = xc_dom_build_acpi(dom);
+        if ( rc != 0 )
+        {
+            DOMPRINTF("Unable to build ACPI tables");
+            goto out;
+        }
     }
     else
     {
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..ef6c239 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
+            /*
+             * HVM guests without device model will want
+             * to have LAPIC emulation.
+             */
+            xc_config->emulation_flags = XEN_X86_EMU_LAPIC;
+    } else 
         xc_config->emulation_flags = 0;
-    }
 
     return 0;
 }
diff --git a/xen/common/libacpi/Makefile b/xen/common/libacpi/Makefile
index efef589..a1f233f 100644
--- a/xen/common/libacpi/Makefile
+++ b/xen/common/libacpi/Makefile
@@ -17,7 +17,8 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/Config.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c dsdt_anycpu_qemu_xen.c
+C_SRC  = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
+C_SRC += dsdt_anycpu_qemu_xen.c dsdt_empty.c
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
 CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
@@ -58,7 +59,7 @@ iasl:
 
 clean:
 	rm -rf *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-	rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+	rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*cpu*.asl
 
 distclean: clean
 
diff --git a/xen/common/libacpi/acpi2_0.h b/xen/common/libacpi/acpi2_0.h
index 0525a1e..458fb49 100644
--- a/xen/common/libacpi/acpi2_0.h
+++ b/xen/common/libacpi/acpi2_0.h
@@ -516,7 +516,7 @@ struct acpi_config {
     struct acpi_mem_ops mem_ops;
 };
 
-void acpi_build_tables(struct acpi_config *config, unsigned int physical);
+void acpi_build_tables(struct acpi_config *config, unsigned long physical);
 
 #endif /* _ACPI_2_0_H_ */
 
diff --git a/xen/common/libacpi/build.c b/xen/common/libacpi/build.c
index eb8c632..e53b4a7 100644
--- a/xen/common/libacpi/build.c
+++ b/xen/common/libacpi/build.c
@@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
     return 1;
 }
 
-void acpi_build_tables(struct acpi_config *config, unsigned int physical)
+void acpi_build_tables(struct acpi_config *config, unsigned long physical)
 {
     struct acpi_20_rsdp *rsdp;
     struct acpi_20_rsdt *rsdt;
diff --git a/xen/common/libacpi/dsdt_empty.asl b/xen/common/libacpi/dsdt_empty.asl
new file mode 100644
index 0000000..25c0b95
--- /dev/null
+++ b/xen/common/libacpi/dsdt_empty.asl
@@ -0,0 +1,22 @@
+/******************************************************************************
+ * DSDT for Xen with Qemu device model
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ *
+ * 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/>.
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
+{
+
+}
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (17 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 13:38   ` Jan Beulich
  2016-04-06  1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
                   ` (2 subsequent siblings)
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Ian Jackson, Tim Deegan, Jan Beulich,
	Boris Ostrovsky, roger.pau

With this flags set guests will not try to set up SCI.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/common/libacpi/build.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/libacpi/build.c b/xen/common/libacpi/build.c
index e53b4a7..7f2662a 100644
--- a/xen/common/libacpi/build.c
+++ b/xen/common/libacpi/build.c
@@ -555,6 +555,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned long physical)
     fadt->x_dsdt = config->mem_ops.v2p(dsdt);
     fadt->firmware_ctrl   = config->mem_ops.v2p(facs);
     fadt->x_firmware_ctrl = config->mem_ops.v2p(facs);
+    if ( !(config->table_flags & ACPI_BUILD_IOAPIC) )
+        fadt->flags |= (1<<20); /* HW_REDUCED_ACPI */
     set_checksum(fadt,
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (18 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
@ 2016-04-06  1:25 ` Boris Ostrovsky
  2016-06-06 13:48   ` Jan Beulich
  2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
  2016-06-02 12:40 ` Jan Beulich
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-04-06  1:25 UTC (permalink / raw)
  To: xen-devel
  Cc: Keir Fraser, Ian Jackson, Tim Deegan, Jan Beulich,
	Boris Ostrovsky, roger.pau

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/common/Makefile          |  2 +-
 xen/common/libacpi/Makefile  | 15 ++++++++++++---
 xen/common/libacpi/acpi2_0.h |  6 ++++++
 xen/common/libacpi/build.c   | 15 +++++++++++++++
 xen/common/libacpi/mk_dsdt.c |  4 ++++
 5 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 77de27e..6e0ac8b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -73,5 +73,5 @@ subdir-$(CONFIG_X86) += hvm
 
 subdir-$(coverage) += gcov
 
-subdir-y += libelf
+subdir-y += libelf libacpi
 subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
diff --git a/xen/common/libacpi/Makefile b/xen/common/libacpi/Makefile
index a1f233f..6cf98db 100644
--- a/xen/common/libacpi/Makefile
+++ b/xen/common/libacpi/Makefile
@@ -21,7 +21,16 @@ C_SRC  = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
 C_SRC += dsdt_anycpu_qemu_xen.c dsdt_empty.c
 OBJS  = $(patsubst %.c,%.o,$(C_SRC))
 
-CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
+ifneq (,$(findstring -D__XEN__,$(CFLAGS)))
+# Hypervisor
+obj-y	= $(OBJS)
+$(OBJS): all
+CFLAGS  += -I$(XEN_ROOT)/xen/include/public
+CFLAGS_MKDSDT = -I$(XEN_ROOT)/xen/include/public/hvm -D__XEN__
+else
+# Toolstack
+CFLAGS_MKDSDT = -I$(XEN_ROOT)/tools/include
+endif
 
 vpath iasl $(PATH)
 all: $(C_SRC) ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
@@ -32,7 +41,7 @@ ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	rm -f $*.hex $*.aml
 
 mk_dsdt: mk_dsdt.c
-	$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
+	$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_MKDSDT) -o $@ mk_dsdt.c
 
 dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
 	awk 'NR > 1 {print s} {s=$$0}' $< > $@
@@ -57,7 +66,7 @@ iasl:
 	@echo 
 	@exit 1
 
-clean:
+clean::
 	rm -rf *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
 	rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*cpu*.asl
 
diff --git a/xen/common/libacpi/acpi2_0.h b/xen/common/libacpi/acpi2_0.h
index 458fb49..d47ad84 100644
--- a/xen/common/libacpi/acpi2_0.h
+++ b/xen/common/libacpi/acpi2_0.h
@@ -17,10 +17,16 @@
 #ifndef _ACPI_2_0_H_
 #define _ACPI_2_0_H_
 
+#ifndef __XEN__
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/hvm/ioreq.h>
 #include <xen/memory.h>
+#else
+#include <xen/lib.h>
+#include <memory.h>
+#include <hvm/ioreq.h>
+#endif
 
 #define ASCII32(a,b,c,d)         \
     (((a) <<  0) | ((b) <<  8) | ((c) << 16) | ((d) << 24))
diff --git a/xen/common/libacpi/build.c b/xen/common/libacpi/build.c
index 7f2662a..cbde7f9 100644
--- a/xen/common/libacpi/build.c
+++ b/xen/common/libacpi/build.c
@@ -15,8 +15,13 @@
  * this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+#ifndef __XEN__
 #include <stdio.h>
 #include <string.h>
+#else
+#include <xen/lib.h>
+#define printf printk
+#endif
 
 #include "acpi2_0.h"
 #include "ssdt_s3.h"
@@ -24,14 +29,24 @@
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "x86.h"
+#ifndef __XEN__
 #include <xen/hvm/hvm_info_table.h>
 #include <xen/hvm/hvm_xs_strings.h>
 #include <xen/hvm/params.h>
+#else
+#include <hvm/hvm_info_table.h>
+#include <hvm/hvm_xs_strings.h>
+#include <hvm/params.h>
+#endif
 
 #define ACPI_MAX_SECONDARY_TABLES 16
 
 #define align16(sz)        (((sz) + 15) & ~15)
+#ifndef __XEN__
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
+#else
+#define fixed_strcpy(d, s) strlcpy((d), (s), sizeof(d))
+#endif
 #ifndef offsetof
 #define offsetof(t, m) ((unsigned long)&((t *)0)->m)
 #endif
diff --git a/xen/common/libacpi/mk_dsdt.c b/xen/common/libacpi/mk_dsdt.c
index b567b38..e38a2f2 100644
--- a/xen/common/libacpi/mk_dsdt.c
+++ b/xen/common/libacpi/mk_dsdt.c
@@ -5,7 +5,11 @@
 #include <getopt.h>
 #include <stdlib.h>
 #include <stdbool.h>
+#ifndef __XEN__
 #include <xen/hvm/hvm_info_table.h>
+#else
+#include <hvm_info_table.h>
+#endif
 
 static unsigned int indent_level;
 static bool debug = false;
-- 
2.4.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (19 preceding siblings ...)
  2016-04-06  1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
@ 2016-05-09 20:10 ` Boris Ostrovsky
  2016-05-10  7:25   ` Jan Beulich
  2016-06-02 12:40 ` Jan Beulich
  21 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-05-09 20:10 UTC (permalink / raw)
  To: xen-devel; +Cc: roger.pau

On 04/05/2016 09:25 PM, Boris Ostrovsky wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html

When do people think they will get a chance to comment on this? Should
this wait until after 4.7 is released?


Thanks.
-boris


> The series
> * Removes dependency of today's builder on hvmloader interfaces
> * Makes many of the tables built optionally.
> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
> * Builds tables for PVHv2 domU guests in libxc
>
> There is still a number of questions about this implementation, thus it's
> an RFC. Examples of things that need to be discussed are
>
> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>   to make this an option.
> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>   tools/firmware/hvmloader/{stdio.h,string.h} 
> * The builder is compiled into the hypervisor even though currently
>   there are no users (PVHv2 dom0 will be the one)
> * Patch 19 is somewhat of a spec violation
> * Makefiles are questionable
> * May need changes to guests' e820 map
>
> This is also available from git://oss.oracle.com/git/bostrovs/xen.git:acpi_rfc.
>
> It has been tested with Linux PVHv2 (and I believe Roger tested an earlier
> version with FreeBSD). No passthrough testing has been done.
>
> (I realize that many people are busy because of Friday's freeze but I figured I'd
> post it now in the hope that this may get some reading so that we can talk about
> it at the hackathon)
>
>
> Boris Ostrovsky (20):
>   hvmloader: Provide hvmloader_acpi_build_tables()
>   acpi/hvmloader: Move acpi_info initialization out of ACPI code
>   acpi/hvmloader: Initialize vm_gid data outside ACPI code
>   acpi/hvmloader: Decide which SSDTs to build in hvmloader
>   acpi/hvmloader: Move passthrough initialization from ACPI code
>   acpi/hvmloader: Collect processor and NUMA info in hvmloader
>   acpi/hvmloader: Set TIS header address in hvmloader
>   acpi/hvmloader: Make providing IOAPIC in MADT optional
>   acpi/hvmloader: Build WAET optionally
>   acpi/hvmloader: Provide address of acpi_info as an argument to ACPI
>     code
>   acpi/hvmloader: Translate all addresses when assigning addresses in
>     ACPI tables
>   acpi/hvmloader: Link ACPI object files directly
>   acpi/hvmloader: Add stdio.h, string.h and x86.h
>   acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
>   acpi: Move ACPI code to xen/common/libacpi
>   x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic()
>   x86: Allow LAPIC-only emulation_flags for HVM guests
>   libxc/acpi: Build ACPI tables for HVMlite guests
>   acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
>   acpi: Make ACPI builder available to hypervisor code
>
>  .gitignore                                         |   8 +-
>  tools/firmware/hvmloader/Makefile                  |  16 +-
>  tools/firmware/hvmloader/config.h                  |  13 +-
>  tools/firmware/hvmloader/hvmloader.c               |   3 +-
>  tools/firmware/hvmloader/mp_tables.c               |   1 +
>  tools/firmware/hvmloader/ovmf.c                    |   4 +-
>  tools/firmware/hvmloader/pci.c                     |   1 +
>  tools/firmware/hvmloader/pir.c                     |   1 +
>  tools/firmware/hvmloader/rombios.c                 |   4 +-
>  tools/firmware/hvmloader/seabios.c                 |   4 +-
>  tools/firmware/hvmloader/smbios.c                  |   1 +
>  tools/firmware/hvmloader/smp.c                     |   1 +
>  tools/firmware/hvmloader/stdio.h                   |   7 +
>  tools/firmware/hvmloader/string.h                  |   7 +
>  tools/firmware/hvmloader/util.c                    |  85 +++++
>  tools/firmware/hvmloader/util.h                    |   6 +-
>  tools/firmware/rombios/32bit/Makefile              |   2 +-
>  tools/firmware/rombios/32bit/tcgbios/Makefile      |   2 +-
>  tools/firmware/rombios/32bit/util.h                |   2 +-
>  tools/libxc/Makefile                               |  22 +-
>  tools/libxc/include/xc_dom.h                       |   1 +
>  tools/libxc/xc_acpi.c                              | 268 +++++++++++++
>  tools/libxc/xc_dom_x86.c                           |   7 +
>  tools/libxl/libxl_x86.c                            |  19 +-
>  xen/arch/x86/domain.c                              |  26 +-
>  xen/arch/x86/hvm/vlapic.c                          |   3 +
>  xen/common/Makefile                                |   2 +-
>  .../hvmloader/acpi => xen/common/libacpi}/Makefile |  33 +-
>  .../hvmloader/acpi => xen/common/libacpi}/README   |   0
>  .../acpi => xen/common/libacpi}/acpi2_0.h          |  66 +++-
>  .../hvmloader/acpi => xen/common/libacpi}/build.c  | 415 ++++++++++-----------
>  .../hvmloader/acpi => xen/common/libacpi}/dsdt.asl |   0
>  xen/common/libacpi/dsdt_empty.asl                  |  22 ++
>  .../acpi => xen/common/libacpi}/mk_dsdt.c          |   4 +
>  .../acpi => xen/common/libacpi}/ssdt_pm.asl        |   0
>  .../acpi => xen/common/libacpi}/ssdt_s3.asl        |   0
>  .../acpi => xen/common/libacpi}/ssdt_s4.asl        |   0
>  .../acpi => xen/common/libacpi}/ssdt_tpm.asl       |   0
>  .../acpi => xen/common/libacpi}/static_tables.c    |   1 -
>  xen/common/libacpi/x86.h                           |  14 +
>  40 files changed, 794 insertions(+), 277 deletions(-)
>  create mode 100644 tools/firmware/hvmloader/stdio.h
>  create mode 100644 tools/firmware/hvmloader/string.h
>  create mode 100644 tools/libxc/xc_acpi.c
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile (70%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README (100%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h (84%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c (58%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl (100%)
>  create mode 100644 xen/common/libacpi/dsdt_empty.asl
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c (99%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl (100%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl (100%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl (100%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl (100%)
>  rename {tools/firmware/hvmloader/acpi => xen/common/libacpi}/static_tables.c (99%)
>  create mode 100644 xen/common/libacpi/x86.h
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
@ 2016-05-10  7:25   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-05-10  7:25 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, roger.pau

>>> On 09.05.16 at 22:10, <boris.ostrovsky@oracle.com> wrote:
> On 04/05/2016 09:25 PM, Boris Ostrovsky wrote:
>> This is an RFC for making hvmloader's ACPI builder available to both the
>> toolstack and the hypervisor, as discussed in
>> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
> 
> When do people think they will get a chance to comment on this? Should
> this wait until after 4.7 is released?

I'm sorry, I don't anticipate to get to this much earlier than that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
                   ` (20 preceding siblings ...)
  2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
@ 2016-06-02 12:40 ` Jan Beulich
  2016-06-02 16:37   ` Boris Ostrovsky
  21 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 12:40 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
> 
> The series
> * Removes dependency of today's builder on hvmloader interfaces
> * Makes many of the tables built optionally.
> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
> * Builds tables for PVHv2 domU guests in libxc
> 
> There is still a number of questions about this implementation, thus it's
> an RFC. Examples of things that need to be discussed are
> 
> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>   to make this an option.
> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>   tools/firmware/hvmloader/{stdio.h,string.h} 
> * The builder is compiled into the hypervisor even though currently
>   there are no users (PVHv2 dom0 will be the one)

Is that really what we want? I thought we don't really mean to
build ACPI tables from scratch for Dom0, but rather follow ARM's
customization approach. And if we don't want this, then the
placement of this now shared code would need reconsidering.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
  2016-04-06  1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
@ 2016-06-02 12:42   ` Jan Beulich
  2016-06-02 16:39     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 12:42 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> @@ -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);
> +}

I guess later patches will make clear why this is an improvement.
On its own it doesn't look worthwhile.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-04-06  1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
@ 2016-06-02 12:54   ` Jan Beulich
  2016-06-02 16:54     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 12:54 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> 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.

So from a mechanical pov the patch looks fine (one remark below),
but if you move this out from acpi/, who's going to do the setup of
that structure outside of hvmloader? And if done by another
entity, how do you mean things to remain in sync? And btw., you're
still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
a hvmloader thing, which you just move the reference to inside
acpi/.

> @@ -619,20 +597,12 @@ 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->acpi_info) )
>          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;
> -    }
> +    memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
> +           &config->acpi_info,
> +           sizeof(config->acpi_info));

I'd prefer structure assignment to be used in cases like this, as
that lets the compiler check that the types match.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code
  2016-04-06  1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
@ 2016-06-02 13:03   ` Jan Beulich
  2016-06-02 17:01     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 13:03 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -448,32 +448,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->acpi_info.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->acpi_info.vm_gid_addr = virt_to_phys(buf);

Here things get interesting: If different entities are responsible for
filling different parts of acpi_info, I think this should be documented
in the structure definition. Can't this be left to the entity initializing
that structure?

> @@ -875,7 +878,19 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
>          config->acpi_info.pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>      }
>  
> +    s = xenstore_read("platform/generation-id", "0:0");
> +    if (s) {

Please use hypervisor coding style here; Interestingly you do so ...

> +        char *end;
> +
> +        config->vm_gid[0] = strtoll(s, &end, 0);
> +        config->vm_gid[1] = 0;
> +        if ( end && end[0] == ':' )

... here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader
  2016-04-06  1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
@ 2016-06-02 13:07   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 13:07 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> With that, xenstore_read() won't need to be done in ACPI code

Except for maybe s/build/install/ in the title, this patch looks fine.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code
  2016-04-06  1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
@ 2016-06-02 13:52   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 13:52 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -481,6 +481,10 @@ struct acpi_config {
>      struct acpi_info acpi_info;
>      uint64_t vm_gid[2];
>      uint32_t table_flags;
> +    struct {
> +        unsigned long acpi_pt_addr;
> +        uint32_t acpi_pt_length;
> +    } pt;

Redundant "acpi" and "pt". (Which btw also holds for the earlier
added acpi_info, as I now realize.) Further please consider also
making the address uint32_t.

> @@ -893,6 +894,15 @@ 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 ) {

Coding style.

Beyond that looks okay.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
  2016-04-06  1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
@ 2016-06-02 14:05   ` Jan Beulich
  2016-06-02 17:18     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 14:05 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> @@ -485,6 +494,10 @@ struct acpi_config {
>          unsigned long acpi_pt_addr;
>          uint32_t acpi_pt_length;
>      } pt;
> +    uint32_t nr_vcpus;
> +    uint8_t  *vcpu_online;
> +    int apic_mode;

Instead of copying those fields, how about simply adding a pointer
to struct hvm_info_table here?

> +    struct acpi_numa numa;

Same for this one - perhaps better a pointer, and an instance of the
structure could then replace all those individual global variables.

> @@ -910,6 +911,16 @@ 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->nr_vcpus = hvm_info->nr_vcpus;
> +    config->vcpu_online = hvm_info->vcpu_online;
> +    config->apic_mode = 1;

Why is this a hard coded 1? It was hvm_info->apic_mode before.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address in hvmloader
  2016-04-06  1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
@ 2016-06-02 14:09   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 14:09 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> @@ -371,41 +370,43 @@ static int construct_secondary_tables(unsigned long *table_ptrs,
>          printf("S4 disabled\n");
>      }
>  
> -    /* 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 )
>      {
> -        ssdt = mem_alloc(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);
> -        if (!tcpa) return -1;
> -        memset(tcpa, 0, sizeof(*tcpa));
> -        table_ptrs[nr_tables++] = (unsigned long)tcpa;
> -
> -        tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
> -        tcpa->header.length    = sizeof(*tcpa);
> -        tcpa->header.revision  = ACPI_2_0_TCPA_REVISION;
> -        fixed_strcpy(tcpa->header.oem_id, ACPI_OEM_ID);
> -        fixed_strcpy(tcpa->header.oem_table_id, ACPI_OEM_TABLE_ID);
> -        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 )
> +        /* TPM TCPA and SSDT. */
> +        if ( (config->tis_hdr[0] == tis_signature[0]) &&
> +             (config->tis_hdr[1] == tis_signature[1]) &&
> +             (config->tis_hdr[2] == tis_signature[2]) )
>          {
> -            tcpa->lasa = virt_to_phys(lasa);
> -            tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
> -            memset(lasa, 0, tcpa->laml);
> -            set_checksum(tcpa,
> -                         offsetof(struct acpi_header, checksum),
> -                         tcpa->header.length);
> +            ssdt = mem_alloc(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);
> +            if (!tcpa) return -1;
> +            memset(tcpa, 0, sizeof(*tcpa));
> +            table_ptrs[nr_tables++] = (unsigned long)tcpa;
> +
> +            tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
> +            tcpa->header.length    = sizeof(*tcpa);
> +            tcpa->header.revision  = ACPI_2_0_TCPA_REVISION;
> +            fixed_strcpy(tcpa->header.oem_id, ACPI_OEM_ID);
> +            fixed_strcpy(tcpa->header.oem_table_id, ACPI_OEM_TABLE_ID);
> +            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 )
> +            {
> +                tcpa->lasa = virt_to_phys(lasa);
> +                tcpa->laml = ACPI_2_0_TCPA_LAML_SIZE;
> +                memset(lasa, 0, tcpa->laml);
> +                set_checksum(tcpa,
> +                             offsetof(struct acpi_header, checksum),
> +                             tcpa->header.length);
> +            }

As it looks, all of this code churn could be avoided by simply
merging the two if()s at the top.

>          }
>      }
> -
> +    

Stray addition of trailing blanks.

> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -911,6 +911,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;
> +
>      config->nr_vcpus = hvm_info->nr_vcpus;
>      config->vcpu_online = hvm_info->vcpu_online;
>      config->apic_mode = 1;
> @@ -921,6 +923,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
>      config->numa.vdistance = vdistance;
>      config->numa.vmemrange = vmemrange;
>  
> +    config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;

Please put these two additions next to each other.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally
  2016-04-06  1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
@ 2016-06-02 14:32   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-02 14:32 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -344,9 +344,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;

Please fix coding style issues as you re-indent code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
@ 2016-06-02 16:26   ` Roger Pau Monné
  2016-06-06 12:03   ` Wei Liu
  2016-06-06 13:29   ` Jan Beulich
  2 siblings, 0 replies; 91+ messages in thread
From: Roger Pau Monné @ 2016-06-02 16:26 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: Stefano Stabellini, Wei Liu, xen-devel

Thanks for looking into this, I've found a couple of issues when compiling 
this with clang.

On Tue, Apr 05, 2016 at 09:25:47PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  tools/libxc/Makefile              |  22 +++-
>  tools/libxc/include/xc_dom.h      |   1 +
>  tools/libxc/xc_acpi.c             | 268 ++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_dom_x86.c          |   7 +
>  tools/libxl/libxl_x86.c           |  19 +--
>  xen/common/libacpi/Makefile       |   5 +-
>  xen/common/libacpi/acpi2_0.h      |   2 +-
>  xen/common/libacpi/build.c        |   2 +-
>  xen/common/libacpi/dsdt_empty.asl |  22 ++++
>  9 files changed, 335 insertions(+), 13 deletions(-)
>  create mode 100644 tools/libxc/xc_acpi.c
>  create mode 100644 xen/common/libacpi/dsdt_empty.asl
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 608404f..9569e54 100644
> +++ b/tools/libxc/xc_acpi.c

Missing license header?

> @@ -0,0 +1,268 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <inttypes.h>
> +#include <assert.h>
> +
> +#include <xen/xen.h>
> +#include <xen/foreign/x86_32.h>
> +#include <xen/foreign/x86_64.h>
> +#include <xen/hvm/hvm_info_table.h>
> +#include <xen/io/protocols.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +#include "xenctrl.h"
> +
> +#include "acpi2_0.h"
> +
> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
> +
> +/* Initial allocation for ACPI tables */
> +#define NUM_ACPI_PAGES  16
> +
> +#define PFN(paddr)  ((paddr) >> PAGE_SHIFT)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[], dsdt_empty[];
> +extern int dsdt_anycpu_len, dsdt_15cpu_len, dsdt_empty_len;
> +
> +static uint64_t alloc_up, alloc_down;
> +static unsigned long base_addr;
> +
> +/* Assumes contiguous physical space */
> +static unsigned long virt_to_phys(void *v)
> +{
> +	return (((unsigned long)v - base_addr) + RESERVED_MEMORY_DYNAMIC_START);
> +}
> +
> +static void *mem_alloc(uint32_t size, uint32_t align)
> +{
> +    uint64_t s, e;
> +
> +    /* Align to at least 16 bytes. */
> +    if ( align < 16 )
> +        align = 16;
> +
> +    s = (alloc_up + align) & ~((uint64_t)align - 1);
> +    e = s + size - 1;
> +
> +    /* TODO: Reallocate memory */
> +    if ((e < s) || (e >= alloc_down)) return NULL;
> +
> +    while ( PFN(alloc_up) != PFN(e) )
> +    {
> +        alloc_up += PAGE_SIZE;
> +    }
> +
> +    alloc_up = e;
> +
> +    return (void *)(unsigned long)s;
> +}
> +
> +static int init_acpi_config(struct xc_dom_image *dom,
> +                            struct acpi_config *config)
> +{
> +    xc_interface *xch = dom->xch;
> +    uint32_t domid = dom->guest_domid;
> +    xc_dominfo_t info;
> +    int i, rc;
> +
> +    memset(config, 0, sizeof(*config));
> +
> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> +
> +    rc = xc_domain_getinfo(xch, domid, 1, &info);
> +    if ( rc < 0 )
> +    {
> +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> +        return rc;
> +    }
> +
> +    config->apic_mode = 1;
> +
> +    if ( dom->nr_vnodes )
> +    {
> +        struct acpi_numa *numa = &config->numa;
> +
> +        numa->vmemrange = calloc(dom->nr_vmemranges,
> +                                 sizeof(*numa->vmemrange));
> +        numa->vdistance = calloc(dom->nr_vnodes,
> +                                 sizeof(*numa->vdistance));
> +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> +                                     sizeof(*numa->vcpu_to_vnode));
> +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> +        {
> +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
> +            free(numa->vmemrange);
> +            free(numa->vdistance);
> +            free(numa->vcpu_to_vnode);
> +            return -ENOMEM;
> +        }
> +
> +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> +                                &numa->nr_vmemranges,
> +                                &config->nr_vcpus, numa->vmemrange,
> +                                numa->vdistance, numa->vcpu_to_vnode);
> +
> +	    if ( rc )
> +        {
> +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
> +            return rc;
> +        }
> +    }
> +    else
> +        config->nr_vcpus = info.max_vcpu_id + 1;
> +
> +    config->vcpu_online = calloc((HVM_MAX_VCPUS + 7) / 8,
> +                                 sizeof(*config->vcpu_online));
> +    if ( config->vcpu_online == NULL )
> +    {
> +        DOMPRINTF("%s: Can't allocate vcpu_online", __FUNCTION__);
> +        return -ENOMEM;
> +    }
> +
> +    for (i=0; i<config->nr_vcpus; i++)
> +        config->vcpu_online[i / 8] |= 1 << (i & 7);
> +
> +    config->mem_ops.alloc = mem_alloc;
> +    config->mem_ops.v2p = virt_to_phys;
> +
> +    return 0;
> +}
> +
> +int xc_dom_build_acpi(struct xc_dom_image *dom)
> +{
> +    struct acpi_config config;
> +    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, *acpi_physical;
> +    void *guest_info_page, *guest_acpi_pages;

guest_acpi_pages, guest_info_page, acpi_physical, extents and acpi_pages 
should be initialized to NULL, and acpi_pages_num to 0.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-06-02 12:40 ` Jan Beulich
@ 2016-06-02 16:37   ` Boris Ostrovsky
  2016-06-03  7:18     ` Roger Pau Monné
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-02 16:37 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, roger.pau

On 06/02/2016 08:40 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> This is an RFC for making hvmloader's ACPI builder available to both the
>> toolstack and the hypervisor, as discussed in
>> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
>>
>> The series
>> * Removes dependency of today's builder on hvmloader interfaces
>> * Makes many of the tables built optionally.
>> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
>> * Builds tables for PVHv2 domU guests in libxc
>>
>> There is still a number of questions about this implementation, thus it's
>> an RFC. Examples of things that need to be discussed are
>>
>> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>>   to make this an option.
>> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>>   tools/firmware/hvmloader/{stdio.h,string.h} 
>> * The builder is compiled into the hypervisor even though currently
>>   there are no users (PVHv2 dom0 will be the one)
> Is that really what we want? I thought we don't really mean to
> build ACPI tables from scratch for Dom0, but rather follow ARM's
> customization approach.

You mean xen/arch/arm/domain_build.c:prepare_acpi()?

The thinking was that customization will be able to make use of this
library. Roger?


>  And if we don't want this, then the
> placement of this now shared code would need reconsidering.

Right. In fact I originally had this as tools/libacpi.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables()
  2016-06-02 12:42   ` Jan Beulich
@ 2016-06-02 16:39     ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-02 16:39 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/02/2016 08:42 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> @@ -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);
>> +}
> I guess later patches will make clear why this is an improvement.
> On its own it doesn't look worthwhile.
>

This is really to make reviewing easier. Not an improvement of any kind.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-06-02 12:54   ` Jan Beulich
@ 2016-06-02 16:54     ` Boris Ostrovsky
  2016-06-03 12:13       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-02 16:54 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> 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.
> So from a mechanical pov the patch looks fine (one remark below),
> but if you move this out from acpi/, who's going to do the setup of
> that structure outside of hvmloader? And if done by another
> entity, how do you mean things to remain in sync? 

Each caller (currently hvmloader and libxc, possibly the hypervisor in
the future) will initialize it. (I think you saw this in the next patch)

> And btw., you're
> still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
> a hvmloader thing, which you just move the reference to inside
> acpi/.

It's not an hvmloader thing, it's the ACPI thing: this is the address
that should match DSDT's description.

Perhaps I should have a script that extracts this address from dsdt.asl
and then make libacpi return it instead of hardcoding it in callers' code.

-boris

>
>> @@ -619,20 +597,12 @@ 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->acpi_info) )
>>          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;
>> -    }
>> +    memcpy((struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS,
>> +           &config->acpi_info,
>> +           sizeof(config->acpi_info));
> I'd prefer structure assignment to be used in cases like this, as
> that lets the compiler check that the types match.
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code
  2016-06-02 13:03   ` Jan Beulich
@ 2016-06-02 17:01     ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-02 17:01 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/02/2016 09:03 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> --- a/tools/firmware/hvmloader/acpi/build.c
>> +++ b/tools/firmware/hvmloader/acpi/build.c
>> @@ -448,32 +448,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->acpi_info.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->acpi_info.vm_gid_addr = virt_to_phys(buf);
> Here things get interesting: If different entities are responsible for
> filling different parts of acpi_info, I think this should be documented
> in the structure definition.

There are IN and OUT parameters in acpi_info, and this is not
documented. It should be.

>  Can't this be left to the entity initializing
> that structure?

vm_gid_addr is calculated by (what will be) libacpi, it's an OUT parameter.


-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
  2016-06-02 14:05   ` Jan Beulich
@ 2016-06-02 17:18     ` Boris Ostrovsky
  2016-06-03 12:16       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-02 17:18 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/02/2016 10:05 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> @@ -485,6 +494,10 @@ struct acpi_config {
>>          unsigned long acpi_pt_addr;
>>          uint32_t acpi_pt_length;
>>      } pt;
>> +    uint32_t nr_vcpus;
>> +    uint8_t  *vcpu_online;
>> +    int apic_mode;
> Instead of copying those fields, how about simply adding a pointer
> to struct hvm_info_table here?
>
>> +    struct acpi_numa numa;
> Same for this one - perhaps better a pointer, and an instance of the
> structure could then replace all those individual global variables.
>
>> @@ -910,6 +911,16 @@ 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->nr_vcpus = hvm_info->nr_vcpus;
>> +    config->vcpu_online = hvm_info->vcpu_online;
>> +    config->apic_mode = 1;
> Why is this a hard coded 1? It was hvm_info->apic_mode before.

I think that's because hvm_info is initialized in libxl very late, after
ACPI is already set. Let me see whether there was a reason for this
order and if there wasn't then yes, I can point to hvm_info.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-06-02 16:37   ` Boris Ostrovsky
@ 2016-06-03  7:18     ` Roger Pau Monné
  2016-06-03 10:08       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Roger Pau Monné @ 2016-06-03  7:18 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: Jan Beulich, xen-devel

On Thu, Jun 02, 2016 at 12:37:27PM -0400, Boris Ostrovsky wrote:
> On 06/02/2016 08:40 AM, Jan Beulich wrote:
> >>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> >> This is an RFC for making hvmloader's ACPI builder available to both the
> >> toolstack and the hypervisor, as discussed in
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
> >>
> >> The series
> >> * Removes dependency of today's builder on hvmloader interfaces
> >> * Makes many of the tables built optionally.
> >> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
> >> * Builds tables for PVHv2 domU guests in libxc
> >>
> >> There is still a number of questions about this implementation, thus it's
> >> an RFC. Examples of things that need to be discussed are
> >>
> >> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
> >>   to make this an option.
> >> * Not sure about header files, especially xen/common/libacpi/x86.h and 
> >>   tools/firmware/hvmloader/{stdio.h,string.h} 
> >> * The builder is compiled into the hypervisor even though currently
> >>   there are no users (PVHv2 dom0 will be the one)
> > Is that really what we want? I thought we don't really mean to
> > build ACPI tables from scratch for Dom0, but rather follow ARM's
> > customization approach.
> 
> You mean xen/arch/arm/domain_build.c:prepare_acpi()?
> 
> The thinking was that customization will be able to make use of this
> library. Roger?

Yes, I (at least) thought that the same library would be used for crafting 
the tables for DomU or customizing the ones presented to Dom0 so that all 
the ACPI code resides at the same place. I was planning to place this code 
in the Xen .init section, so that it's gone after Dom0 construction.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
  2016-06-03  7:18     ` Roger Pau Monné
@ 2016-06-03 10:08       ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 10:08 UTC (permalink / raw)
  To: Roger Pau Monné, Boris Ostrovsky; +Cc: xen-devel

>>> On 03.06.16 at 09:18, <roger.pau@citrix.com> wrote:
> On Thu, Jun 02, 2016 at 12:37:27PM -0400, Boris Ostrovsky wrote:
>> On 06/02/2016 08:40 AM, Jan Beulich wrote:
>> >>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> >> This is an RFC for making hvmloader's ACPI builder available to both the
>> >> toolstack and the hypervisor, as discussed in
>> >> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
>> >>
>> >> The series
>> >> * Removes dependency of today's builder on hvmloader interfaces
>> >> * Makes many of the tables built optionally.
>> >> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
>> >> * Builds tables for PVHv2 domU guests in libxc
>> >>
>> >> There is still a number of questions about this implementation, thus it's
>> >> an RFC. Examples of things that need to be discussed are
>> >>
>> >> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>> >>   to make this an option.
>> >> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>> >>   tools/firmware/hvmloader/{stdio.h,string.h} 
>> >> * The builder is compiled into the hypervisor even though currently
>> >>   there are no users (PVHv2 dom0 will be the one)
>> > Is that really what we want? I thought we don't really mean to
>> > build ACPI tables from scratch for Dom0, but rather follow ARM's
>> > customization approach.
>> 
>> You mean xen/arch/arm/domain_build.c:prepare_acpi()?
>> 
>> The thinking was that customization will be able to make use of this
>> library. Roger?
> 
> Yes, I (at least) thought that the same library would be used for crafting 
> the tables for DomU or customizing the ones presented to Dom0 so that all 
> the ACPI code resides at the same place.

Okay, I can't see much code sharing between customization and
creation from scratch, but I can certainly be convinced otherwise.

> I was planning to place this code 
> in the Xen .init section, so that it's gone after Dom0 construction.

Sure, that's a requirement in any case (just like is the case for libelf).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-06-02 16:54     ` Boris Ostrovsky
@ 2016-06-03 12:13       ` Jan Beulich
  2016-06-03 14:42         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 12:13 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 02.06.16 at 18:54, <boris.ostrovsky@oracle.com> wrote:
> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>> 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.
>> So from a mechanical pov the patch looks fine (one remark below),
>> but if you move this out from acpi/, who's going to do the setup of
>> that structure outside of hvmloader? And if done by another
>> entity, how do you mean things to remain in sync? 
> 
> Each caller (currently hvmloader and libxc, possibly the hypervisor in
> the future) will initialize it. (I think you saw this in the next patch)

I don't think I've made it to patches touching libxc yet.

That aside, what about the "things to remain in sync" part?

>> And btw., you're
>> still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
>> a hvmloader thing, which you just move the reference to inside
>> acpi/.
> 
> It's not an hvmloader thing, it's the ACPI thing: this is the address
> that should match DSDT's description.

As to matching - sure. But it's not libacpi to determine that address.
Guest memory layout gets determined elsewhere (and might differ
between HVM and HVMlite, as well as between DomU and Dom0),
and that's where the sole definition of that address should imo live.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
  2016-06-02 17:18     ` Boris Ostrovsky
@ 2016-06-03 12:16       ` Jan Beulich
  2016-06-03 14:49         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 12:16 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 02.06.16 at 19:18, <boris.ostrovsky@oracle.com> wrote:
> On 06/02/2016 10:05 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>> @@ -485,6 +494,10 @@ struct acpi_config {
>>>          unsigned long acpi_pt_addr;
>>>          uint32_t acpi_pt_length;
>>>      } pt;
>>> +    uint32_t nr_vcpus;
>>> +    uint8_t  *vcpu_online;
>>> +    int apic_mode;
>> Instead of copying those fields, how about simply adding a pointer
>> to struct hvm_info_table here?
>>
>>> +    struct acpi_numa numa;
>> Same for this one - perhaps better a pointer, and an instance of the
>> structure could then replace all those individual global variables.
>>
>>> @@ -910,6 +911,16 @@ 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->nr_vcpus = hvm_info->nr_vcpus;
>>> +    config->vcpu_online = hvm_info->vcpu_online;
>>> +    config->apic_mode = 1;
>> Why is this a hard coded 1? It was hvm_info->apic_mode before.
> 
> I think that's because hvm_info is initialized in libxl very late, after
> ACPI is already set. Let me see whether there was a reason for this
> order and if there wasn't then yes, I can point to hvm_info.

No matter when libxl initializes hvm_info, it necessarily happens
before the guest starts. And we're inside the running guest here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-06-03 12:13       ` Jan Beulich
@ 2016-06-03 14:42         ` Boris Ostrovsky
  2016-06-03 14:55           ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 14:42 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/03/2016 08:13 AM, Jan Beulich wrote:
>>>> On 02.06.16 at 18:54, <boris.ostrovsky@oracle.com> wrote:
>> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>> 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.
>>> So from a mechanical pov the patch looks fine (one remark below),
>>> but if you move this out from acpi/, who's going to do the setup of
>>> that structure outside of hvmloader? And if done by another
>>> entity, how do you mean things to remain in sync? 
>>
>> Each caller (currently hvmloader and libxc, possibly the hypervisor in
>> the future) will initialize it. (I think you saw this in the next patch)
> 
> I don't think I've made it to patches touching libxc yet.
> 
> That aside, what about the "things to remain in sync" part?


I was referring to your comment for patch 3 where you said

  If different entities are responsible for filling different parts
  of acpi_info, I think this should be documented in the structure
  definition

and my response was that acpi_info has IN and OUT fields that I need to
document. If that's not answering your question about things remaining
in sync then I guess I don't understand the question.


> 
>>> And btw., you're
>>> still not fully decoupling things: ACPI_INFO_PHYSICAL_ADDRESS is
>>> a hvmloader thing, which you just move the reference to inside
>>> acpi/.
>>
>> It's not an hvmloader thing, it's the ACPI thing: this is the address
>> that should match DSDT's description.
> 
> As to matching - sure. But it's not libacpi to determine that address.
> Guest memory layout gets determined elsewhere (and might differ
> between HVM and HVMlite, as well as between DomU and Dom0),
> and that's where the sole definition of that address should imo live.

Right, but I figured that since ASL files live in acpi/ (libacpi/ in the
future) then ACPI_INFO_PHYSICAL_ADDRESS should also be defined here.

I used  ACPI_INFO_PHYSICAL_ADDRESS for HVMlite guests as well (you will
see it in a later patch for libxc) but really I don't need to: those
guests use only DSDT header (dsdt_empty.asl) and don't refer to this
address in their ASL file. In fact, they don't need acpi_info at all.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader
  2016-06-03 12:16       ` Jan Beulich
@ 2016-06-03 14:49         ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 14:49 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/03/2016 08:16 AM, Jan Beulich wrote:
>>>> On 02.06.16 at 19:18, <boris.ostrovsky@oracle.com> wrote:
>> On 06/02/2016 10:05 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>> @@ -485,6 +494,10 @@ struct acpi_config {
>>>>          unsigned long acpi_pt_addr;
>>>>          uint32_t acpi_pt_length;
>>>>      } pt;
>>>> +    uint32_t nr_vcpus;
>>>> +    uint8_t  *vcpu_online;
>>>> +    int apic_mode;
>>> Instead of copying those fields, how about simply adding a pointer
>>> to struct hvm_info_table here?
>>>
>>>> +    struct acpi_numa numa;
>>> Same for this one - perhaps better a pointer, and an instance of the
>>> structure could then replace all those individual global variables.
>>>
>>>> @@ -910,6 +911,16 @@ 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->nr_vcpus = hvm_info->nr_vcpus;
>>>> +    config->vcpu_online = hvm_info->vcpu_online;
>>>> +    config->apic_mode = 1;
>>> Why is this a hard coded 1? It was hvm_info->apic_mode before.
>> I think that's because hvm_info is initialized in libxl very late, after
>> ACPI is already set. Let me see whether there was a reason for this
>> order and if there wasn't then yes, I can point to hvm_info.
> No matter when libxl initializes hvm_info, it necessarily happens
> before the guest starts. And we're inside the running guest here.

At this point -- yes. However, this is (partly) done in preparation to
making this code available to libxc for building HVMlite guests, so this
will run before the guest has started.

In any case, I suspect I may be able to move ACPI building in libxl to
after hvm_info is initialized.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-06-03 14:42         ` Boris Ostrovsky
@ 2016-06-03 14:55           ` Jan Beulich
  2016-06-03 15:29             ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 14:55 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 03.06.16 at 16:42, <boris.ostrovsky@oracle.com> wrote:
> On 06/03/2016 08:13 AM, Jan Beulich wrote:
>>>>> On 02.06.16 at 18:54, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/02/2016 08:54 AM, Jan Beulich wrote:
>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>> 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.
>>>> So from a mechanical pov the patch looks fine (one remark below),
>>>> but if you move this out from acpi/, who's going to do the setup of
>>>> that structure outside of hvmloader? And if done by another
>>>> entity, how do you mean things to remain in sync? 
>>>
>>> Each caller (currently hvmloader and libxc, possibly the hypervisor in
>>> the future) will initialize it. (I think you saw this in the next patch)
>> 
>> I don't think I've made it to patches touching libxc yet.
>> 
>> That aside, what about the "things to remain in sync" part?
> 
> 
> I was referring to your comment for patch 3 where you said
> 
>   If different entities are responsible for filling different parts
>   of acpi_info, I think this should be documented in the structure
>   definition
> 
> and my response was that acpi_info has IN and OUT fields that I need to
> document. If that's not answering your question about things remaining
> in sync then I guess I don't understand the question.

Well, first of all the definition of this structure will likely need to
become part of the public interface, so that all consumers of it
(hvmloader, libxc, and maybe the domain builder) can access it.
Which then raises the question of how to deal with updates to
that structure: We should avoid making this part of the stable
public interface, but limiting it to Xen and tools would exclude
hvmloader.

Perhaps the follow-on thing - consumers living in far apart
portions of the tree, and hence it's easy to forget one if an
adjustment is being done - isn't that much different from e.g.
touching code consumed by qemu. But then again we all know
that some things at the xen/tools vs qemu boundary are
pretty fragile, and I'd like to avoid such here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code
  2016-06-03 14:55           ` Jan Beulich
@ 2016-06-03 15:29             ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 15:29 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/03/2016 10:55 AM, Jan Beulich wrote:
> Well, first of all the definition of this structure will likely need to
> become part of the public interface, so that all consumers of it
> (hvmloader, libxc, and maybe the domain builder) can access it.
> Which then raises the question of how to deal with updates to
> that structure: We should avoid making this part of the stable
> public interface, but limiting it to Xen and tools would exclude
> hvmloader.
>
> Perhaps the follow-on thing - consumers living in far apart
> portions of the tree, and hence it's easy to forget one if an
> adjustment is being done - isn't that much different from e.g.
> touching code consumed by qemu. But then again we all know
> that some things at the xen/tools vs qemu boundary are
> pretty fragile, and I'd like to avoid such here.
>

We can add version to acpi_build_tables() call (or to struct acpi_config)?

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code
  2016-04-06  1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
@ 2016-06-03 16:03   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 16:03 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -306,6 +306,9 @@ struct acpi_20_waet {
>  
>  #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
>  
> +/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
> +#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000UL

As said in the context of another patch - I don't think this belongs
here, the more that the consumer is in hvmloader/util.c. This is
genuinely a decision of the rest of the firmware (i.e. hvmloader
here). Plus, even if it was to be determined by libacpi, this would
be the wrong header- here there are supposed to be only ACPI
interface definitions.

The same then of course applies to ACPI_TIS_HDR_ADDRESS.

> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -65,8 +65,7 @@ extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
>  #define HVMLOADER_PHYSICAL_ADDRESS    0x00100000
>  /* Special BIOS mappings, etc. are allocated from here upwards... */
>  #define RESERVED_MEMBASE              0xFC000000
> -/* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
> -#define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
> +
>  #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>  #define RESERVED_MEMORY_DYNAMIC_END   0xFE000000

The lower context here actually supports what I've said above. So
I think that itsem should stay here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic()
  2016-04-06  1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
@ 2016-06-03 16:14   ` Jan Beulich
  2016-06-03 17:50     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 16:14 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: Andrew Cooper, xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1133,6 +1133,9 @@ void vlapic_adjust_i8259_target(struct domain *d)
>  {
>      struct vcpu *v;
>  
> +    if ( !has_vpic(d) )
> +       return;

Considering the title of the patch (which doesn't match the function
you alter) - wouldn't this better go into __vlapic_accept_pic_intr()?
It missing here I have more problems to see any harm than from it
missing there. (Arguably _also_ putting it here then would have the
benefit of avoiding a for_each_vcpu() loop.)

In any event this looks like a relatively independent change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests
  2016-04-06  1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
@ 2016-06-03 16:18   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-03 16:18 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: Andrew Cooper, xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> PVH guests may request LAPIC emulation (and nothing else)
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

This looks okay, except that I'd like to avoid the use of PVH here
(in the description and at least on code comment) - please make
this PVHv2 to avoid confusion with the original PVH code that's still
there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic()
  2016-06-03 16:14   ` Jan Beulich
@ 2016-06-03 17:50     ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-03 17:50 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, xen-devel, Keir Fraser, roger.pau

On 06/03/2016 12:14 PM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> --- a/xen/arch/x86/hvm/vlapic.c
>> +++ b/xen/arch/x86/hvm/vlapic.c
>> @@ -1133,6 +1133,9 @@ void vlapic_adjust_i8259_target(struct domain *d)
>>  {
>>      struct vcpu *v;
>>  
>> +    if ( !has_vpic(d) )
>> +       return;
> Considering the title of the patch (which doesn't match the function
> you alter) - wouldn't this better go into __vlapic_accept_pic_intr()?
> It missing here I have more problems to see any harm than from it
> missing there. (Arguably _also_ putting it here then would have the
> benefit of avoiding a for_each_vcpu() loop.)

One of the reasons I put it here was exactly to avoid this loop. It also
(implicitly) prevented us from going down to
pt_adjust_global_vcpu_target(). In addition, we wouldn't need to check
for IOAPIC presence.

I guess I should add has_vpic(), has_vpit() and has_ioapic() in all
these places.

> In any event this looks like a relatively independent change.

Right. Once ACPI became available to the  PVHv2 guest I immediately
tripped here (because the guest started seeing APIC). So in principle I
can submit this as standalone patch.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables
  2016-04-06  1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
@ 2016-06-06 10:48   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 10:48 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- 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_config *config)
>      else
>          lapic = (struct acpi_20_madt_lapic *)(madt + 1);
>  
> -    config->acpi_info.madt_lapic0_addr = (uint32_t)lapic;
> +    config->acpi_info.madt_lapic0_addr = virt_to_phys(lapic);

While perhaps it doesn't matter much, considering that hvmloader
already has virt_to_phys() I think earlier patches touching lines
like the one above would better switch to using it right away,
instead of using (or even introducing) explicit casts. That'll reduce
code churn and make the history of the changes to the affected
lines more clear.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-04-06  1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
@ 2016-06-06 11:04   ` Jan Beulich
  2016-06-06 14:20     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 11:04 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> ACPI sources will be available to various component which will build
> them according to their own rules. ACPI directory will only build
> sources.

"build sources" is kind of contradictory. How about "build intermediate
files"?

> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -20,8 +20,6 @@
>  XEN_ROOT = $(CURDIR)/../../..
>  include $(XEN_ROOT)/tools/firmware/Rules.mk
>  
> -SUBDIRS := acpi
> -
>  # The HVM loader is started in 32-bit mode at the address below:
>  LOADADDR = 0x100000
>  
> @@ -33,10 +31,18 @@ CFLAGS += $(CFLAGS_xeninclude)
>  # We mustn't use tools-only public interfaces.
>  CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>  
> +# ACPI table builder
> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
> +vpath %.c $(ACPI_PATH)

Please don't - this would preclude having files with the same names
in hvmloader/ and (the future) libacpi/.

> @@ -95,7 +101,11 @@ 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
> +.NOTPARALLEL: $(ACPI_SRC)

And very clearly we will want to avoid the use of .NOTPARALLEL
anywhere in our trees.

> +$(ACPI_SRC):
> +	$(MAKE) -C $(ACPI_PATH)

The more that you can't do this from multiple points in the tree. Did
you consider e.g. symlinking the subtree into the multiple parent
trees?

> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -23,7 +23,7 @@ OBJS  = $(patsubst %.c,%.o,$(C_SRC))
>  CFLAGS += $(CFLAGS_xeninclude)
>  
>  vpath iasl $(PATH)
> -all: acpi.a
> +all: $(C_SRC) ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h

Why $(C_CRC)? Clearly build.c and static_tables.c don't need
listing here.

> --- a/tools/firmware/rombios/32bit/Makefile
> +++ b/tools/firmware/rombios/32bit/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
>  
>  TARGET = 32bitbios_flat.h
>  
> -CFLAGS += $(CFLAGS_xeninclude) -I..
> +CFLAGS += $(CFLAGS_xeninclude) -I.. -I$(XEN_ROOT)/tools/firmware/hvmloader/acpi/

As long as nothing speaks against doing so, I think such references
are better done in a relative manner. That way moving the entire
build tree won't affect the command lines passed to build tools.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h
  2016-04-06  1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
@ 2016-06-06 11:31   ` Jan Beulich
  2016-06-06 15:08     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 11:31 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> Users of ACPI builder will need to provide their own implemetations of
> strncpy(), memcpy, memset() and printf declared in stdio.h and string.h.
> For hvmloader we provide those two as wrappers around utul.h.
> 
> Some x86-specific definitions move to ACPI builder's x86.h file so that
> users won't have to re-define them themselves.
> 
> Explicitly define a few things that are currently available to to build.c
> via util.h.

Considering the first paragraph, this last sentence was more
confusing than clarifying to me: I expected util.h to get changed
in some way, but aiui having gone through the entire patch this is
just a (very different) re-statement of what you've said already.

>  create mode 100644 tools/firmware/hvmloader/acpi/x86.h
>  create mode 100644 tools/firmware/hvmloader/stdio.h
>  create mode 100644 tools/firmware/hvmloader/string.h

I have to admit that I'm not really looking forward to see the
hypervisor gain a file stdio.h. I'm also not convinced libxc'e
planned use of the libacpi/ would fit well with uses of printf() in
that subtree.

> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -36,7 +36,7 @@ ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
>  vpath %.c $(ACPI_PATH)
>  ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
> dsdt_anycpu_qemu_xen.c build.c
>  ACPI_SRC = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
> -CFLAGS += -I$(ACPI_PATH)
> +CFLAGS += -I$(ACPI_PATH) -I.

With the subtree symlink approach, such an addition could then be
limited to just the libacpi/ files, i.e. not affecting core hvmloader ones.

> @@ -30,6 +32,12 @@
>  
>  #define align16(sz)        (((sz) + 15) & ~15)
>  #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
> +#ifndef offsetof
> +#define offsetof(t, m) ((unsigned long)&((t *)0)->m)
> +#endif
> +#ifndef NULL
> +#define NULL ((void *)0)
> +#endif

These should be provided by the consumer too, I would say
(stddef.h).

> @@ -41,6 +49,11 @@ extern struct acpi_20_waet Waet;
>  /* Number of processor objects in the chosen DSDT. */
>  static unsigned int nr_processor_objects;
>  
> +static inline int __test_bit(unsigned int b, void *p)
> +{
> +    return !!(((uint8_t *)p)[b>>3] & (1u<<(b&7)));
> +}

This one too, without the leading underscores (bitops.h or some
other sbtraction). All three potential consumers of this code already
have test_bit().

> @@ -238,8 +251,6 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
>          memory++;
>      }
>  
> -    ASSERT(((unsigned long)memory) - ((unsigned long)p) == size);

I think this was put here for a reason, and hence shouldn't be
removed without good reason (I wouldn't count ASSERT() not being
available as one).

> --- /dev/null
> +++ b/tools/firmware/hvmloader/acpi/x86.h
> @@ -0,0 +1,14 @@
> +#ifndef __ACPI_X86_H__
> +#define __ACPI_X86_H__
> +
> +#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 */

Only the latter of those last two is used by build.c. Please limit what
you move to the very minimum. I.e. IOAPIC_VERSION shouldn't move
either imo (and I notice there's a disconnect between it and the
hypervisor's VIOAPIC_VERSION_ID, but that's a pre-existing issue).

> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -24,6 +24,7 @@
>  #include "config.h"
>  #include "pci_regs.h"
>  #include "apic_regs.h"
> +#include "x86.h"

Looking at an inclusion point like this, it is completely unclear that this
comes from libacpi/. One more argument in favor of keeping the
subtree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
  2016-06-02 16:26   ` Roger Pau Monné
@ 2016-06-06 12:03   ` Wei Liu
  2016-06-06 15:15     ` Boris Ostrovsky
  2016-06-06 13:29   ` Jan Beulich
  2 siblings, 1 reply; 91+ messages in thread
From: Wei Liu @ 2016-06-06 12:03 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: roger.pau, Wei Liu, Stefano Stabellini, xen-devel

On Tue, Apr 05, 2016 at 09:25:47PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  tools/libxc/Makefile              |  22 +++-
>  tools/libxc/include/xc_dom.h      |   1 +
>  tools/libxc/xc_acpi.c             | 268 ++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_dom_x86.c          |   7 +
>  tools/libxl/libxl_x86.c           |  19 +--
>  xen/common/libacpi/Makefile       |   5 +-
>  xen/common/libacpi/acpi2_0.h      |   2 +-
>  xen/common/libacpi/build.c        |   2 +-
>  xen/common/libacpi/dsdt_empty.asl |  22 ++++
>  9 files changed, 335 insertions(+), 13 deletions(-)
>  create mode 100644 tools/libxc/xc_acpi.c
>  create mode 100644 xen/common/libacpi/dsdt_empty.asl
> 

I've only done a very rough review.

> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 608404f..9569e54 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -79,6 +79,26 @@ GUEST_SRCS-y += $(ELF_SRCS-y)
>  $(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
>  $(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
>  
> +ACPI_PATH = $(XEN_ROOT)/xen/common/libacpi
> +vpath %.c $(ACPI_PATH)
> +ACPI_FILES  = dsdt_anycpu.c dsdt_15cpu.c static_tables.c
> +ACPI_FILES += dsdt_anycpu_qemu_xen.c dsdt_empty.c build.c
> +ACPI_SRCS = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
> +
> +.NOTPARALLEL: $(ACPI_SRCS)

Why is this needed?

> +$(ACPI_SRCS):
> +	make -C $(ACPI_PATH)
> +
> +$(patsubst %.c,%.o,$(ACPI_SRCS)): CFLAGS += -I$(ACPI_PATH)
> +$(patsubst %.c,%.opic,$(ACPI_SRCS)): CFLAGS += -I$(ACPI_PATH)
> +xc_acpi.o: CFLAGS += -I$(ACPI_PATH)
> +xc_acpi.opic: CFLAGS += -I$(ACPI_PATH)
> +
> +GUEST_SRCS-y += $(ACPI_FILES)
> +
> +$(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
> +$(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
> +
>  # new domain builder
>  GUEST_SRCS-y                 += xc_dom_core.c xc_dom_boot.c
>  GUEST_SRCS-y                 += xc_dom_elfloader.c
> @@ -89,7 +109,7 @@ GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_armzimageloader.c
>  GUEST_SRCS-y                 += xc_dom_binloader.c
>  GUEST_SRCS-y                 += xc_dom_compat_linux.c
>  
> -GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c
> +GUEST_SRCS-$(CONFIG_X86)     += xc_dom_x86.c xc_acpi.c
>  GUEST_SRCS-$(CONFIG_X86)     += xc_cpuid_x86.c
>  GUEST_SRCS-$(CONFIG_ARM)     += xc_dom_arm.c
>  
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6ebe946..3842fb1 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -407,6 +407,7 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image *dom, xen_pfn_t first,
>                                   xen_pfn_t count, xen_pfn_t *count_out);
>  void xc_dom_unmap_one(struct xc_dom_image *dom, xen_pfn_t pfn);
>  void xc_dom_unmap_all(struct xc_dom_image *dom);
> +int xc_dom_build_acpi(struct xc_dom_image *dom);
>  
>  static inline void *xc_dom_seg_to_ptr_pages(struct xc_dom_image *dom,
>                                        struct xc_dom_seg *seg,
> diff --git a/tools/libxc/xc_acpi.c b/tools/libxc/xc_acpi.c
> new file mode 100644
> index 0000000..3173d49
> --- /dev/null
> +++ b/tools/libxc/xc_acpi.c
> @@ -0,0 +1,268 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <inttypes.h>
> +#include <assert.h>
> +
> +#include <xen/xen.h>
> +#include <xen/foreign/x86_32.h>
> +#include <xen/foreign/x86_64.h>
> +#include <xen/hvm/hvm_info_table.h>
> +#include <xen/io/protocols.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +#include "xenctrl.h"
> +
> +#include "acpi2_0.h"
> +
> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
> +
> +/* Initial allocation for ACPI tables */
> +#define NUM_ACPI_PAGES  16
> +
> +#define PFN(paddr)  ((paddr) >> PAGE_SHIFT)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[], dsdt_empty[];
> +extern int dsdt_anycpu_len, dsdt_15cpu_len, dsdt_empty_len;
> +
> +static uint64_t alloc_up, alloc_down;
> +static unsigned long base_addr;
> +
> +/* Assumes contiguous physical space */
> +static unsigned long virt_to_phys(void *v)
> +{
> +	return (((unsigned long)v - base_addr) + RESERVED_MEMORY_DYNAMIC_START);
> +}
> +
> +static void *mem_alloc(uint32_t size, uint32_t align)
> +{
> +    uint64_t s, e;
> +
> +    /* Align to at least 16 bytes. */
> +    if ( align < 16 )
> +        align = 16;
> +
> +    s = (alloc_up + align) & ~((uint64_t)align - 1);
> +    e = s + size - 1;
> +
> +    /* TODO: Reallocate memory */
> +    if ((e < s) || (e >= alloc_down)) return NULL;
> +
> +    while ( PFN(alloc_up) != PFN(e) )
> +    {
> +        alloc_up += PAGE_SIZE;
> +    }
> +
> +    alloc_up = e;
> +
> +    return (void *)(unsigned long)s;
> +}
> +
> +static int init_acpi_config(struct xc_dom_image *dom,
> +                            struct acpi_config *config)
> +{
> +    xc_interface *xch = dom->xch;
> +    uint32_t domid = dom->guest_domid;
> +    xc_dominfo_t info;
> +    int i, rc;
> +
> +    memset(config, 0, sizeof(*config));
> +
> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> +
> +    rc = xc_domain_getinfo(xch, domid, 1, &info);
> +    if ( rc < 0 )
> +    {
> +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> +        return rc;
> +    }
> +
> +    config->apic_mode = 1;
> +
> +    if ( dom->nr_vnodes )
> +    {
> +        struct acpi_numa *numa = &config->numa;
> +
> +        numa->vmemrange = calloc(dom->nr_vmemranges,
> +                                 sizeof(*numa->vmemrange));
> +        numa->vdistance = calloc(dom->nr_vnodes,
> +                                 sizeof(*numa->vdistance));
> +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> +                                     sizeof(*numa->vcpu_to_vnode));
> +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> +        {
> +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
> +            free(numa->vmemrange);
> +            free(numa->vdistance);
> +            free(numa->vcpu_to_vnode);
> +            return -ENOMEM;
> +        }
> +
> +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> +                                &numa->nr_vmemranges,
> +                                &config->nr_vcpus, numa->vmemrange,
> +                                numa->vdistance, numa->vcpu_to_vnode);
> +
> +	    if ( rc )
> +        {
> +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
> +            return rc;
> +        }
> +    }
> +    else
> +        config->nr_vcpus = info.max_vcpu_id + 1;

This looks wrong, at least it is not immediately clear why you would
want to do this.

> +
> +    config->vcpu_online = calloc((HVM_MAX_VCPUS + 7) / 8,
> +                                 sizeof(*config->vcpu_online));
> +    if ( config->vcpu_online == NULL )
> +    {
> +        DOMPRINTF("%s: Can't allocate vcpu_online", __FUNCTION__);
> +        return -ENOMEM;
> +    }
> +
> +    for (i=0; i<config->nr_vcpus; i++)

Coding style.

> +        config->vcpu_online[i / 8] |= 1 << (i & 7);
> +
> +    config->mem_ops.alloc = mem_alloc;
> +    config->mem_ops.v2p = virt_to_phys;
> +
> +    return 0;
> +}
> +
> +int xc_dom_build_acpi(struct xc_dom_image *dom)
> +{
> +    struct acpi_config config;
> +    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, *acpi_physical;
> +    void *guest_info_page, *guest_acpi_pages;
> +

Need to initialise these to NULL and 0 in case you take the exit path
earlier.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  2016-04-06  1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
@ 2016-06-06 12:58   ` Jan Beulich
  2016-06-06 15:46     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 12:58 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -490,6 +490,11 @@ struct acpi_numa {
>      xen_vmemrange_t *vmemrange;
>  };
>  
> +struct acpi_mem_ops {
> +    void *(*alloc)(uint32_t size, uint32_t align);
> +    unsigned long (*v2p)(void *v);
> +};

As before, I think this is the wrong header for such stuff.

And then I think I agree with the allocation hook (or otherwise the
too generic name would need to be changed), but I don't think I
agree with the v2p one. Instead I think the consumer should
provide a suitable virt_to_phys(): That's already the case for
hvmloader, should be trivial for libxc. And as long as we provide
Dom0 with a 1:1 machine/physical addresses, the existing one in
the hypervisor would do too.

At the very least alternatively, to reduce code churn, patch order
should be changed, so that you don't touch again all the lines that
you made use virt_to_phys() just a patch or two ago.

Plus I think the allocation hook should be accompanied by a
freeing one, even if for now this may not be used. Iirc there are
cases where space gets allocated without being retained, not
getting freed just because the simplistic allocator can't handle
such.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-04-06  1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
@ 2016-06-06 13:05   ` Jan Beulich
  2016-06-06 16:09     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 13:05 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>  .gitignore                                                        | 8 ++++----
>  tools/firmware/hvmloader/Makefile                                 | 3 +--
>  tools/firmware/hvmloader/smbios.c                                 | 1 +
>  tools/firmware/rombios/32bit/Makefile                             | 2 +-
>  tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
>  .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
>  .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
>  17 files changed, 11 insertions(+), 11 deletions(-)

As mentioned before, new placement subject to determination
whether this is to eventually be used by the hypervisor.

> --- a/tools/firmware/hvmloader/smbios.c
> +++ b/tools/firmware/hvmloader/smbios.c
> @@ -24,6 +24,7 @@
>  #include <xen/version.h>
>  #include "smbios_types.h"
>  #include "util.h"
> +#include "acpi2_0.h"
>  #include "hypercall.h"
>  #include <xen/hvm/hvm_xs_strings.h>

This change doesn't seem to belong here (since you only move
around files, and adjustments get done solely to makefiles).

> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/xen/common/libacpi/Makefile
> @@ -14,13 +14,13 @@
>  # this program; If not, see <http://www.gnu.org/licenses/>.
>  #
>  
> -XEN_ROOT = $(CURDIR)/../../../..
> -include $(XEN_ROOT)/tools/firmware/Rules.mk
> +XEN_ROOT = $(CURDIR)/../../..
> +include $(XEN_ROOT)/Config.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))
>  
> -CFLAGS += $(CFLAGS_xeninclude)
> +CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include

Where would this now get consumed? This appears to be a tools/
only setting, which should thus no longer be needed here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
  2016-06-02 16:26   ` Roger Pau Monné
  2016-06-06 12:03   ` Wei Liu
@ 2016-06-06 13:29   ` Jan Beulich
  2016-06-06 16:59     ` Boris Ostrovsky
  2 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 13:29 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- /dev/null
> +++ b/tools/libxc/xc_acpi.c
> @@ -0,0 +1,268 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <inttypes.h>
> +#include <assert.h>
> +
> +#include <xen/xen.h>
> +#include <xen/foreign/x86_32.h>
> +#include <xen/foreign/x86_64.h>

Why are these two needed here? The code here shouldn't care
about the mode the guest may later want to run in.

> +#include <xen/hvm/hvm_info_table.h>
> +#include <xen/io/protocols.h>
> +
> +#include "xg_private.h"
> +#include "xc_dom.h"
> +#include "xenctrl.h"
> +
> +#include "acpi2_0.h"
> +
> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
> +
> +/* Initial allocation for ACPI tables */
> +#define NUM_ACPI_PAGES  16

With which other definitions do these three need to remain in sync?

> +#define PFN(paddr)  ((paddr) >> PAGE_SHIFT)
> +
> +extern unsigned char dsdt_anycpu[], dsdt_15cpu[], dsdt_empty[];

const

> +extern int dsdt_anycpu_len, dsdt_15cpu_len, dsdt_empty_len;

And even these may want to be const (and certainly unsigned).

> +static int init_acpi_config(struct xc_dom_image *dom,
> +                            struct acpi_config *config)
> +{
> +    xc_interface *xch = dom->xch;
> +    uint32_t domid = dom->guest_domid;
> +    xc_dominfo_t info;
> +    int i, rc;
> +
> +    memset(config, 0, sizeof(*config));
> +
> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;

What good does an empty DSDT do? (Perhaps this question is a
result of there not being any description of this change.)

> +    rc = xc_domain_getinfo(xch, domid, 1, &info);
> +    if ( rc < 0 )
> +    {
> +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> +        return rc;
> +    }
> +
> +    config->apic_mode = 1;
> +
> +    if ( dom->nr_vnodes )
> +    {
> +        struct acpi_numa *numa = &config->numa;
> +
> +        numa->vmemrange = calloc(dom->nr_vmemranges,
> +                                 sizeof(*numa->vmemrange));
> +        numa->vdistance = calloc(dom->nr_vnodes,
> +                                 sizeof(*numa->vdistance));
> +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> +                                     sizeof(*numa->vcpu_to_vnode));
> +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> +        {
> +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
> +            free(numa->vmemrange);
> +            free(numa->vdistance);
> +            free(numa->vcpu_to_vnode);
> +            return -ENOMEM;
> +        }
> +
> +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> +                                &numa->nr_vmemranges,
> +                                &config->nr_vcpus, numa->vmemrange,
> +                                numa->vdistance, numa->vcpu_to_vnode);
> +
> +	    if ( rc )
> +        {
> +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
> +            return rc;
> +        }
> +    }
> +    else
> +        config->nr_vcpus = info.max_vcpu_id + 1;
> +
> +    config->vcpu_online = calloc((HVM_MAX_VCPUS + 7) / 8,
> +                                 sizeof(*config->vcpu_online));
> +    if ( config->vcpu_online == NULL )
> +    {
> +        DOMPRINTF("%s: Can't allocate vcpu_online", __FUNCTION__);
> +        return -ENOMEM;
> +    }
> +
> +    for (i=0; i<config->nr_vcpus; i++)

You seem to be mixing styles here.

> +int xc_dom_build_acpi(struct xc_dom_image *dom)
> +{
> +    struct acpi_config config;
> +    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, *acpi_physical;
> +    void *guest_info_page, *guest_acpi_pages;
> +
> +    rc = init_acpi_config(dom, &config);
> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: init_acpi_config failed (rc=%d)", __FUNCTION__, rc);
> +        return rc;
> +    }
> +
> +    /*
> +     * Pages to hold ACPI tables and one page for acpi_info, which
> +     * will be the first one in this region.
> +     */
> +    acpi_pages = xc_memalign(xch, PAGE_SIZE, NUM_ACPI_PAGES * PAGE_SIZE);
> +    if ( !acpi_pages )
> +    {
> +        DOMPRINTF("%s: Can't allocate acpi pages", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    config.acpi_info_page = acpi_pages;
> +
> +    /* Set up allocator memory */
> +    base_addr = alloc_up = (unsigned long)acpi_pages + PAGE_SIZE;
> +    alloc_down = (unsigned long)acpi_pages + (NUM_ACPI_PAGES * PAGE_SIZE);
> +
> +    /* Map page that will hold RSDP */
> +    extent = PFN(ACPI_PHYSICAL_ADDRESS);
> +    rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &extent);
> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d",
> +                  __FUNCTION__, rc);
> +        goto out;
> +    }
> +    acpi_physical = xc_map_foreign_range(xch, domid, PAGE_SIZE,
> +                                         PROT_READ | PROT_WRITE,
> +                                         PFN(ACPI_PHYSICAL_ADDRESS));
> +    if ( !acpi_physical )
> +    {
> +        DOMPRINTF("%s: Can't map acpi_physical", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    /* Build the tables */
> +    acpi_build_tables(&config, (unsigned long)acpi_physical);
> +
> +    /* Copy acpi_info page into guest's memory */
> +    extent = PFN(ACPI_INFO_PHYSICAL_ADDRESS);
> +    rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &extent);
> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d\n",
> +                  __FUNCTION__, rc);
> +        goto out;
> +    }
> +    guest_info_page = xc_map_foreign_range(xch, domid, PAGE_SIZE,
> +                                           PROT_READ | PROT_WRITE,
> +                                           PFN(ACPI_INFO_PHYSICAL_ADDRESS));
> +    if ( !guest_info_page )
> +    {
> +        DOMPRINTF("%s: Can't map acpi_info_page", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +    memcpy(guest_info_page, acpi_pages, PAGE_SIZE);
> +
> +    /* Copy ACPI tables into guest's memory */
> +    acpi_pages_num = ((alloc_up - (unsigned long)acpi_pages +
> +                       (PAGE_SIZE - 1)) >> PAGE_SHIFT) - 1;

This looks like there are acpi_pages_num pages starting at
acpi_pages, yet ...

> +    extents = malloc(acpi_pages_num * sizeof(*extents));
> +    if ( !extents )
> +    {
> +        DOMPRINTF("%s: Can't allocate extents array", __FUNCTION__);
> +        rc = -ENOMEM;
> +        goto out;
> +    }
> +    for (i = 0; i < acpi_pages_num; i++)
> +        extents[i] = PFN(RESERVED_MEMORY_DYNAMIC_START) + i;
> +    rc = xc_domain_populate_physmap_exact(xch, domid, acpi_pages_num,
> +                                          0, 0, extents);
> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d",
> +                  __FUNCTION__, rc);
> +        goto out;
> +    }
> +    guest_acpi_pages = xc_map_foreign_range(xch, domid,
> +                                            PAGE_SIZE * acpi_pages_num,
> +                                            PROT_READ | PROT_WRITE,
> +                                            PFN(RESERVED_MEMORY_DYNAMIC_START));
> +    if ( !guest_acpi_pages )
> +    {
> +        DOMPRINTF("%s Can't map guest_acpi_pages", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    memcpy(guest_acpi_pages, acpi_pages + PAGE_SIZE,
> +           acpi_pages_num * PAGE_SIZE);

... this looks like there are acpi_pages_num pages starting at
acpi_pages + PAGE_SIZE.

> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -643,6 +643,13 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>              DOMPRINTF("Unable to reserve memory for the start info");
>              goto out;
>          }
> +
> +        rc = xc_dom_build_acpi(dom);
> +        if ( rc != 0 )
> +        {
> +            DOMPRINTF("Unable to build ACPI tables");
> +            goto out;
> +        }

Iirc there is an "acpi=" guest config setting, yet neither here nor
down the call tree I have been able to find a respective check. Is
that option not relevant anymore? Do we really want to always
have those tables built?

> --- 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
> +            /*
> +             * HVM guests without device model will want
> +             * to have LAPIC emulation.
> +             */
> +            xc_config->emulation_flags = XEN_X86_EMU_LAPIC;
> +    } else 
>          xc_config->emulation_flags = 0;
> -    }

I'm not maintainer of this code, but I think this would read better if
you used an if/else if/else sequence instead of nested if.

> --- a/xen/common/libacpi/build.c
> +++ b/xen/common/libacpi/build.c
> @@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
>      return 1;
>  }
>  
> -void acpi_build_tables(struct acpi_config *config, unsigned int physical)
> +void acpi_build_tables(struct acpi_config *config, unsigned long physical)

I'm having some difficulty seeing how this change belongs here.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-04-06  1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
@ 2016-06-06 13:38   ` Jan Beulich
  2016-06-06 17:31     ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 13:38 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> With this flags set guests will not try to set up SCI.

I've just read through the respective ACPI spec section again, and
I couldn't find a reference to SCI from there ("Hardware-Reduced
ACPI"). Can you clarify this connection please. Also there are other
consequences of setting that flag, so in order to understand the
reasons behind this change in case of future problems I think the
description here will need to be significantly extended, despite the
change being so small.

> --- a/xen/common/libacpi/build.c
> +++ b/xen/common/libacpi/build.c
> @@ -555,6 +555,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned long physical)
>      fadt->x_dsdt = config->mem_ops.v2p(dsdt);
>      fadt->firmware_ctrl   = config->mem_ops.v2p(facs);
>      fadt->x_firmware_ctrl = config->mem_ops.v2p(facs);
> +    if ( !(config->table_flags & ACPI_BUILD_IOAPIC) )
> +        fadt->flags |= (1<<20); /* HW_REDUCED_ACPI */

I think this would better be made a suitable #define in acpi2_0.h.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code
  2016-04-06  1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
@ 2016-06-06 13:48   ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 13:48 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> --- a/xen/common/libacpi/Makefile
> +++ b/xen/common/libacpi/Makefile
> @@ -21,7 +21,16 @@ C_SRC  = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c
>  C_SRC += dsdt_anycpu_qemu_xen.c dsdt_empty.c
>  OBJS  = $(patsubst %.c,%.o,$(C_SRC))
>  
> -CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
> +ifneq (,$(findstring -D__XEN__,$(CFLAGS)))
> +# Hypervisor
> +obj-y	= $(OBJS)
> +$(OBJS): all
> +CFLAGS  += -I$(XEN_ROOT)/xen/include/public
> +CFLAGS_MKDSDT = -I$(XEN_ROOT)/xen/include/public/hvm -D__XEN__
> +else
> +# Toolstack
> +CFLAGS_MKDSDT = -I$(XEN_ROOT)/tools/include
> +endif

This again speaks against makefile sharing. Note that libelf doesn't
have anything like that.

> --- a/xen/common/libacpi/acpi2_0.h
> +++ b/xen/common/libacpi/acpi2_0.h
> @@ -17,10 +17,16 @@
>  #ifndef _ACPI_2_0_H_
>  #define _ACPI_2_0_H_
>  
> +#ifndef __XEN__
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/hvm/ioreq.h>
>  #include <xen/memory.h>
> +#else
> +#include <xen/lib.h>
> +#include <memory.h>
> +#include <hvm/ioreq.h>
> +#endif

I'm not sure this should be done here, albeit I do see the analogy to
how libelf deals with the dual use in this regard (perhaps doing this
in .c files of header other than this particular one would be fine). In
any event I am missing public/ prefixes above (preferably you would
drop the explicit .../public include path, but even if that's needed for
some reason, please don't obscure the inclusion of public headers
here by omitting that prefix).

> --- a/xen/common/libacpi/build.c
> +++ b/xen/common/libacpi/build.c
> @@ -15,8 +15,13 @@
>   * this program; If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#ifndef __XEN__
>  #include <stdio.h>
>  #include <string.h>
> +#else
> +#include <xen/lib.h>
> +#define printf printk
> +#endif

I think we should strive to not introduce bunches of new log-level-less
printk()-s. (But I do appreciate you not introducing stdio.h here.)

> @@ -24,14 +29,24 @@
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
>  #include "x86.h"
> +#ifndef __XEN__
>  #include <xen/hvm/hvm_info_table.h>
>  #include <xen/hvm/hvm_xs_strings.h>
>  #include <xen/hvm/params.h>
> +#else
> +#include <hvm/hvm_info_table.h>
> +#include <hvm/hvm_xs_strings.h>
> +#include <hvm/params.h>
> +#endif
>  
>  #define ACPI_MAX_SECONDARY_TABLES 16
>  
>  #define align16(sz)        (((sz) + 15) & ~15)
> +#ifndef __XEN__
>  #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
> +#else
> +#define fixed_strcpy(d, s) strlcpy((d), (s), sizeof(d))
> +#endif

I'd rather see you ditch the stray parentheses in the pre-existing
instance than introduce further ones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 11:04   ` Jan Beulich
@ 2016-06-06 14:20     ` Boris Ostrovsky
  2016-06-06 14:29       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 14:20 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/06/2016 07:04 AM, Jan Beulich wrote:
>
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -20,8 +20,6 @@
>>  XEN_ROOT = $(CURDIR)/../../..
>>  include $(XEN_ROOT)/tools/firmware/Rules.mk
>>  
>> -SUBDIRS := acpi
>> -
>>  # The HVM loader is started in 32-bit mode at the address below:
>>  LOADADDR = 0x100000
>>  
>> @@ -33,10 +31,18 @@ CFLAGS += $(CFLAGS_xeninclude)
>>  # We mustn't use tools-only public interfaces.
>>  CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>>  
>> +# ACPI table builder
>> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
>> +vpath %.c $(ACPI_PATH)
> Please don't - this would preclude having files with the same names
> in hvmloader/ and (the future) libacpi/.
>
>> @@ -95,7 +101,11 @@ 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
>> +.NOTPARALLEL: $(ACPI_SRC)
> And very clearly we will want to avoid the use of .NOTPARALLEL
> anywhere in our trees.
>
>> +$(ACPI_SRC):
>> +	$(MAKE) -C $(ACPI_PATH)
> The more that you can't do this from multiple points in the tree. Did
> you consider e.g. symlinking the subtree into the multiple parent
> trees?

How would this help with avoiding building the intermediate files from
multiple paces (libxc and hvmloader specifically --- that was the reason
for .NOTPARALLEL).

I thought of flock-ing directory but then I was afraid that interrupted
make may not clean up properly.

Or are you suggesting symlinking to help with include paths (i.e. to
drop vpath above)?


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 14:20     ` Boris Ostrovsky
@ 2016-06-06 14:29       ` Jan Beulich
  2016-06-06 14:49         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 14:29 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.06.16 at 16:20, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 07:04 AM, Jan Beulich wrote:
>>
>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -20,8 +20,6 @@
>>>  XEN_ROOT = $(CURDIR)/../../..
>>>  include $(XEN_ROOT)/tools/firmware/Rules.mk
>>>  
>>> -SUBDIRS := acpi
>>> -
>>>  # The HVM loader is started in 32-bit mode at the address below:
>>>  LOADADDR = 0x100000
>>>  
>>> @@ -33,10 +31,18 @@ CFLAGS += $(CFLAGS_xeninclude)
>>>  # We mustn't use tools-only public interfaces.
>>>  CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>>>  
>>> +# ACPI table builder
>>> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
>>> +vpath %.c $(ACPI_PATH)
>> Please don't - this would preclude having files with the same names
>> in hvmloader/ and (the future) libacpi/.
>>
>>> @@ -95,7 +101,11 @@ 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
>>> +.NOTPARALLEL: $(ACPI_SRC)
>> And very clearly we will want to avoid the use of .NOTPARALLEL
>> anywhere in our trees.
>>
>>> +$(ACPI_SRC):
>>> +	$(MAKE) -C $(ACPI_PATH)
>> The more that you can't do this from multiple points in the tree. Did
>> you consider e.g. symlinking the subtree into the multiple parent
>> trees?
> 
> How would this help with avoiding building the intermediate files from
> multiple paces (libxc and hvmloader specifically --- that was the reason
> for .NOTPARALLEL).

If you symlink the source files into three different subdirectories,
building in those three subdirectories will become independent. (Or,
just like libelf, build the hypervisor part in the actual directory, and
symlink only the libxc and hvmloader uses.)

> I thought of flock-ing directory but then I was afraid that interrupted
> make may not clean up properly.
> 
> Or are you suggesting symlinking to help with include paths (i.e. to
> drop vpath above)?

That as well - symlinking would solve a number of issues that I have
pointed out, afaict at least.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 14:29       ` Jan Beulich
@ 2016-06-06 14:49         ` Boris Ostrovsky
  2016-06-06 14:57           ` Jan Beulich
  2016-06-06 15:31           ` Andrew Cooper
  0 siblings, 2 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 14:49 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/06/2016 10:29 AM, Jan Beulich wrote:
>> How would this help with avoiding building the intermediate files
>> from multiple paces (libxc and hvmloader specifically --- that was
>> the reason for .NOTPARALLEL). 
> If you symlink the source files into three different subdirectories,
> building in those three subdirectories will become independent. (Or,
> just like libelf, build the hypervisor part in the actual directory, and
> symlink only the libxc and hvmloader uses.)

I see. I didn't want to generate intermediate files multiple times but
yes, it's better than dealing with make synchronization issues.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 14:49         ` Boris Ostrovsky
@ 2016-06-06 14:57           ` Jan Beulich
  2016-06-06 15:31           ` Andrew Cooper
  1 sibling, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 14:57 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

>>> On 06.06.16 at 16:49, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 10:29 AM, Jan Beulich wrote:
>>> How would this help with avoiding building the intermediate files
>>> from multiple paces (libxc and hvmloader specifically --- that was
>>> the reason for .NOTPARALLEL). 
>> If you symlink the source files into three different subdirectories,
>> building in those three subdirectories will become independent. (Or,
>> just like libelf, build the hypervisor part in the actual directory, and
>> symlink only the libxc and hvmloader uses.)
> 
> I see. I didn't want to generate intermediate files multiple times but
> yes, it's better than dealing with make synchronization issues.

Plus, in the end, there may be a need for slightly different build
settings (resulting in slightly different intermediate files).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h
  2016-06-06 11:31   ` Jan Beulich
@ 2016-06-06 15:08     ` Boris Ostrovsky
  2016-06-06 15:22       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 15:08 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

On 06/06/2016 07:31 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> Users of ACPI builder will need to provide their own implemetations of
>> strncpy(), memcpy, memset() and printf declared in stdio.h and string.h.
>> For hvmloader we provide those two as wrappers around utul.h.
>>
>> Some x86-specific definitions move to ACPI builder's x86.h file so that
>> users won't have to re-define them themselves.
>>
>> Explicitly define a few things that are currently available to to build.c
>> via util.h.
> Considering the first paragraph, this last sentence was more
> confusing than clarifying to me: I expected util.h to get changed
> in some way, but aiui having gone through the entire patch this is
> just a (very different) re-statement of what you've said already.
>
>>  create mode 100644 tools/firmware/hvmloader/acpi/x86.h
>>  create mode 100644 tools/firmware/hvmloader/stdio.h
>>  create mode 100644 tools/firmware/hvmloader/string.h
> I have to admit that I'm not really looking forward to see the
> hypervisor gain a file stdio.h. I'm also not convinced libxc'e
> planned use of the libacpi/ would fit well with uses of printf() in
> that subtree.

Hypervisor won't use it, it will be included under '#ifndef __XEN__' (in
patch 20).

>
>> --- /dev/null
>> +++ b/tools/firmware/hvmloader/acpi/x86.h
>> @@ -0,0 +1,14 @@
>> +#ifndef __ACPI_X86_H__
>> +#define __ACPI_X86_H__
>> +
>> +#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 */
> Only the latter of those last two is used by build.c. Please limit what
> you move to the very minimum. I.e. IOAPIC_VERSION shouldn't move
> either imo (and I notice there's a disconnect between it and the
> hypervisor's VIOAPIC_VERSION_ID, but that's a pre-existing issue).

You don't think logically all these should be in the same file?

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-06 12:03   ` Wei Liu
@ 2016-06-06 15:15     ` Boris Ostrovsky
  2016-06-16  8:54       ` Wei Liu
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 15:15 UTC (permalink / raw)
  To: Wei Liu; +Cc: roger.pau, Stefano Stabellini, xen-devel

On 06/06/2016 08:03 AM, Wei Liu wrote:
>
>> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
>> index 608404f..9569e54 100644
>> --- a/tools/libxc/Makefile
>> +++ b/tools/libxc/Makefile
>> @@ -79,6 +79,26 @@ GUEST_SRCS-y += $(ELF_SRCS-y)
>>  $(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
>>  $(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
>>  
>> +ACPI_PATH = $(XEN_ROOT)/xen/common/libacpi
>> +vpath %.c $(ACPI_PATH)
>> +ACPI_FILES  = dsdt_anycpu.c dsdt_15cpu.c static_tables.c
>> +ACPI_FILES += dsdt_anycpu_qemu_xen.c dsdt_empty.c build.c
>> +ACPI_SRCS = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
>> +
>> +.NOTPARALLEL: $(ACPI_SRCS)
> Why is this needed?


To prevent building intermediate *.c files in parallel from multiple
places (libxc and hvmloader). But this will be removed per Jan's
suggestion not to create those files in libacpi and instead keep them in
libxc and hvmloader.


>
> +static int init_acpi_config(struct xc_dom_image *dom,
> +                            struct acpi_config *config)
> +{
> +    xc_interface *xch = dom->xch;
> +    uint32_t domid = dom->guest_domid;
> +    xc_dominfo_t info;
> +    int i, rc;
> +
> +    memset(config, 0, sizeof(*config));
> +
> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> +
> +    rc = xc_domain_getinfo(xch, domid, 1, &info);
> +    if ( rc < 0 )
> +    {
> +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> +        return rc;
> +    }
> +
> +    config->apic_mode = 1;
> +
> +    if ( dom->nr_vnodes )
> +    {
> +        struct acpi_numa *numa = &config->numa;
> +
> +        numa->vmemrange = calloc(dom->nr_vmemranges,
> +                                 sizeof(*numa->vmemrange));
> +        numa->vdistance = calloc(dom->nr_vnodes,
> +                                 sizeof(*numa->vdistance));
> +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> +                                     sizeof(*numa->vcpu_to_vnode));
> +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> +        {
> +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
> +            free(numa->vmemrange);
> +            free(numa->vdistance);
> +            free(numa->vcpu_to_vnode);
> +            return -ENOMEM;
> +        }
> +
> +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> +                                &numa->nr_vmemranges,
> +                                &config->nr_vcpus, numa->vmemrange,
> +                                numa->vdistance, numa->vcpu_to_vnode);
> +
> +	    if ( rc )
> +        {
> +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
> +            return rc;
> +        }
> +    }
> +    else
> +        config->nr_vcpus = info.max_vcpu_id + 1;
> This looks wrong, at least it is not immediately clear why you would
> want to do this.


Why is this wrong? If we have one VCPU max_vcpu_id will be zero, won't it?


> +}
> +
> +int xc_dom_build_acpi(struct xc_dom_image *dom)
> +{
> +    struct acpi_config config;
> +    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, *acpi_physical;
> +    void *guest_info_page, *guest_acpi_pages;
> +
> Need to initialise these to NULL and 0 in case you take the exit path
> earlier.

Right. I think Roger pointed out that clang doesn't like this neither.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h
  2016-06-06 15:08     ` Boris Ostrovsky
@ 2016-06-06 15:22       ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 15:22 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.06.16 at 17:08, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 07:31 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>> --- /dev/null
>>> +++ b/tools/firmware/hvmloader/acpi/x86.h
>>> @@ -0,0 +1,14 @@
>>> +#ifndef __ACPI_X86_H__
>>> +#define __ACPI_X86_H__
>>> +
>>> +#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 */
>> Only the latter of those last two is used by build.c. Please limit what
>> you move to the very minimum. I.e. IOAPIC_VERSION shouldn't move
>> either imo (and I notice there's a disconnect between it and the
>> hypervisor's VIOAPIC_VERSION_ID, but that's a pre-existing issue).
> 
> You don't think logically all these should be in the same file?

Not really, no. IOAPIC_VERSION, as said, should go away.
Meanwhile I already have a patch for that (at once dropping
IOAPIC_BASE_ADDRESS too), albeit that conflicts with what
you're doing.

And the two PCI_ISA_ ones seem to belong together solely
because of their name. The IRQ mask is a simple number,
unrelated to any specific PCI device.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 14:49         ` Boris Ostrovsky
  2016-06-06 14:57           ` Jan Beulich
@ 2016-06-06 15:31           ` Andrew Cooper
  2016-06-06 15:41             ` Jan Beulich
  1 sibling, 1 reply; 91+ messages in thread
From: Andrew Cooper @ 2016-06-06 15:31 UTC (permalink / raw)
  To: Boris Ostrovsky, Jan Beulich
  Cc: Keir Fraser, Stefano Stabellini, Ian Jackson, xen-devel, Wei Liu,
	roger.pau

On 06/06/16 15:49, Boris Ostrovsky wrote:
> On 06/06/2016 10:29 AM, Jan Beulich wrote:
>>> How would this help with avoiding building the intermediate files
>>> from multiple paces (libxc and hvmloader specifically --- that was
>>> the reason for .NOTPARALLEL). 
>> If you symlink the source files into three different subdirectories,
>> building in those three subdirectories will become independent. (Or,
>> just like libelf, build the hypervisor part in the actual directory, and
>> symlink only the libxc and hvmloader uses.)
> I see. I didn't want to generate intermediate files multiple times but
> yes, it's better than dealing with make synchronization issues.

It is exceedingly unlikely that Xen, the toolstack, and hvmloader will
have libacpi compiled with the same compiler settings.

Sharing intermediate files is not safe to do in this context.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly
  2016-06-06 15:31           ` Andrew Cooper
@ 2016-06-06 15:41             ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-06 15:41 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Wei Liu, Stefano Stabellini, Ian Jackson, xen-devel, Keir Fraser,
	Boris Ostrovsky, roger.pau

>>> On 06.06.16 at 17:31, <andrew.cooper3@citrix.com> wrote:
> On 06/06/16 15:49, Boris Ostrovsky wrote:
>> On 06/06/2016 10:29 AM, Jan Beulich wrote:
>>>> How would this help with avoiding building the intermediate files
>>>> from multiple paces (libxc and hvmloader specifically --- that was
>>>> the reason for .NOTPARALLEL). 
>>> If you symlink the source files into three different subdirectories,
>>> building in those three subdirectories will become independent. (Or,
>>> just like libelf, build the hypervisor part in the actual directory, and
>>> symlink only the libxc and hvmloader uses.)
>> I see. I didn't want to generate intermediate files multiple times but
>> yes, it's better than dealing with make synchronization issues.
> 
> It is exceedingly unlikely that Xen, the toolstack, and hvmloader will
> have libacpi compiled with the same compiler settings.
> 
> Sharing intermediate files is not safe to do in this context.

But you realize we don't talk about compiler settings here? The
intermediate .c files are to represent compiled .asl ones, and
the .asl -> .c conversion is much more likely to happen in mostly
similar fashion. But I can foresee customization, which would end
up being different between the consumer environments.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  2016-06-06 12:58   ` Jan Beulich
@ 2016-06-06 15:46     ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 15:46 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, Ian Jackson,
	xen-devel, Keir Fraser, roger.pau

On 06/06/2016 08:58 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
>> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
>> @@ -490,6 +490,11 @@ struct acpi_numa {
>>      xen_vmemrange_t *vmemrange;
>>  };
>>  
>> +struct acpi_mem_ops {
>> +    void *(*alloc)(uint32_t size, uint32_t align);
>> +    unsigned long (*v2p)(void *v);
>> +};
> As before, I think this is the wrong header for such stuff.
>
> And then I think I agree with the allocation hook (or otherwise the
> too generic name would need to be changed), but I don't think I
> agree with the v2p one. Instead I think the consumer should
> provide a suitable virt_to_phys(): That's already the case for
> hvmloader, should be trivial for libxc. And as long as we provide
> Dom0 with a 1:1 machine/physical addresses, the existing one in
> the hypervisor would do too.
>
> At the very least alternatively, to reduce code churn, patch order
> should be changed, so that you don't touch again all the lines that
> you made use virt_to_phys() just a patch or two ago.

I'd rather go this route. IIRC I initially had both mem_alloc() and
virt_to_phys() being provided by callers by name but it ended up being
somewhat messy. And I think for consistency sake they should both be
either hooks or provided directly.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-06-06 13:05   ` Jan Beulich
@ 2016-06-06 16:09     ` Boris Ostrovsky
  2016-06-07  6:20       ` Jan Beulich
  2016-06-07 12:24       ` Roger Pau Monné
  0 siblings, 2 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 16:09 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

On 06/06/2016 09:05 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>  .gitignore                                                        | 8 ++++----
>>  tools/firmware/hvmloader/Makefile                                 | 3 +--
>>  tools/firmware/hvmloader/smbios.c                                 | 1 +
>>  tools/firmware/rombios/32bit/Makefile                             | 2 +-
>>  tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
>>  .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
>>  .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
>>  17 files changed, 11 insertions(+), 11 deletions(-)
> As mentioned before, new placement subject to determination
> whether this is to eventually be used by the hypervisor.


Roger, when do you think you'll be able to see whether dom0 builder will
use this? I can start working on v1 with assumption that this will be
used by hypervisor. We can drop the last patch (and modify this one to
move acpi to somewhere in tools) if it becomes clear that hypervisor
does not want it.


>
>> --- a/tools/firmware/hvmloader/acpi/Makefile
>> +++ b/xen/common/libacpi/Makefile
>> @@ -14,13 +14,13 @@
>>  # this program; If not, see <http://www.gnu.org/licenses/>.
>>  #
>>  
>> -XEN_ROOT = $(CURDIR)/../../../..
>> -include $(XEN_ROOT)/tools/firmware/Rules.mk
>> +XEN_ROOT = $(CURDIR)/../../..
>> +include $(XEN_ROOT)/Config.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))
>>  
>> -CFLAGS += $(CFLAGS_xeninclude)
>> +CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
> Where would this now get consumed? This appears to be a tools/
> only setting, which should thus no longer be needed here.

This is needed for building mk_dsdt.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-06 13:29   ` Jan Beulich
@ 2016-06-06 16:59     ` Boris Ostrovsky
  2016-06-07  6:17       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 16:59 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> --- /dev/null
>> +++ b/tools/libxc/xc_acpi.c
>> @@ -0,0 +1,268 @@
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <inttypes.h>
>> +#include <assert.h>
>> +
>> +#include <xen/xen.h>
>> +#include <xen/foreign/x86_32.h>
>> +#include <xen/foreign/x86_64.h>
> Why are these two needed here? The code here shouldn't care
> about the mode the guest may later want to run in.

These two are not needed.

>
>> +#include <xen/hvm/hvm_info_table.h>
>> +#include <xen/io/protocols.h>
>> +
>> +#include "xg_private.h"
>> +#include "xc_dom.h"
>> +#include "xenctrl.h"
>> +
>> +#include "acpi2_0.h"
>> +
>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>> +
>> +/* Initial allocation for ACPI tables */
>> +#define NUM_ACPI_PAGES  16
> With which other definitions do these three need to remain in sync?

NUM_ACPI_PAGES is private to this file.

ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 0xfffff, I picked this number because that's where most systems that I have appear to have it. (And by "most" I mean the two that I checked ;-))

RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need SystemMemory so it can be anywhere (and e820 should presumably be aware of this, which it is not right now)


>
>> +static int init_acpi_config(struct xc_dom_image *dom,
>> +                            struct acpi_config *config)
>> +{
>> +    xc_interface *xch = dom->xch;
>> +    uint32_t domid = dom->guest_domid;
>> +    xc_dominfo_t info;
>> +    int i, rc;
>> +
>> +    memset(config, 0, sizeof(*config));
>> +
>> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
>> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> What good does an empty DSDT do? (Perhaps this question is a
> result of there not being any description of this change.)

DSDT is required to be present by the spec. And ACPICA gets upset if it
doesn't see it.

> +    /* Copy acpi_info page into guest's memory */
> +    extent = PFN(ACPI_INFO_PHYSICAL_ADDRESS);
> +    rc = xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &extent);
> +    if ( rc )
> +    {
> +        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d\n",
> +                  __FUNCTION__, rc);
> +        goto out;
> +    }
> +    guest_info_page = xc_map_foreign_range(xch, domid, PAGE_SIZE,
> +                                           PROT_READ | PROT_WRITE,
> +                                           PFN(ACPI_INFO_PHYSICAL_ADDRESS));
> +    if ( !guest_info_page )
> +    {
> +        DOMPRINTF("%s: Can't map acpi_info_page", __FUNCTION__);
> +        rc = -1;
> +        goto out;
> +    }
> +    memcpy(guest_info_page, acpi_pages, PAGE_SIZE);
> +
> +    /* Copy ACPI tables into guest's memory */
> +    acpi_pages_num = ((alloc_up - (unsigned long)acpi_pages +
> +                       (PAGE_SIZE - 1)) >> PAGE_SHIFT) - 1;
> This looks like there are acpi_pages_num pages starting at
> acpi_pages, yet ...
>
>> +    extents = malloc(acpi_pages_num * sizeof(*extents));
>> +    if ( !extents )
>> +    {
>> +        DOMPRINTF("%s: Can't allocate extents array", __FUNCTION__);
>> +        rc = -ENOMEM;
>> +        goto out;
>> +    }
>> +    for (i = 0; i < acpi_pages_num; i++)
>> +        extents[i] = PFN(RESERVED_MEMORY_DYNAMIC_START) + i;
>> +    rc = xc_domain_populate_physmap_exact(xch, domid, acpi_pages_num,
>> +                                          0, 0, extents);
>> +    if ( rc )
>> +    {
>> +        DOMPRINTF("%s: xc_domain_populate_physmap failed with %d",
>> +                  __FUNCTION__, rc);
>> +        goto out;
>> +    }
>> +    guest_acpi_pages = xc_map_foreign_range(xch, domid,
>> +                                            PAGE_SIZE * acpi_pages_num,
>> +                                            PROT_READ | PROT_WRITE,
>> +                                            PFN(RESERVED_MEMORY_DYNAMIC_START));
>> +    if ( !guest_acpi_pages )
>> +    {
>> +        DOMPRINTF("%s Can't map guest_acpi_pages", __FUNCTION__);
>> +        rc = -1;
>> +        goto out;
>> +    }
>> +
>> +    memcpy(guest_acpi_pages, acpi_pages + PAGE_SIZE,
>> +           acpi_pages_num * PAGE_SIZE);
> ... this looks like there are acpi_pages_num pages starting at
> acpi_pages + PAGE_SIZE.

Yes, I am off-by-one here. The first page (ACPI_INFO_PHYSICAL_ADDRESS)
is managed separately.

>
>> --- a/tools/libxc/xc_dom_x86.c
>> +++ b/tools/libxc/xc_dom_x86.c
>> @@ -643,6 +643,13 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>>              DOMPRINTF("Unable to reserve memory for the start info");
>>              goto out;
>>          }
>> +
>> +        rc = xc_dom_build_acpi(dom);
>> +        if ( rc != 0 )
>> +        {
>> +            DOMPRINTF("Unable to build ACPI tables");
>> +            goto out;
>> +        }
> Iirc there is an "acpi=" guest config setting, yet neither here nor
> down the call tree I have been able to find a respective check. Is
> that option not relevant anymore? Do we really want to always
> have those tables built?

Right, I should check. Come think of it, we should probably also check
"apic=" option when building MADT in libacpi.


>
>> --- a/xen/common/libacpi/build.c
>> +++ b/xen/common/libacpi/build.c
>> @@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
>>      return 1;
>>  }
>>  
>> -void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>> +void acpi_build_tables(struct acpi_config *config, unsigned long physical)
> I'm having some difficulty seeing how this change belongs here.

acpi_build_tables() is called with virtual (i.e. 64-bit) address from libxc.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-06 13:38   ` Jan Beulich
@ 2016-06-06 17:31     ` Boris Ostrovsky
  2016-06-07  6:06       ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-06 17:31 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> With this flags set guests will not try to set up SCI.
> I've just read through the respective ACPI spec section again, and
> I couldn't find a reference to SCI from there ("Hardware-Reduced
> ACPI"). Can you clarify this connection please. Also there are other
> consequences of setting that flag, so in order to understand the
> reasons behind this change in case of future problems I think the
> description here will need to be significantly extended, despite the
> change being so small.

My understanding is that hardware-reduced platforms don't use ACPI
Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
versa --- SCI is present when ACPI Platform Event Model is in use). The
(somewhat indirect) evidence of this is in section 4.6 "The ACPI
Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
model is disabled (no SCIs are generated) ..."

-boris

>
>> --- a/xen/common/libacpi/build.c
>> +++ b/xen/common/libacpi/build.c
>> @@ -555,6 +555,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned long physical)
>>      fadt->x_dsdt = config->mem_ops.v2p(dsdt);
>>      fadt->firmware_ctrl   = config->mem_ops.v2p(facs);
>>      fadt->x_firmware_ctrl = config->mem_ops.v2p(facs);
>> +    if ( !(config->table_flags & ACPI_BUILD_IOAPIC) )
>> +        fadt->flags |= (1<<20); /* HW_REDUCED_ACPI */
> I think this would better be made a suitable #define in acpi2_0.h.
>
> Jan
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-06 17:31     ` Boris Ostrovsky
@ 2016-06-07  6:06       ` Jan Beulich
  2016-06-07 14:02         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-07  6:06 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>> With this flags set guests will not try to set up SCI.
>> I've just read through the respective ACPI spec section again, and
>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>> ACPI"). Can you clarify this connection please. Also there are other
>> consequences of setting that flag, so in order to understand the
>> reasons behind this change in case of future problems I think the
>> description here will need to be significantly extended, despite the
>> change being so small.
> 
> My understanding is that hardware-reduced platforms don't use ACPI
> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
> versa --- SCI is present when ACPI Platform Event Model is in use). The
> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
> model is disabled (no SCIs are generated) ..."

In the sum of all the non-explicit wording I can only convince myself
that SCI is a prereq for the event model. Yet I could see this being
an if-and-only-if, just that I couldn't find any place saying so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-06 16:59     ` Boris Ostrovsky
@ 2016-06-07  6:17       ` Jan Beulich
  2016-06-07 13:59         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-07  6:17 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>>> +
>>> +/* Initial allocation for ACPI tables */
>>> +#define NUM_ACPI_PAGES  16
>> With which other definitions do these three need to remain in sync?
> 
> NUM_ACPI_PAGES is private to this file.
> 
> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 
> 0xfffff, I picked this number because that's where most systems that I have 
> appear to have it. (And by "most" I mean the two that I checked ;-))

With there not being a BIOS, I can see this being pretty arbitrary.
Yet in that case I'm not convinced of this getting put at a random
address in the middle. Plus I'm not sure I see the connection to the
reservations done in the E820 map the guest gets to see.

> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
> this, which it is not right now)

So you say there's no connection to the end of hvmloader's window
for PCI MMIO assignments (an equivalent of which is going to be
needed for PVHv2)?

>>> +static int init_acpi_config(struct xc_dom_image *dom,
>>> +                            struct acpi_config *config)
>>> +{
>>> +    xc_interface *xch = dom->xch;
>>> +    uint32_t domid = dom->guest_domid;
>>> +    xc_dominfo_t info;
>>> +    int i, rc;
>>> +
>>> +    memset(config, 0, sizeof(*config));
>>> +
>>> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
>>> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
>> What good does an empty DSDT do? (Perhaps this question is a
>> result of there not being any description of this change.)
> 
> DSDT is required to be present by the spec. And ACPICA gets upset if it
> doesn't see it.

But my point (also mentioned further down in the original reply) was
that there's no need for anything if acpi=0. But note that as soon as
you report processors in MADT, the combined set of tables holding
AML code can't be empty anymore: Processors need to be
declared using Processor() (legacy) or Device(). Maybe we don't
need as much as an ordinary HVM guest, but nothing seems too little.

>>> --- a/tools/libxc/xc_dom_x86.c
>>> +++ b/tools/libxc/xc_dom_x86.c
>>> @@ -643,6 +643,13 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>>>              DOMPRINTF("Unable to reserve memory for the start info");
>>>              goto out;
>>>          }
>>> +
>>> +        rc = xc_dom_build_acpi(dom);
>>> +        if ( rc != 0 )
>>> +        {
>>> +            DOMPRINTF("Unable to build ACPI tables");
>>> +            goto out;
>>> +        }
>> Iirc there is an "acpi=" guest config setting, yet neither here nor
>> down the call tree I have been able to find a respective check. Is
>> that option not relevant anymore? Do we really want to always
>> have those tables built?
> 
> Right, I should check. Come think of it, we should probably also check
> "apic=" option when building MADT in libacpi.

Very likely, yes.

>>> --- a/xen/common/libacpi/build.c
>>> +++ b/xen/common/libacpi/build.c
>>> @@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
>>>      return 1;
>>>  }
>>>  
>>> -void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>>> +void acpi_build_tables(struct acpi_config *config, unsigned long physical)
>> I'm having some difficulty seeing how this change belongs here.
> 
> acpi_build_tables() is called with virtual (i.e. 64-bit) address from libxc.

Oh - so the parameter name is then wrong?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-06-06 16:09     ` Boris Ostrovsky
@ 2016-06-07  6:20       ` Jan Beulich
  2016-06-07 12:24       ` Roger Pau Monné
  1 sibling, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-07  6:20 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Andrew Cooper, xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 06.06.16 at 18:09, <boris.ostrovsky@oracle.com> wrote:
> On 06/06/2016 09:05 AM, Jan Beulich wrote:
>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>  .gitignore                                                        | 8 ++++----
>>>  tools/firmware/hvmloader/Makefile                                 | 3 +--
>>>  tools/firmware/hvmloader/smbios.c                                 | 1 +
>>>  tools/firmware/rombios/32bit/Makefile                             | 2 +-
>>>  tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
>>>  .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
>>>  .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
>>>  17 files changed, 11 insertions(+), 11 deletions(-)
>> As mentioned before, new placement subject to determination
>> whether this is to eventually be used by the hypervisor.
> 
> 
> Roger, when do you think you'll be able to see whether dom0 builder will
> use this? I can start working on v1 with assumption that this will be
> used by hypervisor. We can drop the last patch (and modify this one to
> move acpi to somewhere in tools) if it becomes clear that hypervisor
> does not want it.

I guess if it doesn't become clear by then we could still allow for it
to be moved as you do, with the expectation of a follow-up patch
to move it under tools/ if it turns out Dom0 doesn't want/need it.

>>> --- a/tools/firmware/hvmloader/acpi/Makefile
>>> +++ b/xen/common/libacpi/Makefile
>>> @@ -14,13 +14,13 @@
>>>  # this program; If not, see <http://www.gnu.org/licenses/>.
>>>  #
>>>  
>>> -XEN_ROOT = $(CURDIR)/../../../..
>>> -include $(XEN_ROOT)/tools/firmware/Rules.mk
>>> +XEN_ROOT = $(CURDIR)/../../..
>>> +include $(XEN_ROOT)/Config.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))
>>>  
>>> -CFLAGS += $(CFLAGS_xeninclude)
>>> +CFLAGS_xeninclude = -I$(XEN_ROOT)/tools/include
>> Where would this now get consumed? This appears to be a tools/
>> only setting, which should thus no longer be needed here.
> 
> This is needed for building mk_dsdt.

Which you rename later on. This being a tools/ construct, I'd
appreciate the renaming to happen right away, both to cut the
connection to tools/ and to make the (sole) consumer obvious to
reviewers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-06-06 16:09     ` Boris Ostrovsky
  2016-06-07  6:20       ` Jan Beulich
@ 2016-06-07 12:24       ` Roger Pau Monné
  2016-06-07 14:32         ` Boris Ostrovsky
  1 sibling, 1 reply; 91+ messages in thread
From: Roger Pau Monné @ 2016-06-07 12:24 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Andrew Cooper, xen-devel, Wei Liu, Jan Beulich, Stefano Stabellini

On Mon, Jun 06, 2016 at 12:09:21PM -0400, Boris Ostrovsky wrote:
> On 06/06/2016 09:05 AM, Jan Beulich wrote:
> >>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> >>  .gitignore                                                        | 8 ++++----
> >>  tools/firmware/hvmloader/Makefile                                 | 3 +--
> >>  tools/firmware/hvmloader/smbios.c                                 | 1 +
> >>  tools/firmware/rombios/32bit/Makefile                             | 2 +-
> >>  tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
> >>  .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
> >>  .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
> >>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
> >>  17 files changed, 11 insertions(+), 11 deletions(-)
> > As mentioned before, new placement subject to determination
> > whether this is to eventually be used by the hypervisor.
> 
> 
> Roger, when do you think you'll be able to see whether dom0 builder will
> use this? I can start working on v1 with assumption that this will be
> used by hypervisor. We can drop the last patch (and modify this one to
> move acpi to somewhere in tools) if it becomes clear that hypervisor
> does not want it.

What we need to do is quite similar to what ARM does, and they seem to 
prefer to have different ACPI code for Dom0/DomU, so I'm quite sure we could 
do the same for x86 also. FWIW, when Boris and I discussed this we though it 
would be better to have a single place where all the ACPI code resides, both 
to create tables or to modify them.

Would it be a lot of work to leave it in tools/ for the time being and move 
it later if we see that we could benefit from merging both? Or maybe leave 
it in xen/common without linking it with the hypervisor just yet (but that 
would need sorting out later anyway).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-07  6:17       ` Jan Beulich
@ 2016-06-07 13:59         ` Boris Ostrovsky
  2016-06-07 14:10           ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 13:59 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>>>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>>>> +
>>>> +/* Initial allocation for ACPI tables */
>>>> +#define NUM_ACPI_PAGES  16
>>> With which other definitions do these three need to remain in sync?
>> NUM_ACPI_PAGES is private to this file.
>>
>> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 
>> 0xfffff, I picked this number because that's where most systems that I have 
>> appear to have it. (And by "most" I mean the two that I checked ;-))
> With there not being a BIOS, I can see this being pretty arbitrary.
> Yet in that case I'm not convinced of this getting put at a random
> address in the middle. 

I can put it in the beginning, at 0xe0000.

> Plus I'm not sure I see the connection to the
> reservations done in the E820 map the guest gets to see.

I thought ACPI data is supposed to live in reserved areas (ACPI data,
actually)?

>
>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
>> this, which it is not right now)
> So you say there's no connection to the end of hvmloader's window
> for PCI MMIO assignments (an equivalent of which is going to be
> needed for PVHv2)?

I haven't thought about this but then we don't have MMIO hole now. I can
try finding available memory chunk in guest's memory under 4G.

>
>>>> +static int init_acpi_config(struct xc_dom_image *dom,
>>>> +                            struct acpi_config *config)
>>>> +{
>>>> +    xc_interface *xch = dom->xch;
>>>> +    uint32_t domid = dom->guest_domid;
>>>> +    xc_dominfo_t info;
>>>> +    int i, rc;
>>>> +
>>>> +    memset(config, 0, sizeof(*config));
>>>> +
>>>> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
>>>> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
>>> What good does an empty DSDT do? (Perhaps this question is a
>>> result of there not being any description of this change.)
>> DSDT is required to be present by the spec. And ACPICA gets upset if it
>> doesn't see it.
> But my point (also mentioned further down in the original reply) was
> that there's no need for anything if acpi=0. 

Right, but the whole routine will not be called if that's the case (in v1).

> But note that as soon as
> you report processors in MADT, the combined set of tables holding
> AML code can't be empty anymore: Processors need to be
> declared using Processor() (legacy) or Device(). Maybe we don't
> need as much as an ordinary HVM guest, but nothing seems too little.

I will add Processor.

>
>>>> --- a/xen/common/libacpi/build.c
>>>> +++ b/xen/common/libacpi/build.c
>>>> @@ -480,7 +480,7 @@ static int new_vm_gid(struct acpi_config *config)
>>>>      return 1;
>>>>  }
>>>>  
>>>> -void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>>>> +void acpi_build_tables(struct acpi_config *config, unsigned long physical)
>>> I'm having some difficulty seeing how this change belongs here.
>> acpi_build_tables() is called with virtual (i.e. 64-bit) address from libxc.
> Oh - so the parameter name is then wrong?


Yes, it should have a more appropriate name. Like rsdp or something like
that.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-07  6:06       ` Jan Beulich
@ 2016-06-07 14:02         ` Boris Ostrovsky
  2016-06-07 14:12           ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 14:02 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>> With this flags set guests will not try to set up SCI.
>>> I've just read through the respective ACPI spec section again, and
>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>> ACPI"). Can you clarify this connection please. Also there are other
>>> consequences of setting that flag, so in order to understand the
>>> reasons behind this change in case of future problems I think the
>>> description here will need to be significantly extended, despite the
>>> change being so small.
>> My understanding is that hardware-reduced platforms don't use ACPI
>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>> model is disabled (no SCIs are generated) ..."
> In the sum of all the non-explicit wording I can only convince myself
> that SCI is a prereq for the event model. Yet I could see this being
> an if-and-only-if, just that I couldn't find any place saying so.
>

Not sure how I should interpret this: do you (reluctantly, possibly)
agree that we can use HW-reduced flag to indicate that SCI is not there?

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-07 13:59         ` Boris Ostrovsky
@ 2016-06-07 14:10           ` Jan Beulich
  2016-06-07 14:47             ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-07 14:10 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 07.06.16 at 15:59, <boris.ostrovsky@oracle.com> wrote:
> On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>>>>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>>>>> +
>>>>> +/* Initial allocation for ACPI tables */
>>>>> +#define NUM_ACPI_PAGES  16
>>>> With which other definitions do these three need to remain in sync?
>>> NUM_ACPI_PAGES is private to this file.
>>>
>>> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 
>>> 0xfffff, I picked this number because that's where most systems that I have 
>>> appear to have it. (And by "most" I mean the two that I checked ;-))
>> With there not being a BIOS, I can see this being pretty arbitrary.
>> Yet in that case I'm not convinced of this getting put at a random
>> address in the middle. 
> 
> I can put it in the beginning, at 0xe0000.

I'd rather see it put higher up, close below 1Mb.

>> Plus I'm not sure I see the connection to the
>> reservations done in the E820 map the guest gets to see.
> 
> I thought ACPI data is supposed to live in reserved areas (ACPI data,
> actually)?

Correct - but where is such an E820 entry being produced for the
guest?

>>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>>> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
>>> this, which it is not right now)
>> So you say there's no connection to the end of hvmloader's window
>> for PCI MMIO assignments (an equivalent of which is going to be
>> needed for PVHv2)?
> 
> I haven't thought about this but then we don't have MMIO hole now. I can
> try finding available memory chunk in guest's memory under 4G.

Well, we first need to settle on the intended memory layout.
And then we need to put this down in exactly one place, for all
players to consume (and adhere to).

>> But note that as soon as
>> you report processors in MADT, the combined set of tables holding
>> AML code can't be empty anymore: Processors need to be
>> declared using Processor() (legacy) or Device(). Maybe we don't
>> need as much as an ordinary HVM guest, but nothing seems too little.
> 
> I will add Processor.

And did you check whether there's something else that's
mandatory (or even just kind of, due to e.g. ACPI CA relying
on it)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-07 14:02         ` Boris Ostrovsky
@ 2016-06-07 14:12           ` Jan Beulich
  2016-06-07 15:17             ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-07 14:12 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>> With this flags set guests will not try to set up SCI.
>>>> I've just read through the respective ACPI spec section again, and
>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>> consequences of setting that flag, so in order to understand the
>>>> reasons behind this change in case of future problems I think the
>>>> description here will need to be significantly extended, despite the
>>>> change being so small.
>>> My understanding is that hardware-reduced platforms don't use ACPI
>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>> model is disabled (no SCIs are generated) ..."
>> In the sum of all the non-explicit wording I can only convince myself
>> that SCI is a prereq for the event model. Yet I could see this being
>> an if-and-only-if, just that I couldn't find any place saying so.
> 
> Not sure how I should interpret this: do you (reluctantly, possibly)
> agree that we can use HW-reduced flag to indicate that SCI is not there?

I really think we need to get confirmation on this from ACPI folks.
And I think (and I said so before) we need to understand all the
other implications from setting that flag (i.e. we _cannot_ use this
flag _just_ to indicate there's no SCI).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi
  2016-06-07 12:24       ` Roger Pau Monné
@ 2016-06-07 14:32         ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 14:32 UTC (permalink / raw)
  To: Roger Pau Monné
  Cc: Andrew Cooper, xen-devel, Wei Liu, Jan Beulich, Stefano Stabellini

On 06/07/2016 08:24 AM, Roger Pau Monné wrote:
> On Mon, Jun 06, 2016 at 12:09:21PM -0400, Boris Ostrovsky wrote:
>> On 06/06/2016 09:05 AM, Jan Beulich wrote:
>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>  .gitignore                                                        | 8 ++++----
>>>>  tools/firmware/hvmloader/Makefile                                 | 3 +--
>>>>  tools/firmware/hvmloader/smbios.c                                 | 1 +
>>>>  tools/firmware/rombios/32bit/Makefile                             | 2 +-
>>>>  tools/firmware/rombios/32bit/tcgbios/Makefile                     | 2 +-
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/Makefile    | 6 +++---
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/README      | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/acpi2_0.h   | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/build.c     | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/dsdt.asl    | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/mk_dsdt.c   | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_pm.asl | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s3.asl | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_s4.asl | 0
>>>>  .../firmware/hvmloader/acpi => xen/common/libacpi}/ssdt_tpm.asl   | 0
>>>>  .../hvmloader/acpi => xen/common/libacpi}/static_tables.c         | 0
>>>>  {tools/firmware/hvmloader/acpi => xen/common/libacpi}/x86.h       | 0
>>>>  17 files changed, 11 insertions(+), 11 deletions(-)
>>> As mentioned before, new placement subject to determination
>>> whether this is to eventually be used by the hypervisor.
>>
>> Roger, when do you think you'll be able to see whether dom0 builder will
>> use this? I can start working on v1 with assumption that this will be
>> used by hypervisor. We can drop the last patch (and modify this one to
>> move acpi to somewhere in tools) if it becomes clear that hypervisor
>> does not want it.
> What we need to do is quite similar to what ARM does, and they seem to 
> prefer to have different ACPI code for Dom0/DomU, so I'm quite sure we could 
> do the same for x86 also. FWIW, when Boris and I discussed this we though it 
> would be better to have a single place where all the ACPI code resides, both 
> to create tables or to modify them.
>
> Would it be a lot of work to leave it in tools/ for the time being and move 
> it later if we see that we could benefit from merging both? 

It's not a whole lot of work to keep it in tools. It will probably make
things easier, in fact.

-boris

> Or maybe leave 
> it in xen/common without linking it with the hypervisor just yet (but that 
> would need sorting out later anyway).





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-07 14:10           ` Jan Beulich
@ 2016-06-07 14:47             ` Boris Ostrovsky
  2016-06-07 15:00               ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 14:47 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

On 06/07/2016 10:10 AM, Jan Beulich wrote:
>>>> On 07.06.16 at 15:59, <boris.ostrovsky@oracle.com> wrote:
>> On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
>>>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>>>>>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>>>>>> +
>>>>>> +/* Initial allocation for ACPI tables */
>>>>>> +#define NUM_ACPI_PAGES  16
>>>>> With which other definitions do these three need to remain in sync?
>>>> NUM_ACPI_PAGES is private to this file.
>>>>
>>>> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 
>>>> 0xfffff, I picked this number because that's where most systems that I have 
>>>> appear to have it. (And by "most" I mean the two that I checked ;-))
>>> With there not being a BIOS, I can see this being pretty arbitrary.
>>> Yet in that case I'm not convinced of this getting put at a random
>>> address in the middle. 
>> I can put it in the beginning, at 0xe0000.
> I'd rather see it put higher up, close below 1Mb.
>
>>> Plus I'm not sure I see the connection to the
>>> reservations done in the E820 map the guest gets to see.
>> I thought ACPI data is supposed to live in reserved areas (ACPI data,
>> actually)?
> Correct - but where is such an E820 entry being produced for the
> guest?

It's not. I actually mentioned this in cover letter.

I prototyped this at some point in libxl__arch_domain_construct_memmap().


>
>>>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>>>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>>>> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
>>>> this, which it is not right now)
>>> So you say there's no connection to the end of hvmloader's window
>>> for PCI MMIO assignments (an equivalent of which is going to be
>>> needed for PVHv2)?
>> I haven't thought about this but then we don't have MMIO hole now. I can
>> try finding available memory chunk in guest's memory under 4G.
> Well, we first need to settle on the intended memory layout.
> And then we need to put this down in exactly one place, for all
> players to consume (and adhere to).

On the few systems that I looked at they are placed right before the
MMIO region.

How about (HVM_BELOW_4G_RAM_END - NUM_ACPI_PAGES)?


>
>>> But note that as soon as
>>> you report processors in MADT, the combined set of tables holding
>>> AML code can't be empty anymore: Processors need to be
>>> declared using Processor() (legacy) or Device(). Maybe we don't
>>> need as much as an ordinary HVM guest, but nothing seems too little.
>> I will add Processor.
> And did you check whether there's something else that's
> mandatory (or even just kind of, due to e.g. ACPI CA relying
> on it)?

I didn't check the spec but as far as ACPICA is concerned --- this was
tested with PVHv2 Linux and I think Roger ran this version on FreeBSD.

-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-07 14:47             ` Boris Ostrovsky
@ 2016-06-07 15:00               ` Jan Beulich
  0 siblings, 0 replies; 91+ messages in thread
From: Jan Beulich @ 2016-06-07 15:00 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, Stefano Stabellini, Wei Liu, roger.pau

>>> On 07.06.16 at 16:47, <boris.ostrovsky@oracle.com> wrote:
> On 06/07/2016 10:10 AM, Jan Beulich wrote:
>>>>> On 07.06.16 at 15:59, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>>>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
>>>>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>>>>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>>>>> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
>>>>> this, which it is not right now)
>>>> So you say there's no connection to the end of hvmloader's window
>>>> for PCI MMIO assignments (an equivalent of which is going to be
>>>> needed for PVHv2)?
>>> I haven't thought about this but then we don't have MMIO hole now. I can
>>> try finding available memory chunk in guest's memory under 4G.
>> Well, we first need to settle on the intended memory layout.
>> And then we need to put this down in exactly one place, for all
>> players to consume (and adhere to).
> 
> On the few systems that I looked at they are placed right before the
> MMIO region.
> 
> How about (HVM_BELOW_4G_RAM_END - NUM_ACPI_PAGES)?

Sounds reasonable. But as said - all involved parties need to be
made agree on memory use.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-07 14:12           ` Jan Beulich
@ 2016-06-07 15:17             ` Boris Ostrovsky
  2016-06-07 15:41               ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-07 15:17 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

On 06/07/2016 10:12 AM, Jan Beulich wrote:
>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>>> With this flags set guests will not try to set up SCI.
>>>>> I've just read through the respective ACPI spec section again, and
>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>>> consequences of setting that flag, so in order to understand the
>>>>> reasons behind this change in case of future problems I think the
>>>>> description here will need to be significantly extended, despite the
>>>>> change being so small.
>>>> My understanding is that hardware-reduced platforms don't use ACPI
>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>>> model is disabled (no SCIs are generated) ..."
>>> In the sum of all the non-explicit wording I can only convince myself
>>> that SCI is a prereq for the event model. Yet I could see this being
>>> an if-and-only-if, just that I couldn't find any place saying so.
>> Not sure how I should interpret this: do you (reluctantly, possibly)
>> agree that we can use HW-reduced flag to indicate that SCI is not there?
> I really think we need to get confirmation on this from ACPI folks.

Who should those people be? linux-acpi?

> And I think (and I said so before) we need to understand all the
> other implications from setting that flag (i.e. we _cannot_ use this
> flag _just_ to indicate there's no SCI).

FWIW, the Microsoft's reading is
https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-requirements-for-soc-based-platforms

ACPI fixed hardware features such as the following are not required:
    Power Management (PM) timer
    Real Time Clock (RTC) wake alarm
    System Control Interrupt (SCI)
    Fixed Hardware register set (PMx_* event/control/status registers)
    GPE block registers (GPEx_* event/control/status registers)
    Embedded controller

Also, from ACPICA perpective, HW-reduced mode appears to be the only way
to prevent initialization of SCI.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-07 15:17             ` Boris Ostrovsky
@ 2016-06-07 15:41               ` Jan Beulich
  2016-06-08 22:04                 ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-07 15:41 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

>>> On 07.06.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>>>> With this flags set guests will not try to set up SCI.
>>>>>> I've just read through the respective ACPI spec section again, and
>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>>>> consequences of setting that flag, so in order to understand the
>>>>>> reasons behind this change in case of future problems I think the
>>>>>> description here will need to be significantly extended, despite the
>>>>>> change being so small.
>>>>> My understanding is that hardware-reduced platforms don't use ACPI
>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>>>> model is disabled (no SCIs are generated) ..."
>>>> In the sum of all the non-explicit wording I can only convince myself
>>>> that SCI is a prereq for the event model. Yet I could see this being
>>>> an if-and-only-if, just that I couldn't find any place saying so.
>>> Not sure how I should interpret this: do you (reluctantly, possibly)
>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
>> I really think we need to get confirmation on this from ACPI folks.
> 
> Who should those people be? linux-acpi?

That may yield valuable, but not dependable input. I'd rather think of
folks actually working on / contributing to the spec. I'm sure Intel can
name a few of their employees ...

>> And I think (and I said so before) we need to understand all the
>> other implications from setting that flag (i.e. we _cannot_ use this
>> flag _just_ to indicate there's no SCI).
> 
> FWIW, the Microsoft's reading is
> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req 
> uirements-for-soc-based-platforms
> 
> ACPI fixed hardware features such as the following are not required:
>     Power Management (PM) timer
>     Real Time Clock (RTC) wake alarm
>     System Control Interrupt (SCI)
>     Fixed Hardware register set (PMx_* event/control/status registers)
>     GPE block registers (GPEx_* event/control/status registers)
>     Embedded controller
> 
> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
> to prevent initialization of SCI.

Well, we could of course start out with HW-reduced mode, but we'd
then need to settle on all aspects before any of this becomes fully
supported.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-07 15:41               ` Jan Beulich
@ 2016-06-08 22:04                 ` Boris Ostrovsky
  2016-06-09  8:13                   ` Roger Pau Monné
  0 siblings, 1 reply; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-08 22:04 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Keir Fraser, Tim Deegan, xen-devel, Ian Jackson, roger.pau

On 06/07/2016 11:41 AM, Jan Beulich wrote:
>>>> On 07.06.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
>> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
>>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>>>>> With this flags set guests will not try to set up SCI.
>>>>>>> I've just read through the respective ACPI spec section again, and
>>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>>>>> consequences of setting that flag, so in order to understand the
>>>>>>> reasons behind this change in case of future problems I think the
>>>>>>> description here will need to be significantly extended, despite the
>>>>>>> change being so small.
>>>>>> My understanding is that hardware-reduced platforms don't use ACPI
>>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>>>>> model is disabled (no SCIs are generated) ..."
>>>>> In the sum of all the non-explicit wording I can only convince myself
>>>>> that SCI is a prereq for the event model. Yet I could see this being
>>>>> an if-and-only-if, just that I couldn't find any place saying so.
>>>> Not sure how I should interpret this: do you (reluctantly, possibly)
>>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
>>> I really think we need to get confirmation on this from ACPI folks.
>> Who should those people be? linux-acpi?
> That may yield valuable, but not dependable input. I'd rather think of
> folks actually working on / contributing to the spec. I'm sure Intel can
> name a few of their employees ...
>
>>> And I think (and I said so before) we need to understand all the
>>> other implications from setting that flag (i.e. we _cannot_ use this
>>> flag _just_ to indicate there's no SCI).
>> FWIW, the Microsoft's reading is
>> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req 
>> uirements-for-soc-based-platforms
>>
>> ACPI fixed hardware features such as the following are not required:
>>     Power Management (PM) timer
>>     Real Time Clock (RTC) wake alarm
>>     System Control Interrupt (SCI)
>>     Fixed Hardware register set (PMx_* event/control/status registers)
>>     GPE block registers (GPEx_* event/control/status registers)
>>     Embedded controller
>>
>> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
>> to prevent initialization of SCI.
> Well, we could of course start out with HW-reduced mode, but we'd
> then need to settle on all aspects before any of this becomes fully
> supported.

So it looks like we can avoid needing this mode in Linux by simply
allocating an irq descriptor for the SCI. We shouldn't receive anything
on that interrupt in PVH anyway.

I don't know whether this will work for other OSs (i.e. FreeBSD).

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-08 22:04                 ` Boris Ostrovsky
@ 2016-06-09  8:13                   ` Roger Pau Monné
  2016-06-09  8:41                     ` Jan Beulich
  0 siblings, 1 reply; 91+ messages in thread
From: Roger Pau Monné @ 2016-06-09  8:13 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, xen-devel

On Wed, Jun 08, 2016 at 06:04:01PM -0400, Boris Ostrovsky wrote:
> On 06/07/2016 11:41 AM, Jan Beulich wrote:
> >>>> On 07.06.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
> >> On 06/07/2016 10:12 AM, Jan Beulich wrote:
> >>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
> >>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
> >>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
> >>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
> >>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> >>>>>>>> With this flags set guests will not try to set up SCI.
> >>>>>>> I've just read through the respective ACPI spec section again, and
> >>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
> >>>>>>> ACPI"). Can you clarify this connection please. Also there are other
> >>>>>>> consequences of setting that flag, so in order to understand the
> >>>>>>> reasons behind this change in case of future problems I think the
> >>>>>>> description here will need to be significantly extended, despite the
> >>>>>>> change being so small.
> >>>>>> My understanding is that hardware-reduced platforms don't use ACPI
> >>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
> >>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
> >>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
> >>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
> >>>>>> model is disabled (no SCIs are generated) ..."
> >>>>> In the sum of all the non-explicit wording I can only convince myself
> >>>>> that SCI is a prereq for the event model. Yet I could see this being
> >>>>> an if-and-only-if, just that I couldn't find any place saying so.
> >>>> Not sure how I should interpret this: do you (reluctantly, possibly)
> >>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
> >>> I really think we need to get confirmation on this from ACPI folks.
> >> Who should those people be? linux-acpi?
> > That may yield valuable, but not dependable input. I'd rather think of
> > folks actually working on / contributing to the spec. I'm sure Intel can
> > name a few of their employees ...
> >
> >>> And I think (and I said so before) we need to understand all the
> >>> other implications from setting that flag (i.e. we _cannot_ use this
> >>> flag _just_ to indicate there's no SCI).
> >> FWIW, the Microsoft's reading is
> >> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req 
> >> uirements-for-soc-based-platforms
> >>
> >> ACPI fixed hardware features such as the following are not required:
> >>     Power Management (PM) timer
> >>     Real Time Clock (RTC) wake alarm
> >>     System Control Interrupt (SCI)
> >>     Fixed Hardware register set (PMx_* event/control/status registers)
> >>     GPE block registers (GPEx_* event/control/status registers)
> >>     Embedded controller
> >>
> >> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
> >> to prevent initialization of SCI.
> > Well, we could of course start out with HW-reduced mode, but we'd
> > then need to settle on all aspects before any of this becomes fully
> > supported.
> 
> So it looks like we can avoid needing this mode in Linux by simply
> allocating an irq descriptor for the SCI. We shouldn't receive anything
> on that interrupt in PVH anyway.
> 
> I don't know whether this will work for other OSs (i.e. FreeBSD).

I will have to check this, but AFAICT, setting the Hardware-Reduced ACPI 
make sense IMHO for DomU, since we are not providing a PM timer, RTC, SCI or 
any of those PMx and GPEx registers. Not setting it would mean that we would 
have to provide all those in order to comply with the ACPI specification.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-09  8:13                   ` Roger Pau Monné
@ 2016-06-09  8:41                     ` Jan Beulich
  2016-06-09 14:09                       ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Jan Beulich @ 2016-06-09  8:41 UTC (permalink / raw)
  To: Roger Pau Monné, Boris Ostrovsky
  Cc: Keir Fraser, Tim Deegan, Ian Jackson, xen-devel

>>> On 09.06.16 at 10:13, <roger.pau@citrix.com> wrote:
> On Wed, Jun 08, 2016 at 06:04:01PM -0400, Boris Ostrovsky wrote:
>> On 06/07/2016 11:41 AM, Jan Beulich wrote:
>> >>>> On 07.06.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
>> >> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>> >>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
>> >>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>> >>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>> >>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>> >>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>> >>>>>>>> With this flags set guests will not try to set up SCI.
>> >>>>>>> I've just read through the respective ACPI spec section again, and
>> >>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>> >>>>>>> ACPI"). Can you clarify this connection please. Also there are other
>> >>>>>>> consequences of setting that flag, so in order to understand the
>> >>>>>>> reasons behind this change in case of future problems I think the
>> >>>>>>> description here will need to be significantly extended, despite the
>> >>>>>>> change being so small.
>> >>>>>> My understanding is that hardware-reduced platforms don't use ACPI
>> >>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>> >>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>> >>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>> >>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>> >>>>>> model is disabled (no SCIs are generated) ..."
>> >>>>> In the sum of all the non-explicit wording I can only convince myself
>> >>>>> that SCI is a prereq for the event model. Yet I could see this being
>> >>>>> an if-and-only-if, just that I couldn't find any place saying so.
>> >>>> Not sure how I should interpret this: do you (reluctantly, possibly)
>> >>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
>> >>> I really think we need to get confirmation on this from ACPI folks.
>> >> Who should those people be? linux-acpi?
>> > That may yield valuable, but not dependable input. I'd rather think of
>> > folks actually working on / contributing to the spec. I'm sure Intel can
>> > name a few of their employees ...
>> >
>> >>> And I think (and I said so before) we need to understand all the
>> >>> other implications from setting that flag (i.e. we _cannot_ use this
>> >>> flag _just_ to indicate there's no SCI).
>> >> FWIW, the Microsoft's reading is
>> >> 
> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req 
> 
>> >> uirements-for-soc-based-platforms
>> >>
>> >> ACPI fixed hardware features such as the following are not required:
>> >>     Power Management (PM) timer
>> >>     Real Time Clock (RTC) wake alarm
>> >>     System Control Interrupt (SCI)
>> >>     Fixed Hardware register set (PMx_* event/control/status registers)
>> >>     GPE block registers (GPEx_* event/control/status registers)
>> >>     Embedded controller
>> >>
>> >> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
>> >> to prevent initialization of SCI.
>> > Well, we could of course start out with HW-reduced mode, but we'd
>> > then need to settle on all aspects before any of this becomes fully
>> > supported.
>> 
>> So it looks like we can avoid needing this mode in Linux by simply
>> allocating an irq descriptor for the SCI. We shouldn't receive anything
>> on that interrupt in PVH anyway.
>> 
>> I don't know whether this will work for other OSs (i.e. FreeBSD).
> 
> I will have to check this, but AFAICT, setting the Hardware-Reduced ACPI 
> make sense IMHO for DomU, since we are not providing a PM timer, RTC, SCI or 
> any of those PMx and GPEx registers. Not setting it would mean that we would 
> have to provide all those in order to comply with the ACPI specification.

That's true for the current black-or-white model, but won't be
true anymore as soon as we allow other than emulate-all and
emulate-nothing.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported
  2016-06-09  8:41                     ` Jan Beulich
@ 2016-06-09 14:09                       ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-09 14:09 UTC (permalink / raw)
  To: Jan Beulich, Roger Pau Monné
  Cc: Keir Fraser, Tim Deegan, Ian Jackson, xen-devel

On 06/09/2016 04:41 AM, Jan Beulich wrote:
>>>> On 09.06.16 at 10:13, <roger.pau@citrix.com> wrote:
>> On Wed, Jun 08, 2016 at 06:04:01PM -0400, Boris Ostrovsky wrote:
>>> On 06/07/2016 11:41 AM, Jan Beulich wrote:
>>>>>>> On 07.06.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
>>>>> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>>>>>>>>> On 07.06.16 at 16:02, <boris.ostrovsky@oracle.com> wrote:
>>>>>>> On 06/07/2016 02:06 AM, Jan Beulich wrote:
>>>>>>>>>>> On 06.06.16 at 19:31, <boris.ostrovsky@oracle.com> wrote:
>>>>>>>>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>>>>>>>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>>>>>>>> With this flags set guests will not try to set up SCI.
>>>>>>>>>> I've just read through the respective ACPI spec section again, and
>>>>>>>>>> I couldn't find a reference to SCI from there ("Hardware-Reduced
>>>>>>>>>> ACPI"). Can you clarify this connection please. Also there are other
>>>>>>>>>> consequences of setting that flag, so in order to understand the
>>>>>>>>>> reasons behind this change in case of future problems I think the
>>>>>>>>>> description here will need to be significantly extended, despite the
>>>>>>>>>> change being so small.
>>>>>>>>> My understanding is that hardware-reduced platforms don't use ACPI
>>>>>>>>> Platform Event Model (Sec. 4.1.1) and that model requires SCI (and vice
>>>>>>>>> versa --- SCI is present when ACPI Platform Event Model is in use). The
>>>>>>>>> (somewhat indirect) evidence of this is in section 4.6 "The ACPI
>>>>>>>>> Hardware Model" where is says: "In the ACPI Legacy state, the ACPI event
>>>>>>>>> model is disabled (no SCIs are generated) ..."
>>>>>>>> In the sum of all the non-explicit wording I can only convince myself
>>>>>>>> that SCI is a prereq for the event model. Yet I could see this being
>>>>>>>> an if-and-only-if, just that I couldn't find any place saying so.
>>>>>>> Not sure how I should interpret this: do you (reluctantly, possibly)
>>>>>>> agree that we can use HW-reduced flag to indicate that SCI is not there?
>>>>>> I really think we need to get confirmation on this from ACPI folks.
>>>>> Who should those people be? linux-acpi?
>>>> That may yield valuable, but not dependable input. I'd rather think of
>>>> folks actually working on / contributing to the spec. I'm sure Intel can
>>>> name a few of their employees ...
>>>>
>>>>>> And I think (and I said so before) we need to understand all the
>>>>>> other implications from setting that flag (i.e. we _cannot_ use this
>>>>>> flag _just_ to indicate there's no SCI).
>>>>> FWIW, the Microsoft's reading is
>>>>>
>> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/hardware-req 
>>
>>>>> uirements-for-soc-based-platforms
>>>>>
>>>>> ACPI fixed hardware features such as the following are not required:
>>>>>     Power Management (PM) timer
>>>>>     Real Time Clock (RTC) wake alarm
>>>>>     System Control Interrupt (SCI)
>>>>>     Fixed Hardware register set (PMx_* event/control/status registers)
>>>>>     GPE block registers (GPEx_* event/control/status registers)
>>>>>     Embedded controller
>>>>>
>>>>> Also, from ACPICA perpective, HW-reduced mode appears to be the only way
>>>>> to prevent initialization of SCI.
>>>> Well, we could of course start out with HW-reduced mode, but we'd
>>>> then need to settle on all aspects before any of this becomes fully
>>>> supported.
>>> So it looks like we can avoid needing this mode in Linux by simply
>>> allocating an irq descriptor for the SCI. We shouldn't receive anything
>>> on that interrupt in PVH anyway.
>>>
>>> I don't know whether this will work for other OSs (i.e. FreeBSD).
>> I will have to check this, but AFAICT, setting the Hardware-Reduced ACPI 
>> make sense IMHO for DomU, since we are not providing a PM timer, RTC, SCI or 
>> any of those PMx and GPEx registers. Not setting it would mean that we would 
>> have to provide all those in order to comply with the ACPI specification.
> That's true for the current black-or-white model, but won't be
> true anymore as soon as we allow other than emulate-all and
> emulate-nothing.

We probably don't want to be too fine-grained about what we emulate. So
one option could be that we either emulate all devices that Roger listed
above or none.

Also, there is a more definitive answer in the spec about what
HW-reduced mode means as far as SCI (and other features) is concerned:
"5.2.9 Fixed ACPI Description Table (FADT)", Note above table 5-34.


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-06 15:15     ` Boris Ostrovsky
@ 2016-06-16  8:54       ` Wei Liu
  2016-06-16 13:07         ` Boris Ostrovsky
  0 siblings, 1 reply; 91+ messages in thread
From: Wei Liu @ 2016-06-16  8:54 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: roger.pau, Wei Liu, Stefano Stabellini, xen-devel

On Mon, Jun 06, 2016 at 11:15:22AM -0400, Boris Ostrovsky wrote:
[...]
> > +static int init_acpi_config(struct xc_dom_image *dom,
> > +                            struct acpi_config *config)
> > +{
> > +    xc_interface *xch = dom->xch;
> > +    uint32_t domid = dom->guest_domid;
> > +    xc_dominfo_t info;
> > +    int i, rc;
> > +
> > +    memset(config, 0, sizeof(*config));
> > +
> > +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
> > +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
> > +
> > +    rc = xc_domain_getinfo(xch, domid, 1, &info);
> > +    if ( rc < 0 )
> > +    {
> > +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
> > +        return rc;
> > +    }
> > +
> > +    config->apic_mode = 1;
> > +
> > +    if ( dom->nr_vnodes )
> > +    {
> > +        struct acpi_numa *numa = &config->numa;
> > +
> > +        numa->vmemrange = calloc(dom->nr_vmemranges,
> > +                                 sizeof(*numa->vmemrange));
> > +        numa->vdistance = calloc(dom->nr_vnodes,
> > +                                 sizeof(*numa->vdistance));
> > +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
> > +                                     sizeof(*numa->vcpu_to_vnode));
> > +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
> > +        {
> > +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
> > +            free(numa->vmemrange);
> > +            free(numa->vdistance);
> > +            free(numa->vcpu_to_vnode);
> > +            return -ENOMEM;
> > +        }
> > +
> > +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> > +                                &numa->nr_vmemranges,
> > +                                &config->nr_vcpus, numa->vmemrange,
> > +                                numa->vdistance, numa->vcpu_to_vnode);
> > +
> > +	    if ( rc )
> > +        {
> > +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
> > +            return rc;
> > +        }
> > +    }
> > +    else
> > +        config->nr_vcpus = info.max_vcpu_id + 1;
> > This looks wrong, at least it is not immediately clear why you would
> > want to do this.
> 
> 
> Why is this wrong? If we have one VCPU max_vcpu_id will be zero, won't it?
> 

I'm not saying it is absolutely wrong, just that I don't quite
understand why it is coded this way.

It's guarded by dom->nr_vnodes and the code is not immediately clear why
you want to do that. Perhaps you can add a comment here?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

* Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
  2016-06-16  8:54       ` Wei Liu
@ 2016-06-16 13:07         ` Boris Ostrovsky
  0 siblings, 0 replies; 91+ messages in thread
From: Boris Ostrovsky @ 2016-06-16 13:07 UTC (permalink / raw)
  To: Wei Liu; +Cc: roger.pau, Stefano Stabellini, xen-devel

On 06/16/2016 04:54 AM, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 11:15:22AM -0400, Boris Ostrovsky wrote:
> [...]
>>> +static int init_acpi_config(struct xc_dom_image *dom,
>>> +                            struct acpi_config *config)
>>> +{
>>> +    xc_interface *xch = dom->xch;
>>> +    uint32_t domid = dom->guest_domid;
>>> +    xc_dominfo_t info;
>>> +    int i, rc;
>>> +
>>> +    memset(config, 0, sizeof(*config));
>>> +
>>> +    config->dsdt_anycpu = config->dsdt_15cpu = dsdt_empty;
>>> +    config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_empty_len;
>>> +
>>> +    rc = xc_domain_getinfo(xch, domid, 1, &info);
>>> +    if ( rc < 0 )
>>> +    {
>>> +        DOMPRINTF("%s: getdomaininfo failed (rc=%d)", __FUNCTION__, rc);
>>> +        return rc;
>>> +    }
>>> +
>>> +    config->apic_mode = 1;
>>> +
>>> +    if ( dom->nr_vnodes )
>>> +    {
>>> +        struct acpi_numa *numa = &config->numa;
>>> +
>>> +        numa->vmemrange = calloc(dom->nr_vmemranges,
>>> +                                 sizeof(*numa->vmemrange));
>>> +        numa->vdistance = calloc(dom->nr_vnodes,
>>> +                                 sizeof(*numa->vdistance));
>>> +        numa->vcpu_to_vnode = calloc(config->nr_vcpus,
>>> +                                     sizeof(*numa->vcpu_to_vnode));
>>> +        if ( !numa->vmemrange || !numa->vdistance || !numa->vcpu_to_vnode )
>>> +        {
>>> +            DOMPRINTF("%s: Out of memory", __FUNCTION__);
>>> +            free(numa->vmemrange);
>>> +            free(numa->vdistance);
>>> +            free(numa->vcpu_to_vnode);
>>> +            return -ENOMEM;
>>> +        }
>>> +
>>> +        rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
>>> +                                &numa->nr_vmemranges,
>>> +                                &config->nr_vcpus, numa->vmemrange,
>>> +                                numa->vdistance, numa->vcpu_to_vnode);
>>> +
>>> +	    if ( rc )
>>> +        {
>>> +            DOMPRINTF("%s: xc_domain_getvnuma failed (rc=%d)", __FUNCTION__, rc);
>>> +            return rc;
>>> +        }
>>> +    }
>>> +    else
>>> +        config->nr_vcpus = info.max_vcpu_id + 1;
>>> This looks wrong, at least it is not immediately clear why you would
>>> want to do this.
>>
>> Why is this wrong? If we have one VCPU max_vcpu_id will be zero, won't it?
>>
> I'm not saying it is absolutely wrong, just that I don't quite
> understand why it is coded this way.
>
> It's guarded by dom->nr_vnodes and the code is not immediately clear why
> you want to do that. Perhaps you can add a comment here?

So this actually *is* wrong: I am trying to calloc(config->nr_vcpus,...)
before I call xc_domain_getvnuma(), which sets config->nr_vcpus. And I
suspect the same is true for nr_vmemranges.

I think I lost an earlier call to xc_domain_getvnuma(.., NULL, NULL, NULL).

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 91+ messages in thread

end of thread, other threads:[~2016-06-16 13:07 UTC | newest]

Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-06  1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
2016-06-02 12:42   ` Jan Beulich
2016-06-02 16:39     ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
2016-06-02 12:54   ` Jan Beulich
2016-06-02 16:54     ` Boris Ostrovsky
2016-06-03 12:13       ` Jan Beulich
2016-06-03 14:42         ` Boris Ostrovsky
2016-06-03 14:55           ` Jan Beulich
2016-06-03 15:29             ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
2016-06-02 13:03   ` Jan Beulich
2016-06-02 17:01     ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
2016-06-02 13:07   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
2016-06-02 13:52   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
2016-06-02 14:05   ` Jan Beulich
2016-06-02 17:18     ` Boris Ostrovsky
2016-06-03 12:16       ` Jan Beulich
2016-06-03 14:49         ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
2016-06-02 14:09   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
2016-06-02 14:32   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
2016-06-03 16:03   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
2016-06-06 10:48   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
2016-06-06 11:04   ` Jan Beulich
2016-06-06 14:20     ` Boris Ostrovsky
2016-06-06 14:29       ` Jan Beulich
2016-06-06 14:49         ` Boris Ostrovsky
2016-06-06 14:57           ` Jan Beulich
2016-06-06 15:31           ` Andrew Cooper
2016-06-06 15:41             ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
2016-06-06 11:31   ` Jan Beulich
2016-06-06 15:08     ` Boris Ostrovsky
2016-06-06 15:22       ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
2016-06-06 12:58   ` Jan Beulich
2016-06-06 15:46     ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
2016-06-06 13:05   ` Jan Beulich
2016-06-06 16:09     ` Boris Ostrovsky
2016-06-07  6:20       ` Jan Beulich
2016-06-07 12:24       ` Roger Pau Monné
2016-06-07 14:32         ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
2016-06-03 16:14   ` Jan Beulich
2016-06-03 17:50     ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
2016-06-03 16:18   ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
2016-06-02 16:26   ` Roger Pau Monné
2016-06-06 12:03   ` Wei Liu
2016-06-06 15:15     ` Boris Ostrovsky
2016-06-16  8:54       ` Wei Liu
2016-06-16 13:07         ` Boris Ostrovsky
2016-06-06 13:29   ` Jan Beulich
2016-06-06 16:59     ` Boris Ostrovsky
2016-06-07  6:17       ` Jan Beulich
2016-06-07 13:59         ` Boris Ostrovsky
2016-06-07 14:10           ` Jan Beulich
2016-06-07 14:47             ` Boris Ostrovsky
2016-06-07 15:00               ` Jan Beulich
2016-04-06  1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
2016-06-06 13:38   ` Jan Beulich
2016-06-06 17:31     ` Boris Ostrovsky
2016-06-07  6:06       ` Jan Beulich
2016-06-07 14:02         ` Boris Ostrovsky
2016-06-07 14:12           ` Jan Beulich
2016-06-07 15:17             ` Boris Ostrovsky
2016-06-07 15:41               ` Jan Beulich
2016-06-08 22:04                 ` Boris Ostrovsky
2016-06-09  8:13                   ` Roger Pau Monné
2016-06-09  8:41                     ` Jan Beulich
2016-06-09 14:09                       ` Boris Ostrovsky
2016-04-06  1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
2016-06-06 13:48   ` Jan Beulich
2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-05-10  7:25   ` Jan Beulich
2016-06-02 12:40 ` Jan Beulich
2016-06-02 16:37   ` Boris Ostrovsky
2016-06-03  7:18     ` Roger Pau Monné
2016-06-03 10:08       ` Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).