[Qemu-devel] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Qemu-devel] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Alexander Spyridakis]

Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
implemented in this patch series, which is the minimum for a basic ARM support.

The set of generated tables are:
- RSDP
- XSDT
- MADT
- GTDT
- FADT
- FACS
- DSDT

The tables are created in standalone buffers, taking into account the
needed information passed from the virt machine model. When the generation
is finalized, the individual buffers are compacted to a single ACPI binary
blob, where it is injected on the guest memory space in a fixed location.
The guest kernel can find the ACPI tables by providing to it the physical
address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).

This series has been tested on the Foundation Model 0.8 build 5206 and
the Juno development board. For kernel and driver support it is based
on the "Introduce ACPI for ARM64 based on ACPI 5.1" and
"Drivers for Juno to boot from ACPI" patch series from Hanjun Guo.

Alexander Spyridakis (7):
  hw/i386: Move ACPI header definitions in an arch-independent location
  hw/arm/virt-acpi: Basic skeleton for dynamic generation of ACPI tables
  hw/arm/virt-acpi: Generate RSDP and XSDT, add helper functions
  hw/arm/virt-acpi: Generate FACS and FADT, update ACPI headers
  hw/arm/virt-acpi: GIC and Arch Timer definitions in MADT and GTDT
  hw/arm/virt-acpi: Generation of DSDT including virt devices
  hw/arm/virt: Enable dynamic generation of ACPI v5.1 tables

 hw/arm/Makefile.objs        |   2 +-
 hw/arm/boot.c               |  26 +++
 hw/arm/virt-acpi.c          | 555 ++++++++++++++++++++++++++++++++++++++++++++
 hw/arm/virt.c               |  54 ++++-
 hw/i386/acpi-build.c        |   2 +-
 hw/i386/acpi-defs.h         | 368 -----------------------------
 include/hw/acpi/acpi-defs.h | 535 ++++++++++++++++++++++++++++++++++++++++++
 include/hw/arm/arm.h        |   2 +
 include/hw/arm/virt-acpi.h  |  73 ++++++
 tests/bios-tables-test.c    |   2 +-
 10 files changed, 1244 insertions(+), 375 deletions(-)
 create mode 100644 hw/arm/virt-acpi.c
 delete mode 100644 hw/i386/acpi-defs.h
 create mode 100644 include/hw/acpi/acpi-defs.h
 create mode 100644 include/hw/arm/virt-acpi.h

-- 
1.9.1

[Qemu-devel] [RFC PATCH 1/7] hw/i386: Move ACPI header definitions in an arch-independent location

[Alexander Spyridakis]

The ACPI related header file acpi-defs.h, includes definitions that
apply on other architectures as well. Move it in `include/hw/acpi/`
to sanely include it from other architectures.

Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com>
---
 hw/i386/acpi-build.c        |   2 +-
 hw/i386/acpi-defs.h         | 368 --------------------------------------------
 include/hw/acpi/acpi-defs.h | 368 ++++++++++++++++++++++++++++++++++++++++++++
 tests/bios-tables-test.c    |   2 +-
 4 files changed, 370 insertions(+), 370 deletions(-)
 delete mode 100644 hw/i386/acpi-defs.h
 create mode 100644 include/hw/acpi/acpi-defs.h

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 00be4bb..1888420 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -33,7 +33,7 @@
 #include "hw/i386/pc.h"
 #include "target-i386/cpu.h"
 #include "hw/timer/hpet.h"
-#include "hw/i386/acpi-defs.h"
+#include "hw/acpi/acpi-defs.h"
 #include "hw/acpi/acpi.h"
 #include "hw/nvram/fw_cfg.h"
 #include "bios-linker-loader.h"
diff --git a/hw/i386/acpi-defs.h b/hw/i386/acpi-defs.h
deleted file mode 100644
index c4468f8..0000000
--- a/hw/i386/acpi-defs.h
+++ /dev/null
@@ -1,368 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
-
- * This program is distributed in the hope that 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/>.
- */
-#ifndef QEMU_ACPI_DEFS_H
-#define QEMU_ACPI_DEFS_H
-
-enum {
-    ACPI_FADT_F_WBINVD,
-    ACPI_FADT_F_WBINVD_FLUSH,
-    ACPI_FADT_F_PROC_C1,
-    ACPI_FADT_F_P_LVL2_UP,
-    ACPI_FADT_F_PWR_BUTTON,
-    ACPI_FADT_F_SLP_BUTTON,
-    ACPI_FADT_F_FIX_RTC,
-    ACPI_FADT_F_RTC_S4,
-    ACPI_FADT_F_TMR_VAL_EXT,
-    ACPI_FADT_F_DCK_CAP,
-    ACPI_FADT_F_RESET_REG_SUP,
-    ACPI_FADT_F_SEALED_CASE,
-    ACPI_FADT_F_HEADLESS,
-    ACPI_FADT_F_CPU_SW_SLP,
-    ACPI_FADT_F_PCI_EXP_WAK,
-    ACPI_FADT_F_USE_PLATFORM_CLOCK,
-    ACPI_FADT_F_S4_RTC_STS_VALID,
-    ACPI_FADT_F_REMOTE_POWER_ON_CAPABLE,
-    ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL,
-    ACPI_FADT_F_FORCE_APIC_PHYSICAL_DESTINATION_MODE,
-    ACPI_FADT_F_HW_REDUCED_ACPI,
-    ACPI_FADT_F_LOW_POWER_S0_IDLE_CAPABLE,
-};
-
-/*
- * ACPI 2.0 Generic Address Space definition.
- */
-struct Acpi20GenericAddress {
-    uint8_t  address_space_id;
-    uint8_t  register_bit_width;
-    uint8_t  register_bit_offset;
-    uint8_t  reserved;
-    uint64_t address;
-} QEMU_PACKED;
-typedef struct Acpi20GenericAddress Acpi20GenericAddress;
-
-struct AcpiRsdpDescriptor {        /* Root System Descriptor Pointer */
-    uint64_t signature;              /* ACPI signature, contains "RSD PTR " */
-    uint8_t  checksum;               /* To make sum of struct == 0 */
-    uint8_t  oem_id [6];             /* OEM identification */
-    uint8_t  revision;               /* Must be 0 for 1.0, 2 for 2.0 */
-    uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
-    uint32_t length;                 /* XSDT Length in bytes including hdr */
-    uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
-    uint8_t  extended_checksum;      /* Checksum of entire table */
-    uint8_t  reserved [3];           /* Reserved field must be 0 */
-} QEMU_PACKED;
-typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor;
-
-/* Table structure from Linux kernel (the ACPI tables are under the
-   BSD license) */
-
-
-#define ACPI_TABLE_HEADER_DEF   /* ACPI common table header */ \
-    uint32_t signature;          /* ACPI signature (4 ASCII characters) */ \
-    uint32_t length;                 /* Length of table, in bytes, including header */ \
-    uint8_t  revision;               /* ACPI Specification minor version # */ \
-    uint8_t  checksum;               /* To make sum of entire table == 0 */ \
-    uint8_t  oem_id [6];             /* OEM identification */ \
-    uint8_t  oem_table_id [8];       /* OEM table identification */ \
-    uint32_t oem_revision;           /* OEM revision number */ \
-    uint8_t  asl_compiler_id [4];    /* ASL compiler vendor ID */ \
-    uint32_t asl_compiler_revision;  /* ASL compiler revision number */
-
-
-struct AcpiTableHeader         /* ACPI common table header */
-{
-    ACPI_TABLE_HEADER_DEF
-} QEMU_PACKED;
-typedef struct AcpiTableHeader AcpiTableHeader;
-
-/*
- * ACPI 1.0 Fixed ACPI Description Table (FADT)
- */
-struct AcpiFadtDescriptorRev1
-{
-    ACPI_TABLE_HEADER_DEF     /* ACPI common table header */
-    uint32_t firmware_ctrl;          /* Physical address of FACS */
-    uint32_t dsdt;                   /* Physical address of DSDT */
-    uint8_t  model;                  /* System Interrupt Model */
-    uint8_t  reserved1;              /* Reserved */
-    uint16_t sci_int;                /* System vector of SCI interrupt */
-    uint32_t smi_cmd;                /* Port address of SMI command port */
-    uint8_t  acpi_enable;            /* Value to write to smi_cmd to enable ACPI */
-    uint8_t  acpi_disable;           /* Value to write to smi_cmd to disable ACPI */
-    uint8_t  S4bios_req;             /* Value to write to SMI CMD to enter S4BIOS state */
-    uint8_t  reserved2;              /* Reserved - must be zero */
-    uint32_t pm1a_evt_blk;           /* Port address of Power Mgt 1a acpi_event Reg Blk */
-    uint32_t pm1b_evt_blk;           /* Port address of Power Mgt 1b acpi_event Reg Blk */
-    uint32_t pm1a_cnt_blk;           /* Port address of Power Mgt 1a Control Reg Blk */
-    uint32_t pm1b_cnt_blk;           /* Port address of Power Mgt 1b Control Reg Blk */
-    uint32_t pm2_cnt_blk;            /* Port address of Power Mgt 2 Control Reg Blk */
-    uint32_t pm_tmr_blk;             /* Port address of Power Mgt Timer Ctrl Reg Blk */
-    uint32_t gpe0_blk;               /* Port addr of General Purpose acpi_event 0 Reg Blk */
-    uint32_t gpe1_blk;               /* Port addr of General Purpose acpi_event 1 Reg Blk */
-    uint8_t  pm1_evt_len;            /* Byte length of ports at pm1_x_evt_blk */
-    uint8_t  pm1_cnt_len;            /* Byte length of ports at pm1_x_cnt_blk */
-    uint8_t  pm2_cnt_len;            /* Byte Length of ports at pm2_cnt_blk */
-    uint8_t  pm_tmr_len;             /* Byte Length of ports at pm_tm_blk */
-    uint8_t  gpe0_blk_len;           /* Byte Length of ports at gpe0_blk */
-    uint8_t  gpe1_blk_len;           /* Byte Length of ports at gpe1_blk */
-    uint8_t  gpe1_base;              /* Offset in gpe model where gpe1 events start */
-    uint8_t  reserved3;              /* Reserved */
-    uint16_t plvl2_lat;              /* Worst case HW latency to enter/exit C2 state */
-    uint16_t plvl3_lat;              /* Worst case HW latency to enter/exit C3 state */
-    uint16_t flush_size;             /* Size of area read to flush caches */
-    uint16_t flush_stride;           /* Stride used in flushing caches */
-    uint8_t  duty_offset;            /* Bit location of duty cycle field in p_cnt reg */
-    uint8_t  duty_width;             /* Bit width of duty cycle field in p_cnt reg */
-    uint8_t  day_alrm;               /* Index to day-of-month alarm in RTC CMOS RAM */
-    uint8_t  mon_alrm;               /* Index to month-of-year alarm in RTC CMOS RAM */
-    uint8_t  century;                /* Index to century in RTC CMOS RAM */
-    uint8_t  reserved4;              /* Reserved */
-    uint8_t  reserved4a;             /* Reserved */
-    uint8_t  reserved4b;             /* Reserved */
-    uint32_t flags;
-} QEMU_PACKED;
-typedef struct AcpiFadtDescriptorRev1 AcpiFadtDescriptorRev1;
-
-/*
- * ACPI 1.0 Root System Description Table (RSDT)
- */
-struct AcpiRsdtDescriptorRev1
-{
-    ACPI_TABLE_HEADER_DEF       /* ACPI common table header */
-    uint32_t table_offset_entry[0];  /* Array of pointers to other */
-    /* ACPI tables */
-} QEMU_PACKED;
-typedef struct AcpiRsdtDescriptorRev1 AcpiRsdtDescriptorRev1;
-
-/*
- * ACPI 1.0 Firmware ACPI Control Structure (FACS)
- */
-struct AcpiFacsDescriptorRev1
-{
-    uint32_t signature;           /* ACPI Signature */
-    uint32_t length;                 /* Length of structure, in bytes */
-    uint32_t hardware_signature;     /* Hardware configuration signature */
-    uint32_t firmware_waking_vector; /* ACPI OS waking vector */
-    uint32_t global_lock;            /* Global Lock */
-    uint32_t flags;
-    uint8_t  resverved3 [40];        /* Reserved - must be zero */
-} QEMU_PACKED;
-typedef struct AcpiFacsDescriptorRev1 AcpiFacsDescriptorRev1;
-
-/*
- * Differentiated System Description Table (DSDT)
- */
-
-/*
- * MADT values and structures
- */
-
-/* Values for MADT PCATCompat */
-
-#define ACPI_DUAL_PIC                0
-#define ACPI_MULTIPLE_APIC           1
-
-/* Master MADT */
-
-struct AcpiMultipleApicTable
-{
-    ACPI_TABLE_HEADER_DEF     /* ACPI common table header */
-    uint32_t local_apic_address;     /* Physical address of local APIC */
-    uint32_t flags;
-} QEMU_PACKED;
-typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
-
-/* Values for Type in APIC sub-headers */
-
-#define ACPI_APIC_PROCESSOR          0
-#define ACPI_APIC_IO                 1
-#define ACPI_APIC_XRUPT_OVERRIDE     2
-#define ACPI_APIC_NMI                3
-#define ACPI_APIC_LOCAL_NMI          4
-#define ACPI_APIC_ADDRESS_OVERRIDE   5
-#define ACPI_APIC_IO_SAPIC           6
-#define ACPI_APIC_LOCAL_SAPIC        7
-#define ACPI_APIC_XRUPT_SOURCE       8
-#define ACPI_APIC_RESERVED           9           /* 9 and greater are reserved */
-
-/*
- * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE)
- */
-#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
-    uint8_t  type;                               \
-    uint8_t  length;
-
-/* Sub-structures for MADT */
-
-struct AcpiMadtProcessorApic
-{
-    ACPI_SUB_HEADER_DEF
-    uint8_t  processor_id;           /* ACPI processor id */
-    uint8_t  local_apic_id;          /* Processor's local APIC id */
-    uint32_t flags;
-} QEMU_PACKED;
-typedef struct AcpiMadtProcessorApic AcpiMadtProcessorApic;
-
-struct AcpiMadtIoApic
-{
-    ACPI_SUB_HEADER_DEF
-    uint8_t  io_apic_id;             /* I/O APIC ID */
-    uint8_t  reserved;               /* Reserved - must be zero */
-    uint32_t address;                /* APIC physical address */
-    uint32_t interrupt;              /* Global system interrupt where INTI
-                                 * lines start */
-} QEMU_PACKED;
-typedef struct AcpiMadtIoApic AcpiMadtIoApic;
-
-struct AcpiMadtIntsrcovr {
-    ACPI_SUB_HEADER_DEF
-    uint8_t  bus;
-    uint8_t  source;
-    uint32_t gsi;
-    uint16_t flags;
-} QEMU_PACKED;
-typedef struct AcpiMadtIntsrcovr AcpiMadtIntsrcovr;
-
-struct AcpiMadtLocalNmi {
-    ACPI_SUB_HEADER_DEF
-    uint8_t  processor_id;           /* ACPI processor id */
-    uint16_t flags;                  /* MPS INTI flags */
-    uint8_t  lint;                   /* Local APIC LINT# */
-} QEMU_PACKED;
-typedef struct AcpiMadtLocalNmi AcpiMadtLocalNmi;
-
-/*
- * HPET Description Table
- */
-struct Acpi20Hpet {
-    ACPI_TABLE_HEADER_DEF                    /* ACPI common table header */
-    uint32_t           timer_block_id;
-    Acpi20GenericAddress addr;
-    uint8_t            hpet_number;
-    uint16_t           min_tick;
-    uint8_t            page_protect;
-} QEMU_PACKED;
-typedef struct Acpi20Hpet Acpi20Hpet;
-
-/*
- * SRAT (NUMA topology description) table
- */
-
-struct AcpiSystemResourceAffinityTable
-{
-    ACPI_TABLE_HEADER_DEF
-    uint32_t    reserved1;
-    uint32_t    reserved2[2];
-} QEMU_PACKED;
-typedef struct AcpiSystemResourceAffinityTable AcpiSystemResourceAffinityTable;
-
-#define ACPI_SRAT_PROCESSOR          0
-#define ACPI_SRAT_MEMORY             1
-
-struct AcpiSratProcessorAffinity
-{
-    ACPI_SUB_HEADER_DEF
-    uint8_t     proximity_lo;
-    uint8_t     local_apic_id;
-    uint32_t    flags;
-    uint8_t     local_sapic_eid;
-    uint8_t     proximity_hi[3];
-    uint32_t    reserved;
-} QEMU_PACKED;
-typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
-
-struct AcpiSratMemoryAffinity
-{
-    ACPI_SUB_HEADER_DEF
-    uint8_t     proximity[4];
-    uint16_t    reserved1;
-    uint64_t    base_addr;
-    uint64_t    range_length;
-    uint32_t    reserved2;
-    uint32_t    flags;
-    uint32_t    reserved3[2];
-} QEMU_PACKED;
-typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
-
-/* PCI fw r3.0 MCFG table. */
-/* Subtable */
-struct AcpiMcfgAllocation {
-    uint64_t address;                /* Base address, processor-relative */
-    uint16_t pci_segment;            /* PCI segment group number */
-    uint8_t start_bus_number;       /* Starting PCI Bus number */
-    uint8_t end_bus_number;         /* Final PCI Bus number */
-    uint32_t reserved;
-} QEMU_PACKED;
-typedef struct AcpiMcfgAllocation AcpiMcfgAllocation;
-
-struct AcpiTableMcfg {
-    ACPI_TABLE_HEADER_DEF;
-    uint8_t reserved[8];
-    AcpiMcfgAllocation allocation[0];
-} QEMU_PACKED;
-typedef struct AcpiTableMcfg AcpiTableMcfg;
-
-/*
- * TCPA Description Table
- */
-struct Acpi20Tcpa {
-    ACPI_TABLE_HEADER_DEF                    /* ACPI common table header */
-    uint16_t platform_class;
-    uint32_t log_area_minimum_length;
-    uint64_t log_area_start_address;
-} QEMU_PACKED;
-typedef struct Acpi20Tcpa Acpi20Tcpa;
-
-/* DMAR - DMA Remapping table r2.2 */
-struct AcpiTableDmar {
-    ACPI_TABLE_HEADER_DEF
-    uint8_t host_address_width; /* Maximum DMA physical addressability */
-    uint8_t flags;
-    uint8_t reserved[10];
-} QEMU_PACKED;
-typedef struct AcpiTableDmar AcpiTableDmar;
-
-/* Masks for Flags field above */
-#define ACPI_DMAR_INTR_REMAP        1
-#define ACPI_DMAR_X2APIC_OPT_OUT    (1 << 1)
-
-/* Values for sub-structure type for DMAR */
-enum {
-    ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,       /* DRHD */
-    ACPI_DMAR_TYPE_RESERVED_MEMORY = 1,     /* RMRR */
-    ACPI_DMAR_TYPE_ATSR = 2,                /* ATSR */
-    ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,   /* RHSR */
-    ACPI_DMAR_TYPE_ANDD = 4,                /* ANDD */
-    ACPI_DMAR_TYPE_RESERVED = 5             /* Reserved for furture use */
-};
-
-/*
- * Sub-structures for DMAR
- */
-/* Type 0: Hardware Unit Definition */
-struct AcpiDmarHardwareUnit {
-    uint16_t type;
-    uint16_t length;
-    uint8_t flags;
-    uint8_t reserved;
-    uint16_t pci_segment;   /* The PCI Segment associated with this unit */
-    uint64_t address;   /* Base address of remapping hardware register-set */
-} QEMU_PACKED;
-typedef struct AcpiDmarHardwareUnit AcpiDmarHardwareUnit;
-
-/* Masks for Flags field above */
-#define ACPI_DMAR_INCLUDE_PCI_ALL   1
-
-#endif
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
new file mode 100644
index 0000000..c4468f8
--- /dev/null
+++ b/include/hw/acpi/acpi-defs.h
@@ -0,0 +1,368 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that 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/>.
+ */
+#ifndef QEMU_ACPI_DEFS_H
+#define QEMU_ACPI_DEFS_H
+
+enum {
+    ACPI_FADT_F_WBINVD,
+    ACPI_FADT_F_WBINVD_FLUSH,
+    ACPI_FADT_F_PROC_C1,
+    ACPI_FADT_F_P_LVL2_UP,
+    ACPI_FADT_F_PWR_BUTTON,
+    ACPI_FADT_F_SLP_BUTTON,
+    ACPI_FADT_F_FIX_RTC,
+    ACPI_FADT_F_RTC_S4,
+    ACPI_FADT_F_TMR_VAL_EXT,
+    ACPI_FADT_F_DCK_CAP,
+    ACPI_FADT_F_RESET_REG_SUP,
+    ACPI_FADT_F_SEALED_CASE,
+    ACPI_FADT_F_HEADLESS,
+    ACPI_FADT_F_CPU_SW_SLP,
+    ACPI_FADT_F_PCI_EXP_WAK,
+    ACPI_FADT_F_USE_PLATFORM_CLOCK,
+    ACPI_FADT_F_S4_RTC_STS_VALID,
+    ACPI_FADT_F_REMOTE_POWER_ON_CAPABLE,
+    ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL,
+    ACPI_FADT_F_FORCE_APIC_PHYSICAL_DESTINATION_MODE,
+    ACPI_FADT_F_HW_REDUCED_ACPI,
+    ACPI_FADT_F_LOW_POWER_S0_IDLE_CAPABLE,
+};
+
+/*
+ * ACPI 2.0 Generic Address Space definition.
+ */
+struct Acpi20GenericAddress {
+    uint8_t  address_space_id;
+    uint8_t  register_bit_width;
+    uint8_t  register_bit_offset;
+    uint8_t  reserved;
+    uint64_t address;
+} QEMU_PACKED;
+typedef struct Acpi20GenericAddress Acpi20GenericAddress;
+
+struct AcpiRsdpDescriptor {        /* Root System Descriptor Pointer */
+    uint64_t signature;              /* ACPI signature, contains "RSD PTR " */
+    uint8_t  checksum;               /* To make sum of struct == 0 */
+    uint8_t  oem_id [6];             /* OEM identification */
+    uint8_t  revision;               /* Must be 0 for 1.0, 2 for 2.0 */
+    uint32_t rsdt_physical_address;  /* 32-bit physical address of RSDT */
+    uint32_t length;                 /* XSDT Length in bytes including hdr */
+    uint64_t xsdt_physical_address;  /* 64-bit physical address of XSDT */
+    uint8_t  extended_checksum;      /* Checksum of entire table */
+    uint8_t  reserved [3];           /* Reserved field must be 0 */
+} QEMU_PACKED;
+typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor;
+
+/* Table structure from Linux kernel (the ACPI tables are under the
+   BSD license) */
+
+
+#define ACPI_TABLE_HEADER_DEF   /* ACPI common table header */ \
+    uint32_t signature;          /* ACPI signature (4 ASCII characters) */ \
+    uint32_t length;                 /* Length of table, in bytes, including header */ \
+    uint8_t  revision;               /* ACPI Specification minor version # */ \
+    uint8_t  checksum;               /* To make sum of entire table == 0 */ \
+    uint8_t  oem_id [6];             /* OEM identification */ \
+    uint8_t  oem_table_id [8];       /* OEM table identification */ \
+    uint32_t oem_revision;           /* OEM revision number */ \
+    uint8_t  asl_compiler_id [4];    /* ASL compiler vendor ID */ \
+    uint32_t asl_compiler_revision;  /* ASL compiler revision number */
+
+
+struct AcpiTableHeader         /* ACPI common table header */
+{
+    ACPI_TABLE_HEADER_DEF
+} QEMU_PACKED;
+typedef struct AcpiTableHeader AcpiTableHeader;
+
+/*
+ * ACPI 1.0 Fixed ACPI Description Table (FADT)
+ */
+struct AcpiFadtDescriptorRev1
+{
+    ACPI_TABLE_HEADER_DEF     /* ACPI common table header */
+    uint32_t firmware_ctrl;          /* Physical address of FACS */
+    uint32_t dsdt;                   /* Physical address of DSDT */
+    uint8_t  model;                  /* System Interrupt Model */
+    uint8_t  reserved1;              /* Reserved */
+    uint16_t sci_int;                /* System vector of SCI interrupt */
+    uint32_t smi_cmd;                /* Port address of SMI command port */
+    uint8_t  acpi_enable;            /* Value to write to smi_cmd to enable ACPI */
+    uint8_t  acpi_disable;           /* Value to write to smi_cmd to disable ACPI */
+    uint8_t  S4bios_req;             /* Value to write to SMI CMD to enter S4BIOS state */
+    uint8_t  reserved2;              /* Reserved - must be zero */
+    uint32_t pm1a_evt_blk;           /* Port address of Power Mgt 1a acpi_event Reg Blk */
+    uint32_t pm1b_evt_blk;           /* Port address of Power Mgt 1b acpi_event Reg Blk */
+    uint32_t pm1a_cnt_blk;           /* Port address of Power Mgt 1a Control Reg Blk */
+    uint32_t pm1b_cnt_blk;           /* Port address of Power Mgt 1b Control Reg Blk */
+    uint32_t pm2_cnt_blk;            /* Port address of Power Mgt 2 Control Reg Blk */
+    uint32_t pm_tmr_blk;             /* Port address of Power Mgt Timer Ctrl Reg Blk */
+    uint32_t gpe0_blk;               /* Port addr of General Purpose acpi_event 0 Reg Blk */
+    uint32_t gpe1_blk;               /* Port addr of General Purpose acpi_event 1 Reg Blk */
+    uint8_t  pm1_evt_len;            /* Byte length of ports at pm1_x_evt_blk */
+    uint8_t  pm1_cnt_len;            /* Byte length of ports at pm1_x_cnt_blk */
+    uint8_t  pm2_cnt_len;            /* Byte Length of ports at pm2_cnt_blk */
+    uint8_t  pm_tmr_len;             /* Byte Length of ports at pm_tm_blk */
+    uint8_t  gpe0_blk_len;           /* Byte Length of ports at gpe0_blk */
+    uint8_t  gpe1_blk_len;           /* Byte Length of ports at gpe1_blk */
+    uint8_t  gpe1_base;              /* Offset in gpe model where gpe1 events start */
+    uint8_t  reserved3;              /* Reserved */
+    uint16_t plvl2_lat;              /* Worst case HW latency to enter/exit C2 state */
+    uint16_t plvl3_lat;              /* Worst case HW latency to enter/exit C3 state */
+    uint16_t flush_size;             /* Size of area read to flush caches */
+    uint16_t flush_stride;           /* Stride used in flushing caches */
+    uint8_t  duty_offset;            /* Bit location of duty cycle field in p_cnt reg */
+    uint8_t  duty_width;             /* Bit width of duty cycle field in p_cnt reg */
+    uint8_t  day_alrm;               /* Index to day-of-month alarm in RTC CMOS RAM */
+    uint8_t  mon_alrm;               /* Index to month-of-year alarm in RTC CMOS RAM */
+    uint8_t  century;                /* Index to century in RTC CMOS RAM */
+    uint8_t  reserved4;              /* Reserved */
+    uint8_t  reserved4a;             /* Reserved */
+    uint8_t  reserved4b;             /* Reserved */
+    uint32_t flags;
+} QEMU_PACKED;
+typedef struct AcpiFadtDescriptorRev1 AcpiFadtDescriptorRev1;
+
+/*
+ * ACPI 1.0 Root System Description Table (RSDT)
+ */
+struct AcpiRsdtDescriptorRev1
+{
+    ACPI_TABLE_HEADER_DEF       /* ACPI common table header */
+    uint32_t table_offset_entry[0];  /* Array of pointers to other */
+    /* ACPI tables */
+} QEMU_PACKED;
+typedef struct AcpiRsdtDescriptorRev1 AcpiRsdtDescriptorRev1;
+
+/*
+ * ACPI 1.0 Firmware ACPI Control Structure (FACS)
+ */
+struct AcpiFacsDescriptorRev1
+{
+    uint32_t signature;           /* ACPI Signature */
+    uint32_t length;                 /* Length of structure, in bytes */
+    uint32_t hardware_signature;     /* Hardware configuration signature */
+    uint32_t firmware_waking_vector; /* ACPI OS waking vector */
+    uint32_t global_lock;            /* Global Lock */
+    uint32_t flags;
+    uint8_t  resverved3 [40];        /* Reserved - must be zero */
+} QEMU_PACKED;
+typedef struct AcpiFacsDescriptorRev1 AcpiFacsDescriptorRev1;
+
+/*
+ * Differentiated System Description Table (DSDT)
+ */
+
+/*
+ * MADT values and structures
+ */
+
+/* Values for MADT PCATCompat */
+
+#define ACPI_DUAL_PIC                0
+#define ACPI_MULTIPLE_APIC           1
+
+/* Master MADT */
+
+struct AcpiMultipleApicTable
+{
+    ACPI_TABLE_HEADER_DEF     /* ACPI common table header */
+    uint32_t local_apic_address;     /* Physical address of local APIC */
+    uint32_t flags;
+} QEMU_PACKED;
+typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
+
+/* Values for Type in APIC sub-headers */
+
+#define ACPI_APIC_PROCESSOR          0
+#define ACPI_APIC_IO                 1
+#define ACPI_APIC_XRUPT_OVERRIDE     2
+#define ACPI_APIC_NMI                3
+#define ACPI_APIC_LOCAL_NMI          4
+#define ACPI_APIC_ADDRESS_OVERRIDE   5
+#define ACPI_APIC_IO_SAPIC           6
+#define ACPI_APIC_LOCAL_SAPIC        7
+#define ACPI_APIC_XRUPT_SOURCE       8
+#define ACPI_APIC_RESERVED           9           /* 9 and greater are reserved */
+
+/*
+ * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE)
+ */
+#define ACPI_SUB_HEADER_DEF   /* Common ACPI sub-structure header */\
+    uint8_t  type;                               \
+    uint8_t  length;
+
+/* Sub-structures for MADT */
+
+struct AcpiMadtProcessorApic
+{
+    ACPI_SUB_HEADER_DEF
+    uint8_t  processor_id;           /* ACPI processor id */
+    uint8_t  local_apic_id;          /* Processor's local APIC id */
+    uint32_t flags;
+} QEMU_PACKED;
+typedef struct AcpiMadtProcessorApic AcpiMadtProcessorApic;
+
+struct AcpiMadtIoApic
+{
+    ACPI_SUB_HEADER_DEF
+    uint8_t  io_apic_id;             /* I/O APIC ID */
+    uint8_t  reserved;               /* Reserved - must be zero */
+    uint32_t address;                /* APIC physical address */
+    uint32_t interrupt;              /* Global system interrupt where INTI
+                                 * lines start */
+} QEMU_PACKED;
+typedef struct AcpiMadtIoApic AcpiMadtIoApic;
+
+struct AcpiMadtIntsrcovr {
+    ACPI_SUB_HEADER_DEF
+    uint8_t  bus;
+    uint8_t  source;
+    uint32_t gsi;
+    uint16_t flags;
+} QEMU_PACKED;
+typedef struct AcpiMadtIntsrcovr AcpiMadtIntsrcovr;
+
+struct AcpiMadtLocalNmi {
+    ACPI_SUB_HEADER_DEF
+    uint8_t  processor_id;           /* ACPI processor id */
+    uint16_t flags;                  /* MPS INTI flags */
+    uint8_t  lint;                   /* Local APIC LINT# */
+} QEMU_PACKED;
+typedef struct AcpiMadtLocalNmi AcpiMadtLocalNmi;
+
+/*
+ * HPET Description Table
+ */
+struct Acpi20Hpet {
+    ACPI_TABLE_HEADER_DEF                    /* ACPI common table header */
+    uint32_t           timer_block_id;
+    Acpi20GenericAddress addr;
+    uint8_t            hpet_number;
+    uint16_t           min_tick;
+    uint8_t            page_protect;
+} QEMU_PACKED;
+typedef struct Acpi20Hpet Acpi20Hpet;
+
+/*
+ * SRAT (NUMA topology description) table
+ */
+
+struct AcpiSystemResourceAffinityTable
+{
+    ACPI_TABLE_HEADER_DEF
+    uint32_t    reserved1;
+    uint32_t    reserved2[2];
+} QEMU_PACKED;
+typedef struct AcpiSystemResourceAffinityTable AcpiSystemResourceAffinityTable;
+
+#define ACPI_SRAT_PROCESSOR          0
+#define ACPI_SRAT_MEMORY             1
+
+struct AcpiSratProcessorAffinity
+{
+    ACPI_SUB_HEADER_DEF
+    uint8_t     proximity_lo;
+    uint8_t     local_apic_id;
+    uint32_t    flags;
+    uint8_t     local_sapic_eid;
+    uint8_t     proximity_hi[3];
+    uint32_t    reserved;
+} QEMU_PACKED;
+typedef struct AcpiSratProcessorAffinity AcpiSratProcessorAffinity;
+
+struct AcpiSratMemoryAffinity
+{
+    ACPI_SUB_HEADER_DEF
+    uint8_t     proximity[4];
+    uint16_t    reserved1;
+    uint64_t    base_addr;
+    uint64_t    range_length;
+    uint32_t    reserved2;
+    uint32_t    flags;
+    uint32_t    reserved3[2];
+} QEMU_PACKED;
+typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
+
+/* PCI fw r3.0 MCFG table. */
+/* Subtable */
+struct AcpiMcfgAllocation {
+    uint64_t address;                /* Base address, processor-relative */
+    uint16_t pci_segment;            /* PCI segment group number */
+    uint8_t start_bus_number;       /* Starting PCI Bus number */
+    uint8_t end_bus_number;         /* Final PCI Bus number */
+    uint32_t reserved;
+} QEMU_PACKED;
+typedef struct AcpiMcfgAllocation AcpiMcfgAllocation;
+
+struct AcpiTableMcfg {
+    ACPI_TABLE_HEADER_DEF;
+    uint8_t reserved[8];
+    AcpiMcfgAllocation allocation[0];
+} QEMU_PACKED;
+typedef struct AcpiTableMcfg AcpiTableMcfg;
+
+/*
+ * TCPA Description Table
+ */
+struct Acpi20Tcpa {
+    ACPI_TABLE_HEADER_DEF                    /* ACPI common table header */
+    uint16_t platform_class;
+    uint32_t log_area_minimum_length;
+    uint64_t log_area_start_address;
+} QEMU_PACKED;
+typedef struct Acpi20Tcpa Acpi20Tcpa;
+
+/* DMAR - DMA Remapping table r2.2 */
+struct AcpiTableDmar {
+    ACPI_TABLE_HEADER_DEF
+    uint8_t host_address_width; /* Maximum DMA physical addressability */
+    uint8_t flags;
+    uint8_t reserved[10];
+} QEMU_PACKED;
+typedef struct AcpiTableDmar AcpiTableDmar;
+
+/* Masks for Flags field above */
+#define ACPI_DMAR_INTR_REMAP        1
+#define ACPI_DMAR_X2APIC_OPT_OUT    (1 << 1)
+
+/* Values for sub-structure type for DMAR */
+enum {
+    ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,       /* DRHD */
+    ACPI_DMAR_TYPE_RESERVED_MEMORY = 1,     /* RMRR */
+    ACPI_DMAR_TYPE_ATSR = 2,                /* ATSR */
+    ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,   /* RHSR */
+    ACPI_DMAR_TYPE_ANDD = 4,                /* ANDD */
+    ACPI_DMAR_TYPE_RESERVED = 5             /* Reserved for furture use */
+};
+
+/*
+ * Sub-structures for DMAR
+ */
+/* Type 0: Hardware Unit Definition */
+struct AcpiDmarHardwareUnit {
+    uint16_t type;
+    uint16_t length;
+    uint8_t flags;
+    uint8_t reserved;
+    uint16_t pci_segment;   /* The PCI Segment associated with this unit */
+    uint64_t address;   /* Base address of remapping hardware register-set */
+} QEMU_PACKED;
+typedef struct AcpiDmarHardwareUnit AcpiDmarHardwareUnit;
+
+/* Masks for Flags field above */
+#define ACPI_DMAR_INCLUDE_PCI_ALL   1
+
+#endif
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 9e4d205..e7985a4 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -17,7 +17,7 @@
 #include "qemu-common.h"
 #include "libqtest.h"
 #include "qemu/compiler.h"
-#include "hw/i386/acpi-defs.h"
+#include "hw/acpi/acpi-defs.h"
 #include "hw/i386/smbios.h"
 #include "qemu/bitmap.h"
 
-- 
1.9.1

[Qemu-devel] [RFC PATCH 2/7] hw/arm/virt-acpi: Basic skeleton for dynamic generation of ACPI tables

[Alexander Spyridakis]

Introduce a preliminary skeleton in virt-acpi.c with the main
ACPI build functions. The virt machine model is meant to call
'acpi_build_tables' after platform devices are created and pass
all needed information. From that point each table will be
created in a separate memory buffer and finally be copied
to the guest memory as a single binary blob.

The minimum required ACPI v5.1 tables for ARM are:
- RSDP: Initial table that points to XSDT
- XSDT: Points to all other tables (except FACS & DSDT)
- FADT: Generic information about the machine
- DSDT: Holds all information about system devices/peripherals
- FACS: Needs to be pointed from FADT

Signed-off-by: Alexander Spyridakis <a.spyridakis@virtualopensystems.com>
Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com>
---
 hw/arm/Makefile.objs       |  2 +-
 hw/arm/virt-acpi.c         | 84 ++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/arm/virt-acpi.h | 52 ++++++++++++++++++++++++++++
 3 files changed, 137 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/virt-acpi.c
 create mode 100644 include/hw/arm/virt-acpi.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 6088e53..7cffb25 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -2,7 +2,7 @@ obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
 obj-$(CONFIG_DIGIC) += digic_boards.o
 obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
 obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
-obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o
+obj-y += tosa.o versatilepb.o vexpress.o virt.o virt-acpi.o xilinx_zynq.o z2.o
 
 obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
 obj-$(CONFIG_DIGIC) += digic.o
diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c
new file mode 100644
index 0000000..5c8df45
--- /dev/null
+++ b/hw/arm/virt-acpi.c
@@ -0,0 +1,84 @@
+/*
+ * ARM virt ACPI generation
+ *
+ * Copyright (c) 2014 Virtual Open Systems
+ *
+ * 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 or later, 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/>.
+ */
+
+#include "hw/arm/virt-acpi.h"
+
+static void *acpi_table[NUM_ACPI_TABLES];
+static int acpi_size[NUM_ACPI_TABLES];
+
+static void acpi_create_rsdp(void)
+{
+    acpi_table[RSDP] = NULL;
+    acpi_size[RSDP] = 0;
+}
+
+static void acpi_create_xsdt(void)
+{
+    acpi_table[XSDT] = NULL;
+    acpi_size[XSDT] = 0;
+}
+
+static void acpi_create_madt(uint32_t smp_cpus,
+             const struct acpi_madt_info *info)
+{
+    acpi_table[MADT] = NULL;
+    acpi_size[MADT] = 0;
+}
+
+static void acpi_create_gtdt(const struct acpi_gtdt_info *irqs)
+{
+    acpi_table[GTDT] = NULL;
+    acpi_size[GTDT] = 0;
+}
+
+static void acpi_create_fadt(void)
+{
+    acpi_table[FADT] = NULL;
+    acpi_size[FADT] = 0;
+}
+
+static void acpi_create_facs(void)
+{
+    acpi_table[FACS] = NULL;
+    acpi_size[FACS] = 0;
+}
+
+static void acpi_create_dsdt(int smp_cpus, const struct acpi_dsdt_info *info)
+{
+    acpi_table[DSDT] = NULL;
+    acpi_size[DSDT] = 0;
+}
+
+void acpi_build_tables(int smp_cpus,
+            const struct acpi_gtdt_info *gtdt_info,
+            const struct acpi_madt_info *madt_info,
+            const struct acpi_dsdt_info *dsdt_info)
+{
+    acpi_create_madt(smp_cpus, madt_info);
+    acpi_create_gtdt(gtdt_info);
+    acpi_create_rsdp();
+    acpi_create_facs();
+    acpi_create_xsdt();
+    acpi_create_fadt();
+    acpi_create_dsdt(smp_cpus, dsdt_info);
+}
+
+uint32_t acpi_make_blob(void **blob_ptr)
+{
+    return 0;
+}
diff --git a/include/hw/arm/virt-acpi.h b/include/hw/arm/virt-acpi.h
new file mode 100644
index 0000000..5098118
--- /dev/null
+++ b/include/hw/arm/virt-acpi.h
@@ -0,0 +1,52 @@
+/*
+ *
+ * Copyright (c) 2014 Virtual Open Systems
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that 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/>.
+ */
+#ifndef QEMU_VIRT_ACPI_BUILD_H
+#define QEMU_VIRT_ACPI_BUILD_H
+
+#include "qemu-common.h"
+#include "hw/acpi/acpi-defs.h"
+
+#define NUM_ACPI_TABLES 7
+
+enum {
+    RSDP,
+    XSDT,
+    MADT,
+    GTDT,
+    /* New tables should be added before FADT */
+    FADT,
+    FACS,
+    DSDT,
+};
+
+struct acpi_gtdt_info {
+};
+
+struct acpi_madt_info {
+};
+
+struct acpi_dsdt_info {
+};
+
+void acpi_build_tables(int smp_cpus,
+            const struct acpi_gtdt_info *gtdt_info,
+            const struct acpi_madt_info *madt_info,
+            const struct acpi_dsdt_info *dsdt_info);
+uint32_t acpi_make_blob(void **blob_ptr);
+
+#endif
-- 
1.9.1

Re: [Qemu-devel] [RFC PATCH 2/7] hw/arm/virt-acpi: Basic skeleton for dynamic generation of ACPI tables

[Peter Maydell]

On 30 October 2014 17:44, Alexander Spyridakis
<a.spyridakis@virtualopensystems.com> wrote:
> Introduce a preliminary skeleton in virt-acpi.c with the main
> ACPI build functions. The virt machine model is meant to call
> 'acpi_build_tables' after platform devices are created and pass
> all needed information. From that point each table will be
> created in a separate memory buffer and finally be copied
> to the guest memory as a single binary blob.

Please, no. ACPI should be the guest's problem, not QEMU's.
We provide the guest with a device tree it can look at to
figure out what h/w is present.

-- PMM

Re: [Qemu-devel] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 30 October 2014 17:43, Alexander Spyridakis
<a.spyridakis@virtualopensystems.com> wrote:
> Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
> implemented in this patch series, which is the minimum for a basic ARM support.
>
> The set of generated tables are:
> - RSDP
> - XSDT
> - MADT
> - GTDT
> - FADT
> - FACS
> - DSDT
>
> The tables are created in standalone buffers, taking into account the
> needed information passed from the virt machine model. When the generation
> is finalized, the individual buffers are compacted to a single ACPI binary
> blob, where it is injected on the guest memory space in a fixed location.
> The guest kernel can find the ACPI tables by providing to it the physical
> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).

(Sorry, I should have waited for the cover letter to arrive before replying.)

I think this is definitely the wrong approach. We already have to
generate device tree information for the hardware we have, and having
an equivalent parallel infrastructure for generating ACPI as well
seems like it would be a tremendous mess. We should support guests
that require ACPI by having QEMU boot a UEFI bios blob and have that
UEFI code generate ACPI tables based on the DTB we hand it.
(Chances seem good that any guest that wants ACPI is going to want
UEFI runtime services anyway.)

thanks
-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
> On 30 October 2014 17:43, Alexander Spyridakis
> <a.spyridakis@virtualopensystems.com> wrote:
> > Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
> > implemented in this patch series, which is the minimum for a basic ARM support.
> >
> > The set of generated tables are:
> > - RSDP
> > - XSDT
> > - MADT
> > - GTDT
> > - FADT
> > - FACS
> > - DSDT
> >
> > The tables are created in standalone buffers, taking into account the
> > needed information passed from the virt machine model. When the generation
> > is finalized, the individual buffers are compacted to a single ACPI binary
> > blob, where it is injected on the guest memory space in a fixed location.
> > The guest kernel can find the ACPI tables by providing to it the physical
> > address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
> 
> (Sorry, I should have waited for the cover letter to arrive before replying.)
> 
> I think this is definitely the wrong approach. We already have to
> generate device tree information for the hardware we have, and having
> an equivalent parallel infrastructure for generating ACPI as well
> seems like it would be a tremendous mess. We should support guests
> that require ACPI by having QEMU boot a UEFI bios blob and have that
> UEFI code generate ACPI tables based on the DTB we hand it.
> (Chances seem good that any guest that wants ACPI is going to want
> UEFI runtime services anyway.)

Depending on why people want ACPI in a guest environment, generating
ACPI tables from a DTB might not be possible (e.g. if they want to use
AML for some reason).

So the important question is _why_ the guest needs to see an ACPI
environment. What exactly can ACPI provide to the guest that DT does not
already provide, and why is that necessary? What infrastrucutre is
needed for that use case?

Translating DT tables into the equivalent ACPI tables seems like a waste
of effort unless it enables something we can't do at the moment.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Claudio Fontana]

Hi all,

On 30.10.2014 19:02, Mark Rutland wrote:
> On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
>> On 30 October 2014 17:43, Alexander Spyridakis
>> <a.spyridakis@virtualopensystems.com> wrote:
>>> Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
>>> implemented in this patch series, which is the minimum for a basic ARM support.
>>>
>>> The set of generated tables are:
>>> - RSDP
>>> - XSDT
>>> - MADT
>>> - GTDT
>>> - FADT
>>> - FACS
>>> - DSDT
>>>
>>> The tables are created in standalone buffers, taking into account the
>>> needed information passed from the virt machine model. When the generation
>>> is finalized, the individual buffers are compacted to a single ACPI binary
>>> blob, where it is injected on the guest memory space in a fixed location.
>>> The guest kernel can find the ACPI tables by providing to it the physical
>>> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
>>
>> (Sorry, I should have waited for the cover letter to arrive before replying.)
>>
>> I think this is definitely the wrong approach. We already have to
>> generate device tree information for the hardware we have, and having
>> an equivalent parallel infrastructure for generating ACPI as well
>> seems like it would be a tremendous mess. We should support guests
>> that require ACPI by having QEMU boot a UEFI bios blob and have that
>> UEFI code generate ACPI tables based on the DTB we hand it.
>> (Chances seem good that any guest that wants ACPI is going to want
>> UEFI runtime services anyway.)
> 
> Depending on why people want ACPI in a guest environment, generating
> ACPI tables from a DTB might not be possible (e.g. if they want to use
> AML for some reason).
> 
> So the important question is _why_ the guest needs to see an ACPI
> environment. What exactly can ACPI provide to the guest that DT does not
> already provide, and why is that necessary? What infrastrucutre is
> needed for that use case?
> 
> Translating DT tables into the equivalent ACPI tables seems like a waste
> of effort unless it enables something we can't do at the moment.
> 
> Thanks,
> Mark.
> 

Please correct me if I am wrong, my understanding at the moment is that
for X86 there is an ACPI implementation in hw/acpi, with the table generation
happening in hw/i386/acpi-build.c .
Couldn't there be some unification where part of the infrastructure for
ACPI is reused, with arch-specific code specializing for X86 and ARM?
Why are ACPI tables created for X86, but cannot be created likewise for ARM?

We need ACPI guest support in QEMU for AArch64 over here, with all features
(including the ability to run ACPI code and add specific tables), for
ACPI-based guests.

Thanks,

Claudio

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 5 November 2014 09:58, Claudio Fontana <claudio.fontana@huawei.com> wrote:
> Please correct me if I am wrong, my understanding at the moment is that
> for X86 there is an ACPI implementation in hw/acpi, with the table generation
> happening in hw/i386/acpi-build.c .
> Couldn't there be some unification where part of the infrastructure for
> ACPI is reused, with arch-specific code specializing for X86 and ARM?
> Why are ACPI tables created for X86, but cannot be created likewise for ARM?

Because then for ARM boards we'd be creating a description of the
hardware twice, once in device tree and once in ACPI, which seems
like unnecessary duplication.

> We need ACPI guest support in QEMU for AArch64 over here, with all features
> (including the ability to run ACPI code and add specific tables), for
> ACPI-based guests.

The plan for providing ACPI to guests is that we run a UEFI BIOS
blob which is what is responsible for providing ACPI and UEFI
runtime services to guests which need them. (The UEFI blob finds
out about its hardware by looking at a device tree that QEMU
passes it, but that's a detail between QEMU and its bios blob).
This pretty much looks like what x86 QEMU used to do with ACPI
for a very long time, so we know it's a feasible approach.

thanks
-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Igor Mammedov]

On Thu, 6 Nov 2014 12:44:04 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 5 November 2014 09:58, Claudio Fontana <claudio.fontana@huawei.com> wrote:
> > Please correct me if I am wrong, my understanding at the moment is that
> > for X86 there is an ACPI implementation in hw/acpi, with the table generation
> > happening in hw/i386/acpi-build.c .
> > Couldn't there be some unification where part of the infrastructure for
> > ACPI is reused, with arch-specific code specializing for X86 and ARM?
> > Why are ACPI tables created for X86, but cannot be created likewise for ARM?
> 
> Because then for ARM boards we'd be creating a description of the
> hardware twice, once in device tree and once in ACPI, which seems
> like unnecessary duplication.
> 
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
> 
> The plan for providing ACPI to guests is that we run a UEFI BIOS
> blob which is what is responsible for providing ACPI and UEFI
> runtime services to guests which need them. (The UEFI blob finds
> out about its hardware by looking at a device tree that QEMU
> passes it, but that's a detail between QEMU and its bios blob).
> This pretty much looks like what x86 QEMU used to do with ACPI
> for a very long time, so we know it's a feasible approach.
ACPI in BIOS had also led to necessity to
 1. update BIOS and QEMU in lockstep if fix/feature is must to have
 2. adding compatibility hooks so it it would work with mismatched
versions.
 3. never ending expansion of PV QEMU-BIOS interface

That's the reasons why ACPI tables are build by QEMU now, and we
probably should learn on x86 experience instead of going through
the same issues second time.

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Alexander Spyridakis]

On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
>
> The plan for providing ACPI to guests is that we run a UEFI BIOS
> blob which is what is responsible for providing ACPI and UEFI
> runtime services to guests which need them. (The UEFI blob finds
> out about its hardware by looking at a device tree that QEMU
> passes it, but that's a detail between QEMU and its bios blob).
> This pretty much looks like what x86 QEMU used to do with ACPI
> for a very long time, so we know it's a feasible approach.

Hi Peter,

The rational in the proposed approach is meant for cases where the
user does not want to rely on external firmware layers. While UEFI
could do what you are describing, the point is to avoid this not so
trivial overhead in the booting process. Especially in the case of
thin guests, where another software dependency is undesired.

Regards.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 6 November 2014 13:33, Alexander Spyridakis
<a.spyridakis@virtualopensystems.com> wrote:
> The rational in the proposed approach is meant for cases where the
> user does not want to rely on external firmware layers. While UEFI
> could do what you are describing, the point is to avoid this not so
> trivial overhead in the booting process. Especially in the case of
> thin guests, where another software dependency is undesired.

Can you boot an x86 QEMU/KVM ACPI-using guest without running
the BIOS?

-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

Hi,

On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> >
> > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > (including the ability to run ACPI code and add specific tables), for
> > > ACPI-based guests.
> >
> > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > blob which is what is responsible for providing ACPI and UEFI
> > runtime services to guests which need them. (The UEFI blob finds
> > out about its hardware by looking at a device tree that QEMU
> > passes it, but that's a detail between QEMU and its bios blob).
> > This pretty much looks like what x86 QEMU used to do with ACPI
> > for a very long time, so we know it's a feasible approach.
> 
> Hi Peter,
> 
> The rational in the proposed approach is meant for cases where the
> user does not want to rely on external firmware layers. While UEFI
> could do what you are describing, the point is to avoid this not so
> trivial overhead in the booting process. Especially in the case of
> thin guests, where another software dependency is undesired.

I'm not sure how you plan to use ACPI without UEFI, as there are several
pieces of information which ACPI misses, such as the memory map, which
must be discovered from UEFI. How do you intend to discover the memory
map without UEFI?

Additionally, with Linux and other generic OSs, the expectation is that
the ACPI tables are discovered via the UEFI system table. How do you
intend to discover the ACPI tables? Or other system information?

>From experience with Linux, querying this information from UEFI is a
trivial overhead, though a UEFI implementation might take a while to
boot to the point where that is possible. It would be more generally
helpful to have an optimized virtualised UEFI for this case (or perhaps
just a UEFI frontend that presents the same interface to EFI
applications but doesn't have to do any heavy lifting at boot).

So far the general trend with AArch64 at the system level is to use
generic interfaces as far as possible. The generic interface for
discovering ACPI tables is to boot as an EFI application and then to
query the tables from UEFI. That is the interface others are likely to
follow, and ACPI without UEFI is unlikely to be of much use to anyone
else.

Why is it worth expending the effort on the boot protocol you suggest
(which so far is not well defined) when there is already a portable,
well-defined standard that others are already following?

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> Hi,
> 
> On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > >
> > >
> > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > (including the ability to run ACPI code and add specific tables), for
> > > > ACPI-based guests.
> > >
> > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > blob which is what is responsible for providing ACPI and UEFI
> > > runtime services to guests which need them. (The UEFI blob finds
> > > out about its hardware by looking at a device tree that QEMU
> > > passes it, but that's a detail between QEMU and its bios blob).
> > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > for a very long time, so we know it's a feasible approach.
> > 
> > Hi Peter,
> > 
> > The rational in the proposed approach is meant for cases where the
> > user does not want to rely on external firmware layers. While UEFI
> > could do what you are describing, the point is to avoid this not so
> > trivial overhead in the booting process. Especially in the case of
> > thin guests, where another software dependency is undesired.
> 
> I'm not sure how you plan to use ACPI without UEFI, as there are several
> pieces of information which ACPI misses, such as the memory map, which
> must be discovered from UEFI. How do you intend to discover the memory
> map without UEFI?
> 
> Additionally, with Linux and other generic OSs, the expectation is that
> the ACPI tables are discovered via the UEFI system table. How do you
> intend to discover the ACPI tables? Or other system information?

FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
the command line and memory information to Dom0 as well.  We are
currently suggesting adding an RDSP property to the chosen node in the
tiny DT, but a command-line arguement like kexec proposed could be
another option I guess, albeit not a very pretty one.

But, what I hear from Huawei is that they don't want any DT and don't
want any UEFI, so not sure how they plan on accomplishing that.

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

Hi Christoffer,

On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote:
> On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> > Hi,
> > 
> > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > >
> > > >
> > > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > > (including the ability to run ACPI code and add specific tables), for
> > > > > ACPI-based guests.
> > > >
> > > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > > blob which is what is responsible for providing ACPI and UEFI
> > > > runtime services to guests which need them. (The UEFI blob finds
> > > > out about its hardware by looking at a device tree that QEMU
> > > > passes it, but that's a detail between QEMU and its bios blob).
> > > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > > for a very long time, so we know it's a feasible approach.
> > > 
> > > Hi Peter,
> > > 
> > > The rational in the proposed approach is meant for cases where the
> > > user does not want to rely on external firmware layers. While UEFI
> > > could do what you are describing, the point is to avoid this not so
> > > trivial overhead in the booting process. Especially in the case of
> > > thin guests, where another software dependency is undesired.
> > 
> > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > pieces of information which ACPI misses, such as the memory map, which
> > must be discovered from UEFI. How do you intend to discover the memory
> > map without UEFI?
> > 
> > Additionally, with Linux and other generic OSs, the expectation is that
> > the ACPI tables are discovered via the UEFI system table. How do you
> > intend to discover the ACPI tables? Or other system information?
> 
> FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
> the command line and memory information to Dom0 as well.

When you say "memory information", is that pointers to a UEFI memory
map, or memory nodes? The former should work for ACPI, but I don't think
the latter will. I think there's a need for some discussion regarding
the Dom0 boot flow for ACPI. Is there any tree I can take a peek at?

Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and
other potentially useful things, in addition to simply being yet another
potential boot configuration. I'm a little concerned about that.

> We are currently suggesting adding an RDSP property to the chosen node
> in the tiny DT, but a command-line arguement like kexec proposed could
> be another option I guess, albeit not a very pretty one.

I'm not sure what an RDSP command line property would have to do with
kexec. I'll assume I've misunderstood something.

> But, what I hear from Huawei is that they don't want any DT and don't
> want any UEFI, so not sure how they plan on accomplishing that.

Indeed.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Tue, Nov 11, 2014 at 04:48:07PM +0000, Mark Rutland wrote:
> Hi Christoffer,
> 
> On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote:
> > On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > > > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > >
> > > > >
> > > > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > > > (including the ability to run ACPI code and add specific tables), for
> > > > > > ACPI-based guests.
> > > > >
> > > > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > > > blob which is what is responsible for providing ACPI and UEFI
> > > > > runtime services to guests which need them. (The UEFI blob finds
> > > > > out about its hardware by looking at a device tree that QEMU
> > > > > passes it, but that's a detail between QEMU and its bios blob).
> > > > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > > > for a very long time, so we know it's a feasible approach.
> > > > 
> > > > Hi Peter,
> > > > 
> > > > The rational in the proposed approach is meant for cases where the
> > > > user does not want to rely on external firmware layers. While UEFI
> > > > could do what you are describing, the point is to avoid this not so
> > > > trivial overhead in the booting process. Especially in the case of
> > > > thin guests, where another software dependency is undesired.
> > > 
> > > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > > pieces of information which ACPI misses, such as the memory map, which
> > > must be discovered from UEFI. How do you intend to discover the memory
> > > map without UEFI?
> > > 
> > > Additionally, with Linux and other generic OSs, the expectation is that
> > > the ACPI tables are discovered via the UEFI system table. How do you
> > > intend to discover the ACPI tables? Or other system information?
> > 
> > FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
> > the command line and memory information to Dom0 as well.
> 
> When you say "memory information", is that pointers to a UEFI memory
> map, or memory nodes? The former should work for ACPI, but I don't think
> the latter will. I think there's a need for some discussion regarding
> the Dom0 boot flow for ACPI. Is there any tree I can take a peek at?

Plain memory nodes.  There is no UEFI instance for Dom0.  AFAIU x86 does
something similar (although with some custom PV thing instead of DT),
and when Dom0 needs UEFI runtime services, this is done through specific
hypercalls.

The Xen code is incomplete for this work, but can be followed here:
https://git.linaro.org/people/parth.dixit/acpi-rsdp/xen.git/shortlog/refs/heads/explore-rsdp

The Linux side is stuff based on the LEG kernel I think, not sure if
it's pushed anywhere yet.

I'm cc'ing Parth and Julien here, but I agree that having a discussion
on this could probably be good.

> 
> Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and
> other potentially useful things, in addition to simply being yet another
> potential boot configuration. I'm a little concerned about that.
> 

I share your concern, but running another UEFI instance for Dom0 doesn't
seem like a viable alternative either.  Why is this a problem on ARM and
not on x86 though?

> > We are currently suggesting adding an RDSP property to the chosen node
> > in the tiny DT, but a command-line arguement like kexec proposed could
> > be another option I guess, albeit not a very pretty one.
> 
> I'm not sure what an RDSP command line property would have to do with
> kexec. I'll assume I've misunderstood something.
> 

I thought the kexec patches proposed passing the RDSP on the
command-line to boot the secondary kernel, so if that ended up being
supported by the kernel for kexec, maybe that could be leveraged by
Xen's boot protocol.  It was an idea someone brought to me, just thought
I'd mention it.

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Tue, Nov 11, 2014 at 09:33:12PM +0000, Christoffer Dall wrote:
> On Tue, Nov 11, 2014 at 04:48:07PM +0000, Mark Rutland wrote:
> > Hi Christoffer,
> > 
> > On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote:
> > > On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > > > > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > >
> > > > > >
> > > > > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > > > > (including the ability to run ACPI code and add specific tables), for
> > > > > > > ACPI-based guests.
> > > > > >
> > > > > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > > > > blob which is what is responsible for providing ACPI and UEFI
> > > > > > runtime services to guests which need them. (The UEFI blob finds
> > > > > > out about its hardware by looking at a device tree that QEMU
> > > > > > passes it, but that's a detail between QEMU and its bios blob).
> > > > > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > > > > for a very long time, so we know it's a feasible approach.
> > > > > 
> > > > > Hi Peter,
> > > > > 
> > > > > The rational in the proposed approach is meant for cases where the
> > > > > user does not want to rely on external firmware layers. While UEFI
> > > > > could do what you are describing, the point is to avoid this not so
> > > > > trivial overhead in the booting process. Especially in the case of
> > > > > thin guests, where another software dependency is undesired.
> > > > 
> > > > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > > > pieces of information which ACPI misses, such as the memory map, which
> > > > must be discovered from UEFI. How do you intend to discover the memory
> > > > map without UEFI?
> > > > 
> > > > Additionally, with Linux and other generic OSs, the expectation is that
> > > > the ACPI tables are discovered via the UEFI system table. How do you
> > > > intend to discover the ACPI tables? Or other system information?
> > > 
> > > FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
> > > the command line and memory information to Dom0 as well.
> > 
> > When you say "memory information", is that pointers to a UEFI memory
> > map, or memory nodes? The former should work for ACPI, but I don't think
> > the latter will. I think there's a need for some discussion regarding
> > the Dom0 boot flow for ACPI. Is there any tree I can take a peek at?
> 
> Plain memory nodes.  There is no UEFI instance for Dom0.  AFAIU x86 does
> something similar (although with some custom PV thing instead of DT),
> and when Dom0 needs UEFI runtime services, this is done through specific
> hypercalls.
> 
> The Xen code is incomplete for this work, but can be followed here:
> https://git.linaro.org/people/parth.dixit/acpi-rsdp/xen.git/shortlog/refs/heads/explore-rsdp

Thanks.

> The Linux side is stuff based on the LEG kernel I think, not sure if
> it's pushed anywhere yet.
> 
> I'm cc'ing Parth and Julien here, but I agree that having a discussion
> on this could probably be good.

Sounds good to me. That might be worth running as a separate thread so
as not to confuse matters.

Perhaps just using memory nodes is fine, but so far all of the
discussions I've been in (on mailing lists and in person) regarding ACPI
have had the fundamental assumption that ACPI would require UEFI, and
the UEFI memory map is in use. Given that assumption seems to be broken
for this case, we need to revisit those discussions.

There's also a problem in that this opens the possibility of non-Xen
!UEFI + ACPI configurations, which I don't think is something we want to
encourage. Xen is somewhat a special case because of the symbiotic
relationship with Dom0.

> > Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and
> > other potentially useful things, in addition to simply being yet another
> > potential boot configuration. I'm a little concerned about that.
> > 
> 
> I share your concern, but running another UEFI instance for Dom0 doesn't
> seem like a viable alternative either.  Why is this a problem on ARM and
> not on x86 though?

I believe that on x86 the fallback for !UEFI would be the e820 memory
map, which provides info regarding the type of the memory mapping, as
opposed to just the base + size. That said, I'm not that familiar with
e820, and from a quick look the provided information doesn't seem to be
that detailed.

> > > We are currently suggesting adding an RDSP property to the chosen node
> > > in the tiny DT, but a command-line arguement like kexec proposed could
> > > be another option I guess, albeit not a very pretty one.
> > 
> > I'm not sure what an RDSP command line property would have to do with
> > kexec. I'll assume I've misunderstood something.
> > 
> 
> I thought the kexec patches proposed passing the RDSP on the
> command-line to boot the secondary kernel, so if that ended up being
> supported by the kernel for kexec, maybe that could be leveraged by
> Xen's boot protocol.  It was an idea someone brought to me, just thought
> I'd mention it.

Ah, that's not something I'd heard of.

I'm not a fan of placing fundamentally required system description on
the command line. It's fine for explicit overrides but I don't think it
should be the default mechanism as that causes its own set of problems
(who wants to fight with their hypervisor to pass a command line to a
guest kernel?).

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Wed, Nov 12, 2014 at 10:38:54AM +0000, Mark Rutland wrote:
> On Tue, Nov 11, 2014 at 09:33:12PM +0000, Christoffer Dall wrote:
> > On Tue, Nov 11, 2014 at 04:48:07PM +0000, Mark Rutland wrote:
> > > Hi Christoffer,
> > > 
> > > On Tue, Nov 11, 2014 at 04:31:01PM +0000, Christoffer Dall wrote:
> > > > On Tue, Nov 11, 2014 at 03:29:33PM +0000, Mark Rutland wrote:
> > > > > Hi,
> > > > > 
> > > > > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> > > > > > On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > > >
> > > > > > >
> > > > > > > > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > > > > > > > (including the ability to run ACPI code and add specific tables), for
> > > > > > > > ACPI-based guests.
> > > > > > >
> > > > > > > The plan for providing ACPI to guests is that we run a UEFI BIOS
> > > > > > > blob which is what is responsible for providing ACPI and UEFI
> > > > > > > runtime services to guests which need them. (The UEFI blob finds
> > > > > > > out about its hardware by looking at a device tree that QEMU
> > > > > > > passes it, but that's a detail between QEMU and its bios blob).
> > > > > > > This pretty much looks like what x86 QEMU used to do with ACPI
> > > > > > > for a very long time, so we know it's a feasible approach.
> > > > > > 
> > > > > > Hi Peter,
> > > > > > 
> > > > > > The rational in the proposed approach is meant for cases where the
> > > > > > user does not want to rely on external firmware layers. While UEFI
> > > > > > could do what you are describing, the point is to avoid this not so
> > > > > > trivial overhead in the booting process. Especially in the case of
> > > > > > thin guests, where another software dependency is undesired.
> > > > > 
> > > > > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > > > > pieces of information which ACPI misses, such as the memory map, which
> > > > > must be discovered from UEFI. How do you intend to discover the memory
> > > > > map without UEFI?
> > > > > 
> > > > > Additionally, with Linux and other generic OSs, the expectation is that
> > > > > the ACPI tables are discovered via the UEFI system table. How do you
> > > > > intend to discover the ACPI tables? Or other system information?
> > > > 
> > > > FWIW, Xen needs to pass the RDSP pointer along with a tiny DT containing
> > > > the command line and memory information to Dom0 as well.
> > > 
> > > When you say "memory information", is that pointers to a UEFI memory
> > > map, or memory nodes? The former should work for ACPI, but I don't think
> > > the latter will. I think there's a need for some discussion regarding
> > > the Dom0 boot flow for ACPI. Is there any tree I can take a peek at?
> > 
> > Plain memory nodes.  There is no UEFI instance for Dom0.  AFAIU x86 does
> > something similar (although with some custom PV thing instead of DT),
> > and when Dom0 needs UEFI runtime services, this is done through specific
> > hypercalls.
> > 
> > The Xen code is incomplete for this work, but can be followed here:
> > https://git.linaro.org/people/parth.dixit/acpi-rsdp/xen.git/shortlog/refs/heads/explore-rsdp
> 
> Thanks.
> 
> > The Linux side is stuff based on the LEG kernel I think, not sure if
> > it's pushed anywhere yet.
> > 
> > I'm cc'ing Parth and Julien here, but I agree that having a discussion
> > on this could probably be good.
> 
> Sounds good to me. That might be worth running as a separate thread so
> as not to confuse matters.

Agreed.

> 
> Perhaps just using memory nodes is fine, but so far all of the
> discussions I've been in (on mailing lists and in person) regarding ACPI
> have had the fundamental assumption that ACPI would require UEFI, and
> the UEFI memory map is in use. Given that assumption seems to be broken
> for this case, we need to revisit those discussions.
> 
> There's also a problem in that this opens the possibility of non-Xen
> !UEFI + ACPI configurations, which I don't think is something we want to
> encourage. Xen is somewhat a special case because of the symbiotic
> relationship with Dom0.
> 
> > > Passing just the RDSP will mean that Dom0 won't get SMBIOS tables and
> > > other potentially useful things, in addition to simply being yet another
> > > potential boot configuration. I'm a little concerned about that.
> > > 
> > 
> > I share your concern, but running another UEFI instance for Dom0 doesn't
> > seem like a viable alternative either.  Why is this a problem on ARM and
> > not on x86 though?
> 
> I believe that on x86 the fallback for !UEFI would be the e820 memory
> map, which provides info regarding the type of the memory mapping, as
> opposed to just the base + size. That said, I'm not that familiar with
> e820, and from a quick look the provided information doesn't seem to be
> that detailed.
> 

right, the good old PC.

> > > > We are currently suggesting adding an RDSP property to the chosen node
> > > > in the tiny DT, but a command-line arguement like kexec proposed could
> > > > be another option I guess, albeit not a very pretty one.
> > > 
> > > I'm not sure what an RDSP command line property would have to do with
> > > kexec. I'll assume I've misunderstood something.
> > > 
> > 
> > I thought the kexec patches proposed passing the RDSP on the
> > command-line to boot the secondary kernel, so if that ended up being
> > supported by the kernel for kexec, maybe that could be leveraged by
> > Xen's boot protocol.  It was an idea someone brought to me, just thought
> > I'd mention it.
> 
> Ah, that's not something I'd heard of.

Maybe there was a misunderstanding then, I thought you were cc'ed on
those discussions.

> 
> I'm not a fan of placing fundamentally required system description on
> the command line. It's fine for explicit overrides but I don't think it
> should be the default mechanism as that causes its own set of problems
> (who wants to fight with their hypervisor to pass a command line to a
> guest kernel?).
> 

Agreed completely, but I've been lacking strong technical arguments
against passing this stuff on the cmdline.  My personal preferred
approach for the Xen Dom0 case is to add a property to the DT.

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Julien Grall]

Hi,

On 12/11/2014 10:44, Christoffer Dall wrote:
>>
>> I'm not a fan of placing fundamentally required system description on
>> the command line. It's fine for explicit overrides but I don't think it
>> should be the default mechanism as that causes its own set of problems
>> (who wants to fight with their hypervisor to pass a command line to a
>> guest kernel?).
>>
>
> Agreed completely, but I've been lacking strong technical arguments
> against passing this stuff on the cmdline.  My personal preferred
> approach for the Xen Dom0 case is to add a property to the DT.

IHMO, the cmdline is OS specific, therefore this solution wouldn't fit 
to support ACPI on other OS (i.e *BSD) without requiring specific 
implementation/parsing of the command line.

The DT solution would be cleaner and the bindings are already 
standardize (and starting to be used on other OS such as FreeBSD).

Regards,

-- 
Julien Grall

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

[...]

> > > > > We are currently suggesting adding an RDSP property to the chosen node
> > > > > in the tiny DT, but a command-line arguement like kexec proposed could
> > > > > be another option I guess, albeit not a very pretty one.
> > > > 
> > > > I'm not sure what an RDSP command line property would have to do with
> > > > kexec. I'll assume I've misunderstood something.
> > > > 
> > > 
> > > I thought the kexec patches proposed passing the RDSP on the
> > > command-line to boot the secondary kernel, so if that ended up being
> > > supported by the kernel for kexec, maybe that could be leveraged by
> > > Xen's boot protocol.  It was an idea someone brought to me, just thought
> > > I'd mention it.
> > 
> > Ah, that's not something I'd heard of.
> 
> Maybe there was a misunderstanding then, I thought you were cc'ed on
> those discussions.

I may just have lost them in my inbox. I'm on a few too many mailing
lists these days. Sorry about that.

> > I'm not a fan of placing fundamentally required system description on
> > the command line. It's fine for explicit overrides but I don't think it
> > should be the default mechanism as that causes its own set of problems
> > (who wants to fight with their hypervisor to pass a command line to a
> > guest kernel?).
> > 
> 
> Agreed completely, but I've been lacking strong technical arguments
> against passing this stuff on the cmdline.  My personal preferred
> approach for the Xen Dom0 case is to add a property to the DT.

Something under /chosen, or a firmware node would sound preferable to
me. For UEFI we pass the system table address as
/chosen/linux,uefi-system-table = <... ...>, and I think the RDSP could
be handled similarly if necessary. The user can than override that via
the command line if desired.

Ideally, the user shouldn't have to place anything on the command line
to get a usable system. Obviously some things will be necesarry (where
is my rootfs?), but that should be the user's configuration of the
system rather than fundamental properties of said system.

The big issue I'm aware of at the moment that forces people to provide a
command line (on non-virtualised systems at least) is the default
console and the rate thereof, but that's being looked into currently.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Graeme Gregory]

On Wed, Nov 12, 2014 at 11:07:22AM +0000, Mark Rutland wrote:
> [...]
> 
> > > > > > We are currently suggesting adding an RDSP property to the chosen node
> > > > > > in the tiny DT, but a command-line arguement like kexec proposed could
> > > > > > be another option I guess, albeit not a very pretty one.
> > > > > 
> > > > > I'm not sure what an RDSP command line property would have to do with
> > > > > kexec. I'll assume I've misunderstood something.
> > > > > 
> > > > 
> > > > I thought the kexec patches proposed passing the RDSP on the
> > > > command-line to boot the secondary kernel, so if that ended up being
> > > > supported by the kernel for kexec, maybe that could be leveraged by
> > > > Xen's boot protocol.  It was an idea someone brought to me, just thought
> > > > I'd mention it.
> > > 
> > > Ah, that's not something I'd heard of.
> > 
> > Maybe there was a misunderstanding then, I thought you were cc'ed on
> > those discussions.
> 
> I may just have lost them in my inbox. I'm on a few too many mailing
> lists these days. Sorry about that.
> 
> > > I'm not a fan of placing fundamentally required system description on
> > > the command line. It's fine for explicit overrides but I don't think it
> > > should be the default mechanism as that causes its own set of problems
> > > (who wants to fight with their hypervisor to pass a command line to a
> > > guest kernel?).
> > > 
> > 
> > Agreed completely, but I've been lacking strong technical arguments
> > against passing this stuff on the cmdline.  My personal preferred
> > approach for the Xen Dom0 case is to add a property to the DT.
> 
> Something under /chosen, or a firmware node would sound preferable to
> me. For UEFI we pass the system table address as
> /chosen/linux,uefi-system-table = <... ...>, and I think the RDSP could
> be handled similarly if necessary. The user can than override that via
> the command line if desired.
> 
We have actually done that in the past when we had to support u-boot and
bootwrapper as a bootloader. It works fine in the kernel and its a
minimal patch to support.

Graeme

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 11:38, Mark Rutland wrote:
> > I share your concern, but running another UEFI instance for Dom0 doesn't
> > seem like a viable alternative either.  Why is this a problem on ARM and
> > not on x86 though?
> 
> I believe that on x86 the fallback for !UEFI would be the e820 memory
> map, which provides info regarding the type of the memory mapping, as
> opposed to just the base + size. That said, I'm not that familiar with
> e820, and from a quick look the provided information doesn't seem to be
> that detailed.

The e820 memory map is only part of it.  On x86 !UEFI you are supposed
to scan low memory for magic signatures that provides pointers to the
SMBIOS and ACPI tables.

As Christoffer said, "the good old PC". :)

SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
On ARM you could use DT binary blobs instead of fw_cfg, as proposed
already (I don't remember if it was in this thread or IRC).  Then if you
want to go !UEFI you can extract the tables from those binary blobs.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 11:52:22AM +0000, Paolo Bonzini wrote:
> 
> On 12/11/2014 11:38, Mark Rutland wrote:
> > > I share your concern, but running another UEFI instance for Dom0 doesn't
> > > seem like a viable alternative either.  Why is this a problem on ARM and
> > > not on x86 though?
> > 
> > I believe that on x86 the fallback for !UEFI would be the e820 memory
> > map, which provides info regarding the type of the memory mapping, as
> > opposed to just the base + size. That said, I'm not that familiar with
> > e820, and from a quick look the provided information doesn't seem to be
> > that detailed.
> 
> The e820 memory map is only part of it.  On x86 !UEFI you are supposed
> to scan low memory for magic signatures that provides pointers to the
> SMBIOS and ACPI tables.

Fun...

> As Christoffer said, "the good old PC". :)
> 
> SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
> On ARM you could use DT binary blobs instead of fw_cfg, as proposed
> already (I don't remember if it was in this thread or IRC).  Then if you
> want to go !UEFI you can extract the tables from those binary blobs.

This sounds broken. I am very much not a fan of shoving binary blobs
into DT to workaround a shoddy boot interface.

Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 13:04, Mark Rutland wrote:
>> > SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>> > On ARM you could use DT binary blobs instead of fw_cfg, as proposed
>> > already (I don't remember if it was in this thread or IRC).  Then if you
>> > want to go !UEFI you can extract the tables from those binary blobs.
> This sounds broken. I am very much not a fan of shoving binary blobs
> into DT to workaround a shoddy boot interface.

We tried spec-ing everything and building the tables in the firmware on
x86.  You really do not want to do that; it's painful to have to update
firmware in lockstep with QEMU, and when you add the next feature it
always seems like you got the bindings wrong.

And we only had one client (SeaBIOS) while you will have at least two
(TianoCore and Linux, presumably? or is Huawei targeting OSv only?).

What we do now is we have two blobs, one with the ACPI tables and one
that tells the firmware how to relocate pointers from one table to
another.  It's been working very well for both SeaBIOS and OVMF.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 12:04, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Nov 12, 2014 at 11:52:22AM +0000, Paolo Bonzini wrote:
>> SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>> On ARM you could use DT binary blobs instead of fw_cfg, as proposed
>> already (I don't remember if it was in this thread or IRC).  Then if you
>> want to go !UEFI you can extract the tables from those binary blobs.
>
> This sounds broken. I am very much not a fan of shoving binary blobs
> into DT to workaround a shoddy boot interface.

My understanding from an IRC conversation yesterday was that at
least some of these ACPI blobs contain data which has to be constructed
at the point it is requested (ie is not fixed at the point when
QEMU starts up), because OVMF will do:
 * startup
 * prod some parts of the hardware to configure it
 * request ACPI tables via fw_cfg
and the ACPI tables have to reflect the statu of the hardware
after OVMF's poking, not before.

It wasn't entirely clear to me whether this applies equally
to the ARM UEFI setup as to x86 + OVMF, but it does suggest that
it would be better to define a memory-mapped variant of fw_cfg
rather than stuffing the blobs into the device tree. (I didn't
much like throwing the blobs in the dtb myself either.)

If somebody with more x86/ACPI knowledge could clarify what the
dynamically-constructed parts of the tables are and whether
they're likely to apply to use that would be good. I think they
involved PCI in some way, but I don't have access to my irc logs
right now to check. (I could imagine that ARM UEFI might not need
to prod and configure a PCI bus and devices in the way that an
x86 BIOS expects it has to, but that's speculation on my part,
and I dunno that I'd care to bake that assumption into the design
anyway.)

-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 14:27, Peter Maydell wrote:
> If somebody with more x86/ACPI knowledge could clarify what the
> dynamically-constructed parts of the tables are and whether
> they're likely to apply to use that would be good. I think they
> involved PCI in some way, but I don't have access to my irc logs
> right now to check. (I could imagine that ARM UEFI might not need
> to prod and configure a PCI bus and devices in the way that an
> x86 BIOS expects it has to, but that's speculation on my part,
> and I dunno that I'd care to bake that assumption into the design
> anyway.)

Yes, IIUC it's just for ACPI hotplug on devices behind a PCI-to-PCI
bridge.  On Linux/x86 we can use the PCI standard hotplug controller
(SHPC), but not on Windows.  So if it's just PCI, I tend to agree with
you.  ARM should really just use PCIe and SHPC hotplug and call it a day.

To me that actually goes in favor of putting blobs in the DT.  :)

That said, if you really really want to write kernel drivers for stuff
that x86 puts in the AML, there's little point in building the ACPI
tables in QEMU.  You already have a DT interface to talk to non-ACPI
devices, Tiano Core can use the same bits to build ACPI tables.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Claudio Fontana]

On 12.11.2014 14:27, Peter Maydell wrote:
> On 12 November 2014 12:04, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Nov 12, 2014 at 11:52:22AM +0000, Paolo Bonzini wrote:
>>> SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>>> On ARM you could use DT binary blobs instead of fw_cfg, as proposed
>>> already (I don't remember if it was in this thread or IRC).  Then if you
>>> want to go !UEFI you can extract the tables from those binary blobs.
>>
>> This sounds broken. I am very much not a fan of shoving binary blobs
>> into DT to workaround a shoddy boot interface.
> 
> My understanding from an IRC conversation yesterday was that at
> least some of these ACPI blobs contain data which has to be constructed
> at the point it is requested (ie is not fixed at the point when
> QEMU starts up), because OVMF will do:
>  * startup
>  * prod some parts of the hardware to configure it
>  * request ACPI tables via fw_cfg
> and the ACPI tables have to reflect the statu of the hardware
> after OVMF's poking, not before.
> 
> It wasn't entirely clear to me whether this applies equally
> to the ARM UEFI setup as to x86 + OVMF, but it does suggest that
> it would be better to define a memory-mapped variant of fw_cfg
> rather than stuffing the blobs into the device tree. (I didn't
> much like throwing the blobs in the dtb myself either.)
> 
> If somebody with more x86/ACPI knowledge could clarify what the
> dynamically-constructed parts of the tables are and whether
> they're likely to apply to use that would be good. I think they
> involved PCI in some way, but I don't have access to my irc logs
> right now to check. (I could imagine that ARM UEFI might not need
> to prod and configure a PCI bus and devices in the way that an
> x86 BIOS expects it has to, but that's speculation on my part,
> and I dunno that I'd care to bake that assumption into the design
> anyway.)

Would the last step you mention allow for guests to start with an already existing PCI interrupt map
and the BAR registers preprogrammed to point to somewhere sane?

I ask because on OSv at the moment, the situation is that for x86 we don't need to reprogram anything on PCI,
as everything is already nicely set up by the time the guest starts, and thus the BAR addresses can be read directly.
On ARM we have to reprogram the BARs manually for all devices.

Couldn't we give an easier time to each OS guest by having everything nicely set up on AArch64 as well?

Claudio

 

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
> 
> Would the last step you mention allow for guests to start with an already existing PCI interrupt map
> and the BAR registers preprogrammed to point to somewhere sane?
> 
> I ask because on OSv at the moment, the situation is that for x86 we don't need to reprogram anything on PCI,
> as everything is already nicely set up by the time the guest starts, and thus the BAR addresses can be read directly.
> On ARM we have to reprogram the BARs manually for all devices.
> 
> Couldn't we give an easier time to each OS guest by having everything
> nicely set up on AArch64 as well?

Definitely, I think having the OS manually program the BARs only makes sense
in an environment where you don't have a full-featured boot loader or you
don't trust it. In servers and virtual machines, the PCI bus should always come
fully set up. This also implies that the OS should not have to deal with
registers for setting up the translation between PCI and system address
ranges.

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 15:32, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
>> Would the last step you mention allow for guests to start with an already existing PCI interrupt map
>> and the BAR registers preprogrammed to point to somewhere sane?
>>
>> I ask because on OSv at the moment, the situation is that for x86 we don't need to reprogram anything on PCI,
>> as everything is already nicely set up by the time the guest starts, and thus the BAR addresses can be read directly.
>> On ARM we have to reprogram the BARs manually for all devices.
>>
>> Couldn't we give an easier time to each OS guest by having everything
>> nicely set up on AArch64 as well?
>
> Definitely, I think having the OS manually program the BARs only makes sense
> in an environment where you don't have a full-featured boot loader or you
> don't trust it. In servers and virtual machines, the PCI bus should always come
> fully set up. This also implies that the OS should not have to deal with
> registers for setting up the translation between PCI and system address
> ranges.

It seems to me like complicated stuff like that definitely belongs
in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
the hardware and let the guest (or the firmware, which is guest
code from QEMU's point of view) set it up however it wants.

-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 16:39, Peter Maydell wrote:
> > Definitely, I think having the OS manually program the BARs only makes sense
> > in an environment where you don't have a full-featured boot loader or you
> > don't trust it. In servers and virtual machines, the PCI bus should always come
> > fully set up. This also implies that the OS should not have to deal with
> > registers for setting up the translation between PCI and system address
> > ranges.
>
> It seems to me like complicated stuff like that definitely belongs
> in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> the hardware and let the guest (or the firmware, which is guest
> code from QEMU's point of view) set it up however it wants.

It definitely doesn't belong in QEMU!

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 16:52:25 Paolo Bonzini wrote:
> On 12/11/2014 16:39, Peter Maydell wrote:
> > > Definitely, I think having the OS manually program the BARs only makes sense
> > > in an environment where you don't have a full-featured boot loader or you
> > > don't trust it. In servers and virtual machines, the PCI bus should always come
> > > fully set up. This also implies that the OS should not have to deal with
> > > registers for setting up the translation between PCI and system address
> > > ranges.
> >
> > It seems to me like complicated stuff like that definitely belongs
> > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> > the hardware and let the guest (or the firmware, which is guest
> > code from QEMU's point of view) set it up however it wants.
> 
> It definitely doesn't belong in QEMU!

The easiest option would probably be not make all PCI devices have
fixed BARs and not even allow them to be changed. I believe this is
what kvmtool does, but I can see how supporting both modes is much
harder than either one.

How does it work on x86 with qemu?

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 16:57, Arnd Bergmann wrote:
> > > It seems to me like complicated stuff like that definitely belongs
> > > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> > > the hardware and let the guest (or the firmware, which is guest
> > > code from QEMU's point of view) set it up however it wants.
> > 
> > It definitely doesn't belong in QEMU!
> 
> The easiest option would probably be not make all PCI devices have
> fixed BARs and not even allow them to be changed. I believe this is
> what kvmtool does, but I can see how supporting both modes is much
> harder than either one.

kvmtool does not have firmware; it starts the kernel directly, so it
does all the setup that usually is done by the firmware.  It implements
a couple real-mode interfaces that Linux uses when booting, but nothing
of this deals with PCI.

x86 QEMU always runs firmware.  Even if you specify -kernel, the
firmware does all the usual initialization and then boots from a small
ROM.  The ROM contains the bootloader, so it loads and starts the kernel.

> How does it work on x86 with qemu?

Same as real hardware.  Firmware (SeaBIOS or OVMF) builds the memory
map, decides where in the free space the BARs go, and programs the PCI
devices accordingly.

kvmtool is the special one here.  Xen, VMware, Hyper-V all do the same
as QEMU.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 17:04:30 Paolo Bonzini wrote:
> On 12/11/2014 16:57, Arnd Bergmann wrote:
> > > > It seems to me like complicated stuff like that definitely belongs
> > > > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> > > > the hardware and let the guest (or the firmware, which is guest
> > > > code from QEMU's point of view) set it up however it wants.
> > > 
> > > It definitely doesn't belong in QEMU!
> > 
> > The easiest option would probably be not make all PCI devices have
> > fixed BARs and not even allow them to be changed. I believe this is
> > what kvmtool does, but I can see how supporting both modes is much
> > harder than either one.
> 
> kvmtool does not have firmware; it starts the kernel directly, so it
> does all the setup that usually is done by the firmware.  It implements
> a couple real-mode interfaces that Linux uses when booting, but nothing
> of this deals with PCI.
> 
> x86 QEMU always runs firmware.  Even if you specify -kernel, the
> firmware does all the usual initialization and then boots from a small
> ROM.  The ROM contains the bootloader, so it loads and starts the kernel.

Ok, I see.

> > How does it work on x86 with qemu?
> 
> Same as real hardware.  Firmware (SeaBIOS or OVMF) builds the memory
> map, decides where in the free space the BARs go, and programs the PCI
> devices accordingly.
> 
> kvmtool is the special one here.  Xen, VMware, Hyper-V all do the same
> as QEMU.

Right. I guess embedded ARM images in qemu are a third way then, because
these don't have a guest firmware but also don't set up the hardware
the way that kvmtool does.

Claudio's request to do this differently on arm64 seems absolutely
reasonable to me, but I guess that implies having UEFI or something
like it that does the PCI scan. Not sure what the best default for
"qemu -kernel image" should be though if you don't explicitly pass
a firmware image.

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 17:13, Arnd Bergmann wrote:
> > Same as real hardware.  Firmware (SeaBIOS or OVMF) builds the memory
> > map, decides where in the free space the BARs go, and programs the PCI
> > devices accordingly.
> > 
> > kvmtool is the special one here.  Xen, VMware, Hyper-V all do the same
> > as QEMU.
> 
> Right. I guess embedded ARM images in qemu are a third way then, because
> these don't have a guest firmware but also don't set up the hardware
> the way that kvmtool does.
> 
> Claudio's request to do this differently on arm64 seems absolutely
> reasonable to me, but I guess that implies having UEFI or something
> like it that does the PCI scan. Not sure what the best default for
> "qemu -kernel image" should be though if you don't explicitly pass
> a firmware image.

The PowerPC folks are using u-boot as the firmware.  I know Peter
disagrees, but I don't understand why so I'll throw this up for
discussion too; it is definitely lighter-weight than UEFI.  Would that
make sense for ARM?

I just stumbled upon patches that port u-Boot to bare x86 (no SeaBIOS):
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/201885 -- they
have to do the same PCI BAR initialization that Claudio is doing in OSv.
Could Claudio build a u-boot ROM that sets up PCI and then automatically
loads the OSv kernel?

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 16:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 12/11/2014 17:13, Arnd Bergmann wrote:
>> > Same as real hardware.  Firmware (SeaBIOS or OVMF) builds the memory
>> > map, decides where in the free space the BARs go, and programs the PCI
>> > devices accordingly.
>> >
>> > kvmtool is the special one here.  Xen, VMware, Hyper-V all do the same
>> > as QEMU.
>>
>> Right. I guess embedded ARM images in qemu are a third way then, because
>> these don't have a guest firmware but also don't set up the hardware
>> the way that kvmtool does.
>>
>> Claudio's request to do this differently on arm64 seems absolutely
>> reasonable to me, but I guess that implies having UEFI or something
>> like it that does the PCI scan. Not sure what the best default for
>> "qemu -kernel image" should be though if you don't explicitly pass
>> a firmware image.
>
> The PowerPC folks are using u-boot as the firmware.  I know Peter
> disagrees, but I don't understand why so I'll throw this up for
> discussion too; it is definitely lighter-weight than UEFI.  Would that
> make sense for ARM?

I don't have any objection to people running u-boot firmware if that's
what makes sense for them. Historically QEMU's -kernel option on ARM
has behaved as "do the extremely bare minimum that the ARM kernel boot
protocol demands, as by-hand setup of the CPU before we start executing".
Before the advent of multiprocessor this was pretty much just "set up an
ATAGS list and then boot the kernel by setting a couple of registers and
jumping to it". Bringing in SMP and then the GIC and now device trees
has gradually increased the scope of the little bootloader that's built
into QEMU, and it is showing the strains a little (especially now it has
to cope with some tweaks for some board/SoC models where their SMP secondary
boot protocol is different). TrustZone is probably going to complicate
the picture further.

Anyway, this approach works because ARMv7 embedded Linux doesn't
really demand much of its bootloader. It has the advantage that we
haven't needed to carry around ROM images for all our board models
(which are a pain to deal with since you get to pick between needing
a target CPU toolchain for building, or distributing binary blobs;
and in some cases they aren't redistributable at all unless you go to
the effort of writing custom firmware just for QEMU). Unlike x86,
we wouldn't be able to just have one firmware and be done with it.

ARMv8 Linux at the moment also has a pretty minimal set of booting
requirements (the kernel does not require anything like setting up
PCI BARs, for instance), and so we've taken a similar approach with
the addition of implementing the PSCI firmware interface for CPU
power up/down/reset.

You could make a pretty good argument that the QEMU builtin
bootloader really has reached the end of its useful life and
we should switch to always booting some lump of firmware. (Indeed,
the VM spec for ARMv8 mandates a UEFI firmware.) But for any
particular new feature in the past we've ended up taking the
pragmatic approach of adding it to the builtin loader rather than
committing to replacing the whole thing. If ARMv8 Linux starts
mandating PCI setup and other complicated setup then the
balance probably tilts towards running at least some firmware
in all cases.

-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Gerd Hoffmann]

  Hi,

> The PowerPC folks are using u-boot as the firmware.  I know Peter
> disagrees, but I don't understand why so I'll throw this up for
> discussion too; it is definitely lighter-weight than UEFI.  Would that
> make sense for ARM?

Played around with that.  Look here:

https://www.kraxel.org/cgit/jenkins/u-boot/tree/
https://www.kraxel.org/repos/jenkins/u-boot/

[ based on fedora uboot package, some vexpress patches on top ]

Problems I ran into:

 * u-boot has no virto support.
 * sdcard emulation is painfully slow on arm kvm.

Oh, and working with u-boot upstream is *ahem* a challenge.  After
trying to get a patch upstream (rpm patch #8) I'm not really surprised
any more that there are so many u-boot forks around.

Making edk2 fly on arm looks more promising to me.  Especially for
aarch64 of course, but also for armv7 + -M virt.

cheers,
  Gerd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Gerd Hoffmann]

On Mi, 2014-11-12 at 16:01 +0100, Claudio Fontana wrote:
> I ask because on OSv at the moment, the situation is that for x86 we
> don't need to reprogram anything on PCI,
> as everything is already nicely set up by the time the guest starts,
> and thus the BAR addresses can be read directly.
> On ARM we have to reprogram the BARs manually for all devices.

qemu doesn't do anything here, seabios / ovmf does the pci
initialization.

cheers,
  Gerd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Gerd Hoffmann]

  Hi,

> My understanding from an IRC conversation yesterday was that at
> least some of these ACPI blobs contain data which has to be constructed
> at the point it is requested (ie is not fixed at the point when
> QEMU starts up), because OVMF will do:
>  * startup
>  * prod some parts of the hardware to configure it
>  * request ACPI tables via fw_cfg
> and the ACPI tables have to reflect the statu of the hardware
> after OVMF's poking, not before.

It is this:

[root@fedora ~]# cat /proc/ioports 
[ ... ]
  0600-063f : 0000:00:01.3
    0600-0603 : ACPI PM1a_EVT_BLK
    0604-0605 : ACPI PM1a_CNT_BLK
    0608-060b : ACPI PM_TMR
  0700-070f : 0000:00:01.3
    0700-0707 : piix4_smbus
[ ... ]
[root@fedora ~]# lspci -vs1.3
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
	Subsystem: Red Hat, Inc Qemu virtual machine
	Flags: medium devsel, IRQ 9
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4

A bunch of acpi registers are in a hidden pci bar of the piix4 acpi
device (likewise on q35).  The firmware must map this somewhere, and
this must be done pretty early because the firmware uses the acpi pm
timer for timekeeping.

The acpi tables have references to the apci registers, so the acpi table
content must match the actual register location.

[ q35 only: similar issue with the pci mmconfig xbar ]

So there are three options to solve that:

(1) Use a fixed address.  Doable, but takes away some flexibility.

(2) Have qemu define the address locations.  Has some nasty
    initialization order issues.  Also would require (a) a
    paravirtual interface or (b) a acpi table parser in the
    firmware.

(3) Have firmware define the address location.  This is what we
    did on x86.  No paravirt interface needed, the firmware simply
    programs the registers as it likes, and qemu adapts the acpi
    tables accordingly.

> It wasn't entirely clear to me whether this applies equally
> to the ARM UEFI setup as to x86 + OVMF,

I think on arm doing (2) is alot easier as DT provides a nice way to
pass addresses from qemu to firmware/guest.

cheers,
  Gerd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Al Stone]

On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> My understanding from an IRC conversation yesterday was that at
>> least some of these ACPI blobs contain data which has to be constructed
>> at the point it is requested (ie is not fixed at the point when
>> QEMU starts up), because OVMF will do:
>>  * startup
>>  * prod some parts of the hardware to configure it
>>  * request ACPI tables via fw_cfg
>> and the ACPI tables have to reflect the statu of the hardware
>> after OVMF's poking, not before.
> 
> It is this:
> 
> [root@fedora ~]# cat /proc/ioports 
> [ ... ]
>   0600-063f : 0000:00:01.3
>     0600-0603 : ACPI PM1a_EVT_BLK
>     0604-0605 : ACPI PM1a_CNT_BLK
>     0608-060b : ACPI PM_TMR
>   0700-070f : 0000:00:01.3
>     0700-0707 : piix4_smbus
> [ ... ]

So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not
exist if hardware reduced mode ACPI is being used; the values in the
FADT should be zero so there should be no ioports (see section 5.2.9
of the ACPI spec).  If this is from an ARM platform, it _should_ be in
hardware reduced mode.  QEMU will have to take that into account.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@linaro.org
-----------------------------------

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 13/11/2014 19:16, Al Stone wrote:
>> > [root@fedora ~]# cat /proc/ioports 
>> > [ ... ]
>> >   0600-063f : 0000:00:01.3
>> >     0600-0603 : ACPI PM1a_EVT_BLK
>> >     0604-0605 : ACPI PM1a_CNT_BLK
>> >     0608-060b : ACPI PM_TMR
>> >   0700-070f : 0000:00:01.3
>> >     0700-0707 : piix4_smbus
>> > [ ... ]
> So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not
> exist if hardware reduced mode ACPI is being used; the values in the
> FADT should be zero so there should be no ioports (see section 5.2.9
> of the ACPI spec).  If this is from an ARM platform, it _should_ be in
> hardware reduced mode.  QEMU will have to take that into account.

No, this is x86.  As mentioned elsewhere in the thread, we'd have to add
a GPIO controller (e.g. PL061) to mach-virt, to replace GPE.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Gerd Hoffmann]

On Do, 2014-11-13 at 11:16 -0700, Al Stone wrote:
> On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
> >   Hi,
> > 
> >> My understanding from an IRC conversation yesterday was that at
> >> least some of these ACPI blobs contain data which has to be constructed
> >> at the point it is requested (ie is not fixed at the point when
> >> QEMU starts up), because OVMF will do:
> >>  * startup
> >>  * prod some parts of the hardware to configure it
> >>  * request ACPI tables via fw_cfg
> >> and the ACPI tables have to reflect the statu of the hardware
> >> after OVMF's poking, not before.
> > 
> > It is this:
> > 
> > [root@fedora ~]# cat /proc/ioports 
> > [ ... ]
> >   0600-063f : 0000:00:01.3
> >     0600-0603 : ACPI PM1a_EVT_BLK
> >     0604-0605 : ACPI PM1a_CNT_BLK
> >     0608-060b : ACPI PM_TMR
> >   0700-070f : 0000:00:01.3
> >     0700-0707 : piix4_smbus
> > [ ... ]
> 
> So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not
> exist if hardware reduced mode ACPI is being used;

This is x86 and gives some background on why the "firmware inits
hardware -> qemu adjusts addresses in acpi tables -> firmware loads acpi
tables via fw_cfg" init sequence is used there.

Figuring whenever you have similar problems / requirements on arm or if
you can simply go with static acpi tables is up to you ;)

cheers,
  Gerd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Claudio Fontana]

On 11.11.2014 16:29, Mark Rutland wrote:
> Hi,
> 
> On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
>> On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>
>>>
>>>> We need ACPI guest support in QEMU for AArch64 over here, with all features
>>>> (including the ability to run ACPI code and add specific tables), for
>>>> ACPI-based guests.
>>>
>>> The plan for providing ACPI to guests is that we run a UEFI BIOS
>>> blob which is what is responsible for providing ACPI and UEFI
>>> runtime services to guests which need them. (The UEFI blob finds
>>> out about its hardware by looking at a device tree that QEMU
>>> passes it, but that's a detail between QEMU and its bios blob).
>>> This pretty much looks like what x86 QEMU used to do with ACPI
>>> for a very long time, so we know it's a feasible approach.
>>
>> Hi Peter,
>>
>> The rational in the proposed approach is meant for cases where the
>> user does not want to rely on external firmware layers. While UEFI
>> could do what you are describing, the point is to avoid this not so
>> trivial overhead in the booting process. Especially in the case of
>> thin guests, where another software dependency is undesired.
> 
> I'm not sure how you plan to use ACPI without UEFI, as there are several
> pieces of information which ACPI misses, such as the memory map, which
> must be discovered from UEFI. How do you intend to discover the memory
> map without UEFI?
> 
> Additionally, with Linux and other generic OSs, the expectation is that
> the ACPI tables are discovered via the UEFI system table. How do you
> intend to discover the ACPI tables? Or other system information?
> 
> From experience with Linux, querying this information from UEFI is a
> trivial overhead, though a UEFI implementation might take a while to
> boot to the point where that is possible. It would be more generally
> helpful to have an optimized virtualised UEFI for this case (or perhaps
> just a UEFI frontend that presents the same interface to EFI
> applications but doesn't have to do any heavy lifting at boot).
> 
> So far the general trend with AArch64 at the system level is to use
> generic interfaces as far as possible. The generic interface for
> discovering ACPI tables is to boot as an EFI application and then to
> query the tables from UEFI. That is the interface others are likely to
> follow, and ACPI without UEFI is unlikely to be of much use to anyone
> else.
> 
> Why is it worth expending the effort on the boot protocol you suggest
> (which so far is not well defined) when there is already a portable,
> well-defined standard that others are already following?
> 
> Thanks,
> Mark.
> 

Hi,

I tend to mostly agree with this, we might look for alternative solutions for
speeding up guest startup in the future but in general if getting ACPI in the
guest for ARM64 requires also getting UEFI, then I can personally live with that,
especially if we strive to have the kind of optimized virtualized UEFI you mention.

We can in the meantime use these patches to test the "fast path" to the guest
by just hardcoding or passing on the command line what is needed to be able to test
information reading from ACPI from the guest side.

I cc: my colleagues Jani and Paul which have more the use case in mind and
might correct me there.

For x86 though what is the state of UEFI in QEMU? Is it relying on the OVMF
project to provide the firmware images if I understand correctly..
How is it working out in practice?
Should the same kind of approach be taken for ARM64?

As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
learns from the experience of X86 (and possibly shares some code if possible),
rather than going in a different direction by creating device trees first,
and then converting them to ACPI tables somewhere in the firmware, just because
device trees are "already there", for the reasons which have already been
mentioned before by Igor and others.

I wouldn't want for ACPI to be "sort of" supported in QEMU, but with a limited
functionality which makes it not fully useful in practice. I'd rather see it
as a first class citizen instead, including the ability to run AML code.

Thanks,

Claudio

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> On 11.11.2014 16:29, Mark Rutland wrote:
> > Hi,
> > 
> > On Thu, Nov 06, 2014 at 01:33:20PM +0000, Alexander Spyridakis wrote:
> >> On 6 November 2014 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>
> >>>
> >>>> We need ACPI guest support in QEMU for AArch64 over here, with all features
> >>>> (including the ability to run ACPI code and add specific tables), for
> >>>> ACPI-based guests.
> >>>
> >>> The plan for providing ACPI to guests is that we run a UEFI BIOS
> >>> blob which is what is responsible for providing ACPI and UEFI
> >>> runtime services to guests which need them. (The UEFI blob finds
> >>> out about its hardware by looking at a device tree that QEMU
> >>> passes it, but that's a detail between QEMU and its bios blob).
> >>> This pretty much looks like what x86 QEMU used to do with ACPI
> >>> for a very long time, so we know it's a feasible approach.
> >>
> >> Hi Peter,
> >>
> >> The rational in the proposed approach is meant for cases where the
> >> user does not want to rely on external firmware layers. While UEFI
> >> could do what you are describing, the point is to avoid this not so
> >> trivial overhead in the booting process. Especially in the case of
> >> thin guests, where another software dependency is undesired.
> > 
> > I'm not sure how you plan to use ACPI without UEFI, as there are several
> > pieces of information which ACPI misses, such as the memory map, which
> > must be discovered from UEFI. How do you intend to discover the memory
> > map without UEFI?
> > 
> > Additionally, with Linux and other generic OSs, the expectation is that
> > the ACPI tables are discovered via the UEFI system table. How do you
> > intend to discover the ACPI tables? Or other system information?
> > 
> > From experience with Linux, querying this information from UEFI is a
> > trivial overhead, though a UEFI implementation might take a while to
> > boot to the point where that is possible. It would be more generally
> > helpful to have an optimized virtualised UEFI for this case (or perhaps
> > just a UEFI frontend that presents the same interface to EFI
> > applications but doesn't have to do any heavy lifting at boot).
> > 
> > So far the general trend with AArch64 at the system level is to use
> > generic interfaces as far as possible. The generic interface for
> > discovering ACPI tables is to boot as an EFI application and then to
> > query the tables from UEFI. That is the interface others are likely to
> > follow, and ACPI without UEFI is unlikely to be of much use to anyone
> > else.
> > 
> > Why is it worth expending the effort on the boot protocol you suggest
> > (which so far is not well defined) when there is already a portable,
> > well-defined standard that others are already following?
> > 
> > Thanks,
> > Mark.
> > 
> 
> Hi,
> 
> I tend to mostly agree with this, we might look for alternative
> solutions for speeding up guest startup in the future but in general
> if getting ACPI in the guest for ARM64 requires also getting UEFI,
> then I can personally live with that, especially if we strive to have
> the kind of optimized virtualized UEFI you mention.

Given that UEFI will be required for other guests (e.g. if you want to
boot a distribution's ISO image), I hope that virtualised UEFI will see
some optimisation work.

> We can in the meantime use these patches to test the "fast path" to
> the guest by just hardcoding or passing on the command line what is
> needed to be able to test information reading from ACPI from the guest
> side.
> 
> I cc: my colleagues Jani and Paul which have more the use case in mind
> and
> might correct me there.
> 
> For x86 though what is the state of UEFI in QEMU? Is it relying on the
> OVMF project to provide the firmware images if I understand
> correctly..
> How is it working out in practice?
> Should the same kind of approach be taken for ARM64?

I'm unfortunately not familiar enough with OVMF to answer any of these
questions.

> As mentioned by others, I'd rather see an implementation of ACPI in
> QEMU which learns from the experience of X86 (and possibly shares some
> code if possible), rather than going in a different direction by
> creating device trees first, and then converting them to ACPI tables
> somewhere in the firmware, just because device trees are "already
> there", for the reasons which have already been mentioned before by
> Igor and others.

For the features which ACPI provides which device trees do not (e.g. the
dynamic addition and removal of memory and CPUs), there will need to be
some sort of interface between QEMU and the ACPI implementation. That's
already outside of the realm of DT, so as previously mentioned a simple
conversion doesn't cover the general case.

For most static things, device tree should be suitable as-is (i.e.
without translation to ACPI) for all currently supported guests.

I think any ACPI implemenation for a hypervisor should provide a
demonstrable useful feature (e.g. hot-add of CPUs) before merging so we
know the infrastructure is suitable.

> I wouldn't want for ACPI to be "sort of" supported in QEMU, but with a
> limited functionality which makes it not fully useful in practice. I'd
> rather see it as a first class citizen instead, including the ability
> to run AML code.

I agree that there's no point in having ACPI in a guest unless it
provides something which dt does not. I don't know how it should be
structured to provide those useful features.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> > On 11.11.2014 16:29, Mark Rutland wrote:
> > 
> > I tend to mostly agree with this, we might look for alternative
> > solutions for speeding up guest startup in the future but in general
> > if getting ACPI in the guest for ARM64 requires also getting UEFI,
> > then I can personally live with that, especially if we strive to have
> > the kind of optimized virtualized UEFI you mention.
> 
> Given that UEFI will be required for other guests (e.g. if you want to
> boot a distribution's ISO image), I hope that virtualised UEFI will see
> some optimisation work.

I think the requirement it just for KVM to provide something that
behaves exactly like UEFI, it doesn't have to be the full Tianocore
implementation if it's easier to reimplement the boot interface.

> > As mentioned by others, I'd rather see an implementation of ACPI in
> > QEMU which learns from the experience of X86 (and possibly shares some
> > code if possible), rather than going in a different direction by
> > creating device trees first, and then converting them to ACPI tables
> > somewhere in the firmware, just because device trees are "already
> > there", for the reasons which have already been mentioned before by
> > Igor and others.
> 
> For the features which ACPI provides which device trees do not (e.g. the
> dynamic addition and removal of memory and CPUs), there will need to be
> some sort of interface between QEMU and the ACPI implementation. That's
> already outside of the realm of DT, so as previously mentioned a simple
> conversion doesn't cover the general case.

I think we need to support the low-level interfaces in the kernel for
this anyway, we should not have to use ACPI just to do memory and CPU
hotplugging in KVM, that would be silly. If ACPI is present, it can
provide a wrapper for the same interface, but KVM should not need to
be aware of the fact that ACPI is used in the guest, after it has
passed the initial ACPI blob to the kernel.

> I think any ACPI implemenation for a hypervisor should provide a
> demonstrable useful feature (e.g. hot-add of CPUs) before merging so we
> know the infrastructure is suitable.

> > I wouldn't want for ACPI to be "sort of" supported in QEMU, but with a
> > limited functionality which makes it not fully useful in practice. I'd
> > rather see it as a first class citizen instead, including the ability
> > to run AML code.
> 
> I agree that there's no point in having ACPI in a guest unless it
> provides something which dt does not. I don't know how it should be
> structured to provide those useful features.

I see it the opposite way: we shouldn't have to use ACPI just to make
use of some feature in Linux, the only reason why you'd want ACPI support
in KVM is to be able to run Windows. It makes sense for the ACPI
implementation to be compatible with the Linux ACPI code as well so
we can test it better.

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> > > On 11.11.2014 16:29, Mark Rutland wrote:
> > > 
> > > I tend to mostly agree with this, we might look for alternative
> > > solutions for speeding up guest startup in the future but in general
> > > if getting ACPI in the guest for ARM64 requires also getting UEFI,
> > > then I can personally live with that, especially if we strive to have
> > > the kind of optimized virtualized UEFI you mention.
> > 
> > Given that UEFI will be required for other guests (e.g. if you want to
> > boot a distribution's ISO image), I hope that virtualised UEFI will see
> > some optimisation work.
> 
> I think the requirement it just for KVM to provide something that
> behaves exactly like UEFI, it doesn't have to be the full Tianocore
> implementation if it's easier to reimplement the boot interface.

We already have a port of Tinaocode that works for virt, but yes,
implementing something ligther is certainly possible.

> 
> > > As mentioned by others, I'd rather see an implementation of ACPI in
> > > QEMU which learns from the experience of X86 (and possibly shares some
> > > code if possible), rather than going in a different direction by
> > > creating device trees first, and then converting them to ACPI tables
> > > somewhere in the firmware, just because device trees are "already
> > > there", for the reasons which have already been mentioned before by
> > > Igor and others.
> > 
> > For the features which ACPI provides which device trees do not (e.g. the
> > dynamic addition and removal of memory and CPUs), there will need to be
> > some sort of interface between QEMU and the ACPI implementation. That's
> > already outside of the realm of DT, so as previously mentioned a simple
> > conversion doesn't cover the general case.
> 
> I think we need to support the low-level interfaces in the kernel for
> this anyway, we should not have to use ACPI just to do memory and CPU
> hotplugging in KVM, that would be silly.

I had that same intuitive feeling, but lacked good tecnical arguments
for it.  Care to elaborate on that?

> If ACPI is present, it can
> provide a wrapper for the same interface, but KVM should not need to
> be aware of the fact that ACPI is used in the guest, after it has
> passed the initial ACPI blob to the kernel.
> 

That's where things begin to be a bit foggy for me.  AFAIU ACPI already
has a method for doing this and I speculate that there is some IRQ
assigned to an ACPI event that causes some AML code to be interpreted by
your OS.  Wouldn't it be a matter of QEMU putting the right AML table
fragments in place to wire this up then?

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 12:34, Christoffer Dall wrote:
> AFAIU ACPI already has a method for doing this

It's not defined in the spec.  QEMU defines a bunch of registers to do
that, and provides AML that works with those registers.

While these registers can be separated from the ACPI code in QEMU...

> and I speculate that there is some IRQ
> assigned to an ACPI event that causes some AML code to be interpreted by
> your OS.

... QEMU does exactly this, it uses the "general purpose event" (GPE)
mechanism to trigger the parsing of the AML.  When you hot-plug/unplug a
CPU or memory, an SCI (system control interrupt - the ACPI IRQ) is
triggered in the guest and that's not entirely disconnected from ACPI.

Perhaps you could treat it as a shared level-triggered interrupt in DT?
 I don't know.

> Wouldn't it be a matter of QEMU putting the right AML table
> fragments in place to wire this up then?

Yes.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 11:48:27AM +0000, Paolo Bonzini wrote:
> 
> On 12/11/2014 12:34, Christoffer Dall wrote:
> > AFAIU ACPI already has a method for doing this
> 
> It's not defined in the spec.  QEMU defines a bunch of registers to do
> that, and provides AML that works with those registers.

Huh? SCI + AML is the method, and that's defined by the spec.

The registers the AML pokes are an implementation detail abstracted by
the AML, and as such are irrelevant to the spec.

> While these registers can be separated from the ACPI code in QEMU...
> 
> > and I speculate that there is some IRQ
> > assigned to an ACPI event that causes some AML code to be interpreted by
> > your OS.
> 
> ... QEMU does exactly this, it uses the "general purpose event" (GPE)
> mechanism to trigger the parsing of the AML.  When you hot-plug/unplug a
> CPU or memory, an SCI (system control interrupt - the ACPI IRQ) is
> triggered in the guest and that's not entirely disconnected from ACPI.
> 
> Perhaps you could treat it as a shared level-triggered interrupt in DT?
>  I don't know.

Putting an interrupt in DT is trivial. The hard part is the rest of the
interface, which so far there is no specification for.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 13:18, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 11:48:27AM +0000, Paolo Bonzini wrote:
>>
>> On 12/11/2014 12:34, Christoffer Dall wrote:
>>> AFAIU ACPI already has a method for doing this
>>
>> It's not defined in the spec.  QEMU defines a bunch of registers to do
>> that, and provides AML that works with those registers.
> 
> Huh? SCI + AML is the method, and that's defined by the spec.

I thought Christoffer meant a method to do the actual hotplug, not just
to signal events.  If you want to "support the low-level interfaces in
the kernel for this anyway", you certainly need to know the details
underneath the AML.

>> Perhaps you could treat it as a shared level-triggered interrupt in DT?
>>  I don't know.
> 
> Putting an interrupt in DT is trivial. The hard part is the rest of the
> interface, which so far there is no specification for.

Have you looked at docs/specs/acpi_{cpu,mem}_hotplug.txt?  Writing a DT
binding for it is trivial too.  Or are we talking about two different
things?

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Wed, Nov 12, 2014 at 1:27 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 12/11/2014 13:18, Mark Rutland wrote:
>> On Wed, Nov 12, 2014 at 11:48:27AM +0000, Paolo Bonzini wrote:
>>>
>>> On 12/11/2014 12:34, Christoffer Dall wrote:
>>>> AFAIU ACPI already has a method for doing this
>>>
>>> It's not defined in the spec.  QEMU defines a bunch of registers to do
>>> that, and provides AML that works with those registers.
>>
>> Huh? SCI + AML is the method, and that's defined by the spec.
>
> I thought Christoffer meant a method to do the actual hotplug, not just
> to signal events.  If you want to "support the low-level interfaces in
> the kernel for this anyway", you certainly need to know the details
> underneath the AML.
>
I was being deliberately vague, because I don't know how this works (I
did use the word speculate, didn't I?).

But yes, one of the reasons why I would argue that we're not in a
hurry to accept these patches is that we don't know how the actual
underlying mechanisms to do the things we want ACPI to facilitate
(e.g. cpu and memory hotplug) really work, and thus we cannot verify
the implementation or benefit directly from it today.

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 13:27:14 Paolo Bonzini wrote:
> On 12/11/2014 13:18, Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 11:48:27AM +0000, Paolo Bonzini wrote:
> >> Perhaps you could treat it as a shared level-triggered interrupt in DT?
> >>  I don't know.
> > 
> > Putting an interrupt in DT is trivial. The hard part is the rest of the
> > interface, which so far there is no specification for.
> 
> Have you looked at docs/specs/acpi_{cpu,mem}_hotplug.txt?  Writing a DT
> binding for it is trivial too.  Or are we talking about two different
> things?

Interesting. I agree that doing a DT binding for these will be trivial,
and the implementation in Linux should also be straightforward, thanks
for pointing these out.

However, it seems that the implementation that qemu uses is incompatible
with ARM64, since GPE is not part of the ACPI hardware reduced mode.

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 14:08, Arnd Bergmann wrote:
>>> Putting an interrupt in DT is trivial. The hard part is the rest of the
>>> interface, which so far there is no specification for.
>> 
>> Have you looked at docs/specs/acpi_{cpu,mem}_hotplug.txt?  Writing a DT
>> binding for it is trivial too.  Or are we talking about two different
>> things?
> 
> Interesting. I agree that doing a DT binding for these will be trivial,
> and the implementation in Linux should also be straightforward, thanks
> for pointing these out.
> 
> However, it seems that the implementation that qemu uses is incompatible
> with ARM64, since GPE is not part of the ACPI hardware reduced mode.

That makes it even simpler because you do not have to use SCI.

-M virt currently doesn't have a GPIO controller, but it's easy to add a
PL061 and specify a random GPIO pin in the DT bindings.  Then you can
use GPIO-signaled ACPI events in the AML, just move _Lxx methods move
from \_GPE to \_SB.GPIO under the GPIO controller.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 12:27:14PM +0000, Paolo Bonzini wrote:
> 
> 
> On 12/11/2014 13:18, Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 11:48:27AM +0000, Paolo Bonzini wrote:
> >>
> >> On 12/11/2014 12:34, Christoffer Dall wrote:
> >>> AFAIU ACPI already has a method for doing this
> >>
> >> It's not defined in the spec.  QEMU defines a bunch of registers to do
> >> that, and provides AML that works with those registers.
> > 
> > Huh? SCI + AML is the method, and that's defined by the spec.
> 
> I thought Christoffer meant a method to do the actual hotplug, not just
> to signal events.  If you want to "support the low-level interfaces in
> the kernel for this anyway", you certainly need to know the details
> underneath the AML.

I think when Christoffer said that ACPI already had a mechanism he was
referring to the SCI + AML, as opposed to the underlying implementation.

> >> Perhaps you could treat it as a shared level-triggered interrupt in DT?
> >>  I don't know.
> > 
> > Putting an interrupt in DT is trivial. The hard part is the rest of the
> > interface, which so far there is no specification for.
> 
> Have you looked at docs/specs/acpi_{cpu,mem}_hotplug.txt?  Writing a DT
> binding for it is trivial too.  Or are we talking about two different
> things?

Writing a binding for the partiuclar device might be trivial. How this
would fit with the DT model is more complicated, and needs to be
specified. As far as I can see, those documents are quite strongly tied
to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs).

I agree that we could do CPU and memory hotplug without ACPI, but we
need to specify the full firmware interface for doing so, and how this
interacts with the initial DTB if using DT. We can't just pick-and-mix
portions of ACPI and state that it's specified and standard.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 14:41, Mark Rutland wrote:
> Writing a binding for the partiuclar device might be trivial. How this
> would fit with the DT model is more complicated, and needs to be
> specified. As far as I can see, those documents are quite strongly tied
> to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs).

OSPM -> replace with kernel driver
OST -> used to generate events, doesn't need to be implemented in the
       kernel driver.  Or just define the meaning based on the ACPI
       _OST spec.
GPE -> replace with GPIO
APIC ID -> replace with whatever id ARM CPUs have

> I agree that we could do CPU and memory hotplug without ACPI, but we
> need to specify the full firmware interface for doing so, and how this
> interacts with the initial DTB if using DT.

The initial DTB has to expose the IDs for hotpluggable CPUs and the
range for hotpluggable memory.  In the ACPI case this goes in the SRAT.
 But none of this is insurmountable.

> We can't just pick-and-mix
> portions of ACPI and state that it's specified and standard.

But that's what you already do if you want to build ACPI tables from DT.
 You are already picking-and-mixing the variable portions of the ACPI
tables and make a DT bindings for them.

All that's left is to de-x86ify the existing spec (which is really
easy), and to figure out a DT binding for it.  It's really not unlike
any other MMIO device.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 01:59:30PM +0000, Paolo Bonzini wrote:
> 
> 
> On 12/11/2014 14:41, Mark Rutland wrote:
> > Writing a binding for the partiuclar device might be trivial. How this
> > would fit with the DT model is more complicated, and needs to be
> > specified. As far as I can see, those documents are quite strongly tied
> > to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs).
> 
> OSPM -> replace with kernel driver
> OST -> used to generate events, doesn't need to be implemented in the
>        kernel driver.  Or just define the meaning based on the ACPI
>        _OST spec.
> GPE -> replace with GPIO
> APIC ID -> replace with whatever id ARM CPUs have
> 
> > I agree that we could do CPU and memory hotplug without ACPI, but we
> > need to specify the full firmware interface for doing so, and how this
> > interacts with the initial DTB if using DT.
> 
> The initial DTB has to expose the IDs for hotpluggable CPUs and the
> range for hotpluggable memory.  In the ACPI case this goes in the SRAT.
>  But none of this is insurmountable.

My only point is that it needs to be defined, not that this definition
is impossible. That does trickle into a few places -- we currently have
no way of defining a CPU in DT which is possible but not present, for
example (the status property historically means something different per
ePAPR).

> > We can't just pick-and-mix
> > portions of ACPI and state that it's specified and standard.
> 
> But that's what you already do if you want to build ACPI tables from DT.
>  You are already picking-and-mixing the variable portions of the ACPI
> tables and make a DT bindings for them.

I don't follow. I argued _against_ trying to build ACPI tables from DT
because the two don't quite match up anyway. I argued _against_ trying
to convert ACPI tables to DT in prior discussions for similar reasons.

> All that's left is to de-x86ify the existing spec (which is really
> easy), and to figure out a DT binding for it.  It's really not unlike
> any other MMIO device.

In addition to fixing up the other specs which are affected by this
(e.g. how we describe those additional CPUs). There's also some
de-ACPIing to be done in addition to de-x86ification, and we need to be
careful to ensure we have access to all the information we require in
the absence of ACPI, and that we have a well defined behaviour on both
sides of the interface for what would previously have been implicit in
ACPI.

I'm not saying that this is impossible. It's just a greater body of work
than modifying one spec.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 12/11/2014 15:10, Mark Rutland wrote:
>>> We can't just pick-and-mix
>>> portions of ACPI and state that it's specified and standard.
>>
>> But that's what you already do if you want to build ACPI tables from DT.
>>  You are already picking-and-mixing the variable portions of the ACPI
>> tables and make a DT bindings for them.
> 
> I don't follow. I argued _against_ trying to build ACPI tables from DT
> because the two don't quite match up anyway. I argued _against_ trying
> to convert ACPI tables to DT in prior discussions for similar reasons.

Sorry, that was not you-Mark, but more you-ARM.

And in fact I'd tend to agree with you, but if there are people that
want not to use ACPI or UEFI or both, I think it's better if the UEFI
firmware swallows the same pill and builds ACPI from DT.

> In addition to fixing up the other specs which are affected by this
> (e.g. how we describe those additional CPUs). There's also some
> de-ACPIing to be done in addition to de-x86ification, and we need to be
> careful to ensure we have access to all the information we require in
> the absence of ACPI, and that we have a well defined behaviour on both
> sides of the interface for what would previously have been implicit in
> ACPI.

Yes, I agree.  On the QEMU side the de-ACPIfication would have to be
done anyway (no GPE because of the reduced hardware), but you need extra
de-ACPIfication for stuff like the SRAT.

> I'm not saying that this is impossible. It's just a greater body of work
> than modifying one spec.

No doubt about that.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > > 
> > > For the features which ACPI provides which device trees do not (e.g. the
> > > dynamic addition and removal of memory and CPUs), there will need to be
> > > some sort of interface between QEMU and the ACPI implementation. That's
> > > already outside of the realm of DT, so as previously mentioned a simple
> > > conversion doesn't cover the general case.
> > 
> > I think we need to support the low-level interfaces in the kernel for
> > this anyway, we should not have to use ACPI just to do memory and CPU
> > hotplugging in KVM, that would be silly.
> 
> I had that same intuitive feeling, but lacked good tecnical arguments
> for it.  Care to elaborate on that?

ACPI always has to interface back to the hypervisor to do anything that
changes the hardware configuration, so it essentially has to perform
a hypercall or touch some virtual register.

If we need to architect that interface in qemu anyway, we should make
it sane enough for the kernel to use directly, without having to go
through ACPI, as not everyone will want to run ACPI.
 
> > If ACPI is present, it can
> > provide a wrapper for the same interface, but KVM should not need to
> > be aware of the fact that ACPI is used in the guest, after it has
> > passed the initial ACPI blob to the kernel.
> 
> That's where things begin to be a bit foggy for me.  AFAIU ACPI already
> has a method for doing this and I speculate that there is some IRQ
> assigned to an ACPI event that causes some AML code to be interpreted by
> your OS.  Wouldn't it be a matter of QEMU putting the right AML table
> fragments in place to wire this up then?

Yes, that is what I meant with a wrapper. The two choices are:

1. have an interrupt and a hypercall or mmio interface. When the
   interrupt gets triggered, we ask the interface what happened and
   do something on the same interface depending on the state of the
   system.

2. have an interrupt that causes AML code to be run, that code will
   use the hypercall or mmio interface to find out what happened and
   create an ACPI event. This event is enqueued to the generic ACPI
   hotplug handler, which depending on the state of the system decides
   to do something by calling into AML code again, which will trigger
   the underlying interface.

>From qemu's point of view, the two are doing exactly the same thing,
except that the MMIO access can be hidden in AML so the OS doesn't have
to know the interface. Note that in case of Xen, the use of hypercalls
means that the OS has to know the interface after all, so the second
half of the process is handled by drivers/xen/xen-acpi-*hotplug.c.

Note how the implementation that uses the ACPI wrapper is much
more complex than the native one that does the same thing:

-rw-r--r-- 1 arnd arnd  2119 Nov 10 16:43 drivers/xen/cpu_hotplug.c
-rw-r--r-- 1 arnd arnd 10987 Nov 10 16:43 drivers/xen/xen-acpi-cpuhotplug.c

-rw-r--r-- 1 arnd arnd  6894 Nov 10 16:43 drivers/xen/xen-balloon.c
-rw-r--r-- 1 arnd arnd 12085 Nov 10 16:43 drivers/xen/xen-acpi-memhotplug.c

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Christoffer Dall]

On Wed, Nov 12, 2014 at 02:03:01PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> > On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > > > 
> > > > For the features which ACPI provides which device trees do not (e.g. the
> > > > dynamic addition and removal of memory and CPUs), there will need to be
> > > > some sort of interface between QEMU and the ACPI implementation. That's
> > > > already outside of the realm of DT, so as previously mentioned a simple
> > > > conversion doesn't cover the general case.
> > > 
> > > I think we need to support the low-level interfaces in the kernel for
> > > this anyway, we should not have to use ACPI just to do memory and CPU
> > > hotplugging in KVM, that would be silly.
> > 
> > I had that same intuitive feeling, but lacked good tecnical arguments
> > for it.  Care to elaborate on that?
> 
> ACPI always has to interface back to the hypervisor to do anything that
> changes the hardware configuration, so it essentially has to perform
> a hypercall or touch some virtual register.
> 
> If we need to architect that interface in qemu anyway, we should make
> it sane enough for the kernel to use directly, without having to go
> through ACPI, as not everyone will want to run ACPI.
>  

With the usual benefits of doing it in ACPI will not require updates on
both sides if we need to fix something, but also the usual downside of
having something obscure and pseduo-hidden, which may be broken
underneath, I suppose.

> > > If ACPI is present, it can
> > > provide a wrapper for the same interface, but KVM should not need to
> > > be aware of the fact that ACPI is used in the guest, after it has
> > > passed the initial ACPI blob to the kernel.
> > 
> > That's where things begin to be a bit foggy for me.  AFAIU ACPI already
> > has a method for doing this and I speculate that there is some IRQ
> > assigned to an ACPI event that causes some AML code to be interpreted by
> > your OS.  Wouldn't it be a matter of QEMU putting the right AML table
> > fragments in place to wire this up then?
> 
> Yes, that is what I meant with a wrapper. The two choices are:
> 
> 1. have an interrupt and a hypercall or mmio interface. When the
>    interrupt gets triggered, we ask the interface what happened and
>    do something on the same interface depending on the state of the
>    system.
> 
> 2. have an interrupt that causes AML code to be run, that code will
>    use the hypercall or mmio interface to find out what happened and
>    create an ACPI event. This event is enqueued to the generic ACPI
>    hotplug handler, which depending on the state of the system decides
>    to do something by calling into AML code again, which will trigger
>    the underlying interface.
> 
> From qemu's point of view, the two are doing exactly the same thing,
> except that the MMIO access can be hidden in AML so the OS doesn't have
> to know the interface.

right, thanks for the explanation.

> Note that in case of Xen, the use of hypercalls
> means that the OS has to know the interface after all, so the second
> half of the process is handled by drivers/xen/xen-acpi-*hotplug.c.
> 
> Note how the implementation that uses the ACPI wrapper is much
> more complex than the native one that does the same thing:
> 
> -rw-r--r-- 1 arnd arnd  2119 Nov 10 16:43 drivers/xen/cpu_hotplug.c
> -rw-r--r-- 1 arnd arnd 10987 Nov 10 16:43 drivers/xen/xen-acpi-cpuhotplug.c
> 
> -rw-r--r-- 1 arnd arnd  6894 Nov 10 16:43 drivers/xen/xen-balloon.c
> -rw-r--r-- 1 arnd arnd 12085 Nov 10 16:43 drivers/xen/xen-acpi-memhotplug.c
> 
Interesting.

-Christoffer

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Wed, Nov 12, 2014 at 11:15:08AM +0000, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
> > > On 11.11.2014 16:29, Mark Rutland wrote:
> > > 
> > > I tend to mostly agree with this, we might look for alternative
> > > solutions for speeding up guest startup in the future but in general
> > > if getting ACPI in the guest for ARM64 requires also getting UEFI,
> > > then I can personally live with that, especially if we strive to have
> > > the kind of optimized virtualized UEFI you mention.
> > 
> > Given that UEFI will be required for other guests (e.g. if you want to
> > boot a distribution's ISO image), I hope that virtualised UEFI will see
> > some optimisation work.
> 
> I think the requirement it just for KVM to provide something that
> behaves exactly like UEFI, it doesn't have to be the full Tianocore
> implementation if it's easier to reimplement the boot interface.

I agree that we don't need a full Tianocore, but whatever we have must
implement the minimal interface UEFI requires (which is more than just
the boot interface).

For a "boot this EFI application" workflow you can skip most of the BDS
stuff, but you still need boot services and runtime services provided to
the application.

> > > As mentioned by others, I'd rather see an implementation of ACPI in
> > > QEMU which learns from the experience of X86 (and possibly shares some
> > > code if possible), rather than going in a different direction by
> > > creating device trees first, and then converting them to ACPI tables
> > > somewhere in the firmware, just because device trees are "already
> > > there", for the reasons which have already been mentioned before by
> > > Igor and others.
> > 
> > For the features which ACPI provides which device trees do not (e.g. the
> > dynamic addition and removal of memory and CPUs), there will need to be
> > some sort of interface between QEMU and the ACPI implementation. That's
> > already outside of the realm of DT, so as previously mentioned a simple
> > conversion doesn't cover the general case.
> 
> I think we need to support the low-level interfaces in the kernel for
> this anyway, we should not have to use ACPI just to do memory and CPU
> hotplugging in KVM, that would be silly. If ACPI is present, it can
> provide a wrapper for the same interface, but KVM should not need to
> be aware of the fact that ACPI is used in the guest, after it has
> passed the initial ACPI blob to the kernel.

The difficulty here is that there is currently no common low-level
interface between the guest and any specific hypervisor for these
facilities. This would be up to kvm tool or QEMU, not KVM itself. So
we'd have to spec one for !ACPI.

With ACPI, the interface should be common (following the ACPI spec), but
we don't have a common interface underlying that.

I am not averse to having mechanisms for !ACPI, but we'd need to spec
something.

> > I think any ACPI implemenation for a hypervisor should provide a
> > demonstrable useful feature (e.g. hot-add of CPUs) before merging so we
> > know the infrastructure is suitable.
> 
> > > I wouldn't want for ACPI to be "sort of" supported in QEMU, but with a
> > > limited functionality which makes it not fully useful in practice. I'd
> > > rather see it as a first class citizen instead, including the ability
> > > to run AML code.
> > 
> > I agree that there's no point in having ACPI in a guest unless it
> > provides something which dt does not. I don't know how it should be
> > structured to provide those useful features.
> 
> I see it the opposite way: we shouldn't have to use ACPI just to make
> use of some feature in Linux, the only reason why you'd want ACPI support
> in KVM is to be able to run Windows. It makes sense for the ACPI
> implementation to be compatible with the Linux ACPI code as well so
> we can test it better.

At the moment, ACPI specifies how these features should work. So without
inventing a whole new interface, ACPI is the way of providing those
features.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 09:08, Claudio Fontana <claudio.fontana@huawei.com> wrote:
> As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
> learns from the experience of X86 (and possibly shares some code if possible),
> rather than going in a different direction by creating device trees first,
> and then converting them to ACPI tables somewhere in the firmware, just because
> device trees are "already there", for the reasons which have already been
> mentioned before by Igor and others.

I think the motivation for "leave ACPI entirely to the firmware" is not
just that the device trees are already there, but because it allows
for a cleaner separation of concerns between QEMU and the firmware
and thus makes QEMU simpler and easier to maintain in future.
However as a result of the discussion in this thread and on IRC about
what x86 QEMU/OVMF do and what the complexities of handling this in
UEFI are, I'm not as sure as I was that it's actually feasible in
practice.

I agree with you that if we have QEMU generating ACPI information
itself then we should definitely follow the existing tested approach
that x86 QEMU+OVMF have, and share code, both in QEMU and in the
UEFI firmware. (As I understand it there is a common source code
base between OVMF and the Tianocore code we're using for the ARM
QEMU UEFI firmware. I've probably got the project names wrong here;
I'm not familiar with the distinctions between Tianocore, EDK2,
OVMF, etc.)

The x86 QEMU-generating-APCI approach is more complicated than
what this RFC patchset does, since it generates various separate
tables and hands them individually to the firmware, rather than
creating a single (non-relocatable) complete ACPI blob. I would
hope we didn't need to support both "provide separated tables to
firmware" and "provide a single blob to a standalone guest kernel";
if we're agreed that ACPI should imply UEFI we can forget about
the latter, though.

thanks
-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Claudio Fontana]

On 12.11.2014 19:10, Peter Maydell wrote:
> On 12 November 2014 09:08, Claudio Fontana <claudio.fontana@huawei.com> wrote:
>> As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
>> learns from the experience of X86 (and possibly shares some code if possible),
>> rather than going in a different direction by creating device trees first,
>> and then converting them to ACPI tables somewhere in the firmware, just because
>> device trees are "already there", for the reasons which have already been
>> mentioned before by Igor and others.
> 
> I think the motivation for "leave ACPI entirely to the firmware" is not
> just that the device trees are already there, but because it allows
> for a cleaner separation of concerns between QEMU and the firmware
> and thus makes QEMU simpler and easier to maintain in future.
> However as a result of the discussion in this thread and on IRC about
> what x86 QEMU/OVMF do and what the complexities of handling this in
> UEFI are, I'm not as sure as I was that it's actually feasible in
> practice.
> 
> I agree with you that if we have QEMU generating ACPI information
> itself then we should definitely follow the existing tested approach
> that x86 QEMU+OVMF have, and share code, both in QEMU and in the
> UEFI firmware. (As I understand it there is a common source code
> base between OVMF and the Tianocore code we're using for the ARM
> QEMU UEFI firmware. I've probably got the project names wrong here;
> I'm not familiar with the distinctions between Tianocore, EDK2,
> OVMF, etc.)
> 
> The x86 QEMU-generating-APCI approach is more complicated than
> what this RFC patchset does,

I think that the RFC was useful in its goal, as it generated a lot of comments,
and we will also be using it to do some internal early tests with ACPI on the
guest to speed up development.

I agree with you that as a result of this discussion, the solution for QEMU
upstreaming purposes needs to take everything discussed (possibly more)
into account.

> since it generates various separate
> tables and hands them individually to the firmware, rather than
> creating a single (non-relocatable) complete ACPI blob. I would
> hope we didn't need to support both "provide separated tables to
> firmware" and "provide a single blob to a standalone guest kernel";
> if we're agreed that ACPI should imply UEFI we can forget about
> the latter, though.
> 

As I mentioned I am personally fine with the ACPI -> UEFI implication, also
Paul (who represents my employer here) mentioned that we can live with this
implication if we have to.
The hope is to try to keep what needs to be implemented under control,
as to have as small an impact on boot time as possible, while still complying
to the specifications.

Thanks,

Claudio

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 13 November 2014 09:57, Claudio Fontana <claudio.fontana@huawei.com> wrote:
> I agree with you that as a result of this discussion, the solution for QEMU
> upstreaming purposes needs to take everything discussed (possibly more)
> into account.

(Picking this email as a reasonable if slightly arbitrary
place to try to summarise this discussion thread...)

Everybody agrees that we need to support guests that want
to use ACPI. There are several possible approaches to this
that have been proposed:

1. all-in-QEMU: generate a complete single ACPI table in QEMU
and pass it to the guest and/or firmware, as this RFC does

2. all-in-UEFI: don't do any ACPI table generation in QEMU;
just create a device tree (and some standardised interfaces for
hotplugging, etc), and let the UEFI firmware put together the
ACPI tables accordingly

3. mixed-mode: follow the x86/QEMU practice, and have QEMU
generate a set of ACPI table fragments, which UEFI then has to
stitch together in combination with any extras it wants to add
itself before passing the result to the guest. [Some of these
fragments might need to be generated on-demand and supplied via
a fw_cfg-like conduit device; this is necessary on x86 and might
be also for ARM.]

My opinion about the best approach has swung all over the
place during the course of this discussion, but at the moment
I think mixed-mode is the way to go.

The most common use case for ACPI is going to be with UEFI,
and I'm told that the details of Tianocore and the ACPI binary
format mean that it's not possible for UEFI to edit a complete
ACPI blob to add any extra items it needs to, so for this
use case the all-in-QEMU approach won't work. We could in theory
support all-in-QEMU as an extra boot protocol for directly booting
a guest that used ACPI without UEFI, alongside one of the other
two methods, but I'm pretty reluctant to support multiple ways
of constructing the ACPI tables and I think we have agreement that
we don't need to do that. That means we can drop 'all-in-QEMU'
from consideration and concentrate on the other two options.

The all-in-UEFI approach is potentially workable, and from a
QEMU maintainer's perspective it has the attraction of a clean
separation: QEMU only has to describe hardware in one way, and
all the ACPI related code is in the firmware. However it also
has some definite demerits:
 * we'd need code in UEFI to create ACPI tables based on the
   device tree information, which is at minimum code that nobody's
   written yet, and could be difficult even given the restriction
   that it only has to cope with the particular subset of dtb that
   QEMU generates
 * adding support for something like "hotplug-$FOO" needs changes
   in QEMU and also in UEFI, even if UEFI would otherwise not need
   to care about the hotplugging, because it has to translate the
   relevant dtb entries into ACPI
 * we would need to specify and define dt bindings for any (virtual)
   hardware used for notifying and controlling hotplug type features
   rather than these being an implementation detail of QEMU
   (though we might want to define these anyway so that you can use
   hotplug etc from a non-ACPI non-UEFI guest, of course)

Going with mixed-mode does mean we end up with a sort of triplication
of code (once to create the board model, once to describe it in DT
and once to describe it in ACPI), but the payoff is that we get to
handle ACPI the same way as we do on x86, which includes a lot of
preexisting code both in QEMU and in UEFI. We also don't need to
update the UEFI code when we add new hotplug features.

Does anybody have an approach that I've missed from my list of
three, or any advantages/disadvantages to add that might tilt
the decision in a different direction?

thanks
-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Hanjun Guo]

On 2014-10-31 2:02, Mark Rutland wrote:
> On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
>> On 30 October 2014 17:43, Alexander Spyridakis
>> <a.spyridakis@virtualopensystems.com> wrote:
>>> Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
>>> implemented in this patch series, which is the minimum for a basic ARM support.
>>>
>>> The set of generated tables are:
>>> - RSDP
>>> - XSDT
>>> - MADT
>>> - GTDT
>>> - FADT
>>> - FACS
>>> - DSDT
>>>
>>> The tables are created in standalone buffers, taking into account the
>>> needed information passed from the virt machine model. When the generation
>>> is finalized, the individual buffers are compacted to a single ACPI binary
>>> blob, where it is injected on the guest memory space in a fixed location.
>>> The guest kernel can find the ACPI tables by providing to it the physical
>>> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
>>
>> (Sorry, I should have waited for the cover letter to arrive before replying.)
>>
>> I think this is definitely the wrong approach. We already have to
>> generate device tree information for the hardware we have, and having
>> an equivalent parallel infrastructure for generating ACPI as well
>> seems like it would be a tremendous mess. We should support guests
>> that require ACPI by having QEMU boot a UEFI bios blob and have that
>> UEFI code generate ACPI tables based on the DTB we hand it.
>> (Chances seem good that any guest that wants ACPI is going to want
>> UEFI runtime services anyway.)
> 
> Depending on why people want ACPI in a guest environment, generating
> ACPI tables from a DTB might not be possible (e.g. if they want to use
> AML for some reason).

Agreed.

> 
> So the important question is _why_ the guest needs to see an ACPI
> environment. What exactly can ACPI provide to the guest that DT does not
> already provide, and why is that necessary? What infrastrucutre is
> needed for that use case?

There is important feature called system device dynamic reconfiguration,
you know, hot-add/remove, if a gust need more/less memory or CPU, can we
add or remove them dynamically with DT? ACPI can do this, but I have no
idea if DT can. (Sorry, I don't know much about DT)

Thanks
Hanjun

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Mark Rutland]

On Thu, Nov 06, 2014 at 06:53:03AM +0000, Hanjun Guo wrote:
> On 2014-10-31 2:02, Mark Rutland wrote:
> > On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
> >> On 30 October 2014 17:43, Alexander Spyridakis
> >> <a.spyridakis@virtualopensystems.com> wrote:
> >>> Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
> >>> implemented in this patch series, which is the minimum for a basic ARM support.
> >>>
> >>> The set of generated tables are:
> >>> - RSDP
> >>> - XSDT
> >>> - MADT
> >>> - GTDT
> >>> - FADT
> >>> - FACS
> >>> - DSDT
> >>>
> >>> The tables are created in standalone buffers, taking into account the
> >>> needed information passed from the virt machine model. When the generation
> >>> is finalized, the individual buffers are compacted to a single ACPI binary
> >>> blob, where it is injected on the guest memory space in a fixed location.
> >>> The guest kernel can find the ACPI tables by providing to it the physical
> >>> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
> >>
> >> (Sorry, I should have waited for the cover letter to arrive before replying.)
> >>
> >> I think this is definitely the wrong approach. We already have to
> >> generate device tree information for the hardware we have, and having
> >> an equivalent parallel infrastructure for generating ACPI as well
> >> seems like it would be a tremendous mess. We should support guests
> >> that require ACPI by having QEMU boot a UEFI bios blob and have that
> >> UEFI code generate ACPI tables based on the DTB we hand it.
> >> (Chances seem good that any guest that wants ACPI is going to want
> >> UEFI runtime services anyway.)
> > 
> > Depending on why people want ACPI in a guest environment, generating
> > ACPI tables from a DTB might not be possible (e.g. if they want to use
> > AML for some reason).
> 
> Agreed.
> 
> > 
> > So the important question is _why_ the guest needs to see an ACPI
> > environment. What exactly can ACPI provide to the guest that DT does not
> > already provide, and why is that necessary? What infrastrucutre is
> > needed for that use case?
> 
> There is important feature called system device dynamic reconfiguration,
> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
> add or remove them dynamically with DT? ACPI can do this, but I have no
> idea if DT can. (Sorry, I don't know much about DT)

There is no way of doing this with DT. There has been work into DT
fragments/overlays where portions can be added to the tree dynamically,
but that's controlled by the OS rather than the hypervisor, and there's
no standard for communicating what has been hotplugged to trigger
changes to the tree, so it's not quite the same. It really only works
for tightly coupled hw/kernel/userspace combinations (i.e. embedded).

Depending on how you implement the hot-add/remove you might be able to
get away with an initial static configuration translated from DT. If you
need to describe what might be hotplugged from the start, then I suspect
you cannot get away with translating a DT in general.

Thanks,
Mark.

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Arnd Bergmann]

On Thursday 06 November 2014 13:30:01 Mark Rutland wrote:
> 
> There is no way of doing this with DT. There has been work into DT
> fragments/overlays where portions can be added to the tree dynamically,
> but that's controlled by the OS rather than the hypervisor, and there's
> no standard for communicating what has been hotplugged to trigger
> changes to the tree, so it's not quite the same. It really only works
> for tightly coupled hw/kernel/userspace combinations (i.e. embedded).
> 
> Depending on how you implement the hot-add/remove you might be able to
> get away with an initial static configuration translated from DT. If you
> need to describe what might be hotplugged from the start, then I suspect
> you cannot get away with translating a DT in general.

I believe IBM POWER 5/6/7 servers have an interface to update the DT
from the hypervisor, but it's not a nice interface, so we may want to
avoid duplicating that.

	Arnd

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 06/11/2014 07:53, Hanjun Guo wrote:
>> So the important question is _why_ the guest needs to see an ACPI
>> environment. What exactly can ACPI provide to the guest that DT does not
>> already provide, and why is that necessary? What infrastrucutre is
>> needed for that use case?
> 
> There is important feature called system device dynamic reconfiguration,
> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
> add or remove them dynamically with DT? ACPI can do this, but I have no
> idea if DT can. (Sorry, I don't know much about DT)

Indeed hot-add/remove is the single biggest AML user in x86 QEMU.
Whether you really need it, it depends on what you are adding/removing.

For PCI there is no problem.  We can use PCIe from the beginning, and
use PCIe hotplug support that is already in QEMU.

Memory and CPU are more problematic.  For memory we could perhaps use a
PCI memory device, though I'm not sure if that would require drivers in
the OS or everything just works.

CPU hotplug, however, probably requires AML.  Of course it can be
generated in the firmware, like we used to do for x86, but Igor
explained why it wasn't a great idea.  That said, one of the problems
("never ending expansion of PV QEMU-BIOS interface") could be less
important since ARM DT is a better interface than x86 fw_cfg.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Igor Mammedov]

On Thu, 06 Nov 2014 16:57:47 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 06/11/2014 07:53, Hanjun Guo wrote:
> >> So the important question is _why_ the guest needs to see an ACPI
> >> environment. What exactly can ACPI provide to the guest that DT does not
> >> already provide, and why is that necessary? What infrastrucutre is
> >> needed for that use case?
> > 
> > There is important feature called system device dynamic reconfiguration,
> > you know, hot-add/remove, if a gust need more/less memory or CPU, can we
> > add or remove them dynamically with DT? ACPI can do this, but I have no
> > idea if DT can. (Sorry, I don't know much about DT)
> 
> Indeed hot-add/remove is the single biggest AML user in x86 QEMU.
> Whether you really need it, it depends on what you are adding/removing.
> 
> For PCI there is no problem.  We can use PCIe from the beginning, and
> use PCIe hotplug support that is already in QEMU.
> 
> Memory and CPU are more problematic.  For memory we could perhaps use a
> PCI memory device, though I'm not sure if that would require drivers in
> the OS or everything just works.
BTW what's PCI memory device? Is there any reference I could read about it?

> CPU hotplug, however, probably requires AML.  Of course it can be
> generated in the firmware, like we used to do for x86, but Igor
> explained why it wasn't a great idea.  That said, one of the problems
> ("never ending expansion of PV QEMU-BIOS interface") could be less
> important since ARM DT is a better interface than x86 fw_cfg.
Unfortunately we still would need to teach UEFI to recognize
QEMU specific DT entries that were just invented,
it doesn't matter what transport is used (DT or fw_cfg) to convey
new information to UEFI/BIOS.

> 
> Paolo
> 

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini]

On 06/11/2014 17:18, Igor Mammedov wrote:
> On Thu, 06 Nov 2014 16:57:47 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 06/11/2014 07:53, Hanjun Guo wrote:
>>>> So the important question is _why_ the guest needs to see an ACPI
>>>> environment. What exactly can ACPI provide to the guest that DT does not
>>>> already provide, and why is that necessary? What infrastrucutre is
>>>> needed for that use case?
>>>
>>> There is important feature called system device dynamic reconfiguration,
>>> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
>>> add or remove them dynamically with DT? ACPI can do this, but I have no
>>> idea if DT can. (Sorry, I don't know much about DT)
>>
>> Indeed hot-add/remove is the single biggest AML user in x86 QEMU.
>> Whether you really need it, it depends on what you are adding/removing.
>>
>> For PCI there is no problem.  We can use PCIe from the beginning, and
>> use PCIe hotplug support that is already in QEMU.
>>
>> Memory and CPU are more problematic.  For memory we could perhaps use a
>> PCI memory device, though I'm not sure if that would require drivers in
>> the OS or everything just works.
> 
> BTW what's PCI memory device? Is there any reference I could read about it?

Just something with a huge BAR.  Like ivshmem, but teaching the OS to
see it as memory.

>> CPU hotplug, however, probably requires AML.  Of course it can be
>> generated in the firmware, like we used to do for x86, but Igor
>> explained why it wasn't a great idea.  That said, one of the problems
>> ("never ending expansion of PV QEMU-BIOS interface") could be less
>> important since ARM DT is a better interface than x86 fw_cfg.
> Unfortunately we still would need to teach UEFI to recognize
> QEMU specific DT entries that were just invented,
> it doesn't matter what transport is used (DT or fw_cfg) to convey
> new information to UEFI/BIOS.

Right, it's just a bit more organized than fw_cfg.

Paolo

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Hanjun Guo]

On 2014-11-6 23:57, Paolo Bonzini wrote:
> On 06/11/2014 07:53, Hanjun Guo wrote:
>>> So the important question is _why_ the guest needs to see an ACPI
>>> environment. What exactly can ACPI provide to the guest that DT does not
>>> already provide, and why is that necessary? What infrastrucutre is
>>> needed for that use case?
>>
>> There is important feature called system device dynamic reconfiguration,
>> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
>> add or remove them dynamically with DT? ACPI can do this, but I have no
>> idea if DT can. (Sorry, I don't know much about DT)
> 
> Indeed hot-add/remove is the single biggest AML user in x86 QEMU.
> Whether you really need it, it depends on what you are adding/removing.
> 
> For PCI there is no problem.  We can use PCIe from the beginning, and
> use PCIe hotplug support that is already in QEMU.
> 
> Memory and CPU are more problematic.  For memory we could perhaps use a
> PCI memory device, though I'm not sure if that would require drivers in
> the OS or everything just works.

I didn't see some code for hot-adding system memory as PCI device, but people
from Fujitsu is working on that in another solution - QEmu memory hot unplug
support:

https://www.mail-archive.com/qemu-devel@nongnu.org/msg251355.html

for the guest, ACPI based memory hot-add/remove was already supported.

Thanks
Hanjun

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Leif Lindholm]

Sorry for being late to the party, missed this set when it went out.

On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
> On 30 October 2014 17:43, Alexander Spyridakis
> <a.spyridakis@virtualopensystems.com> wrote:
> > Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been
> > implemented in this patch series, which is the minimum for a basic ARM support.
> >
> > The set of generated tables are:
> > - RSDP
> > - XSDT
> > - MADT
> > - GTDT
> > - FADT
> > - FACS
> > - DSDT
> >
> > The tables are created in standalone buffers, taking into account the
> > needed information passed from the virt machine model. When the generation
> > is finalized, the individual buffers are compacted to a single ACPI binary
> > blob, where it is injected on the guest memory space in a fixed location.
> > The guest kernel can find the ACPI tables by providing to it the physical
> > address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
> 
> (Sorry, I should have waited for the cover letter to arrive before replying.)
> 
> I think this is definitely the wrong approach. We already have to
> generate device tree information for the hardware we have, and having
> an equivalent parallel infrastructure for generating ACPI as well
> seems like it would be a tremendous mess.

I don't see this as duplication, I see this as platform completeness.
And it would be really useful for firmware validation.

> We should support guests
> that require ACPI by having QEMU boot a UEFI bios blob and have that
> UEFI code generate ACPI tables based on the DTB we hand it.
> (Chances seem good that any guest that wants ACPI is going to want
> UEFI runtime services anyway.)

Yes, we could do that, but in doing so we would be treating ACPI as
some artificial tickbox thing rather than a platform property. And it
would introduce an entirely new class of ARM-specific errors.

Moreover, we currently have separate EDK2 platforms for ARM*/x86 QEMU
(ArmVirtualizationQEMU vs. Ovmf). The goal there is to progressively
move towards greater amounts of shared code between the two, and
hopefully merge them into one eventually.

Deferring specifically on ARM the responsibility of generating (all)
ACPI tables to the firmware leads to reduced amount of code shared
between ARM/x86 in both QEMU and EDK2. And reduced ability to share
future developments in that area (x86 QEMU seems well on the way
towards letting you inject AML blobs from the command line).

/
    Leif

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 9 March 2015 at 21:12, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> Sorry for being late to the party, missed this set when it went out.

You seem to be replying to an email thread which is now many
months old and at a part of the conversation which was obsoleted
by the subsequent discussion in this thread...

Summary-of-consensus email from this thread:
http://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02529.html

I think this is the most recent patchset, implementing the
"mixed-mode" design:
http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg03290.html

(I might have missed an update, though, I've been on holiday
and not tracking the list as closely the last few weeks.)

thanks
-- PMM

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Shannon Zhao]

On 2015/3/9 20:28, Peter Maydell wrote:
> On 9 March 2015 at 21:12, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>> > Sorry for being late to the party, missed this set when it went out.
> You seem to be replying to an email thread which is now many
> months old and at a part of the conversation which was obsoleted
> by the subsequent discussion in this thread...
> 
> Summary-of-consensus email from this thread:
> http://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02529.html
> 
> I think this is the most recent patchset, implementing the
> "mixed-mode" design:
> http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg03290.html
> 
> (I might have missed an update, though, I've been on holiday
> and not tracking the list as closely the last few weeks.)

Hi Peter,

You haven't missed it. I don't send an update version since V3. I'm waiting for
the dependencies(the patches of Igor, Marcel, Michael) to be settled down. Then
I'll send a new version.

-- 
Thanks,
Shannon

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Leif Lindholm]

On Mon, Mar 09, 2015 at 09:28:05PM +0900, Peter Maydell wrote:
> On 9 March 2015 at 21:12, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > Sorry for being late to the party, missed this set when it went out.
> 
> You seem to be replying to an email thread which is now many
> months old and at a part of the conversation which was obsoleted
> by the subsequent discussion in this thread...

And here I was getting all prepared to have to argue :)
 
> Summary-of-consensus email from this thread:
> http://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02529.html

Thanks!

> I think this is the most recent patchset, implementing the
> "mixed-mode" design:
> http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg03290.html

Excellent, that looks like exactly what I was hoping for.
I'll give that a spin - thanks again and sorry for the noise.
 
/
    Leif