ACPI reorganization for hardware-reduced API addition
v5 cover ACPI reorganization for hardware-reduced API addition
This patch set provides an ACPI code reorganization in preparation for adding a shared hardware-reduced ACPI API to QEMU.
The changes are coming from the NEMU [1] project where we're defining a new x86 machine type: i386/virt. This is an EFI only, ACPI hardware-reduced platform that is built on top of a generic hardware-reduced ACPI API [2]. This API was initially based off the generic parts of the arm/virt-acpi-build.c implementation, and the goal is for both i386/virt and arm/virt to duplicate as little code as possible by using this new, shared API.
As a preliminary for adding this hardware-reduced ACPI API to QEMU, we did some ACPI code reorganization with the following goals:
* Share as much as possible of the current ACPI build APIs between legacy and hardware-reduced ACPI.
* Share the ACPI build code across machine types and architectures and remove the typical PC machine type dependency.
The patches are also available in their own git branch [3].
[1] https://github.com/intel/nemu
[2] https://github.com/intel/nemu/blob/topic/virt-x86/hw/acpi/reduced.c
[3] https://github.com/intel/nemu/tree/topic/upstream/acpi
v1 -> v2:
* Drop the hardware-reduced implementation for now. Our next patch
* set
will add hardware-reduced and convert arm/virt to it.
* Implement the ACPI build methods as a QOM Interface Class and
* convert
the PC machine type to it.
* acpi_conf_pc_init() uses a PCMachineState pointer and not a MachineState one as its argument.
v2 -> v3:
* Cc all relevant maintainers, no functional changes.
v3 -> v4:
* Renamed all AcpiConfiguration pointers from conf to acpi_conf.
* Removed the ACPI_BUILD_ALIGN_SIZE export.
* Temporarily updated the arm virt build_rsdp() prototype for bisectability purposes.
* Removed unneeded pci headers from acpi-build.c.
* Refactor the acpi PCI host getter so that it truly is architecture agnostic, by carrying the PCI host pointer through the AcpiConfiguration structure.
* Splitted the PCI host AML builder API export patch from the PCI host and holes getter one.
* Reduced the build_srat() export scope to hw/i386 instead of the broader hw/acpi. SRAT builders are truly architecture specific and can hardly be generalized.
* Completed the ACPI builder documentation.
v4 -> v5:
* Reorganize the ACPI RSDP export and XSDT implementation into 3 patches.
* Fix the hw/i386/acpi header inclusions.
Samuel Ortiz (16):
hw: i386: Decouple the ACPI build from the PC machine type
hw: acpi: Export ACPI build alignment API
hw: acpi: The RSDP build API can return void
hw: acpi: Export the RSDP build API
hw: acpi: Implement XSDT support for RSDP
hw: acpi: Factorize the RSDP build API implementation
hw: i386: Move PCI host definitions to pci_host.h
hw: acpi: Export the PCI host and holes getters
hw: acpi: Do not create hotplug method when handler is not defined
hw: i386: Make the hotpluggable memory size property more generic
hw: i386: Export the i386 ACPI SRAT build method
hw: i386: Export the MADT build method
hw: acpi: Define ACPI tables builder interface
hw: i386: Implement the ACPI builder interface for PC
hw: pci-host: piix: Return PCI host pointer instead of PCI bus
hw: i386: Set ACPI configuration PCI host pointer
Sebastien Boeuf (2):
hw: acpi: Export the PCI hotplug API
hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Yang Zhong (6):
hw: acpi: Generalize AML build routines
hw: acpi: Factorize _OSC AML across architectures
hw: acpi: Export and generalize the PCI host AML API
hw: acpi: Export the MCFG getter
hw: acpi: Fix memory hotplug AML generation error
hw: i386: Refactor PCI host getter
hw/i386/acpi-build.h | 9 +- include/hw/acpi/acpi-defs.h | 14 + include/hw/acpi/acpi.h | 44 ++ include/hw/acpi/aml-build.h | 47 ++ include/hw/acpi/builder.h | 100 +++ include/hw/i386/acpi.h | 28 + include/hw/i386/pc.h | 49 +- include/hw/mem/memory-device.h | 2 + include/hw/pci/pci_host.h | 6 + hw/acpi/aml-build.c | 981 +++++++++++++++++++++++++++++ hw/acpi/builder.c | 97 +++ hw/acpi/cpu.c | 8 +- hw/acpi/cpu_hotplug.c | 9 +- hw/acpi/memory_hotplug.c | 21 +- hw/acpi/pcihp.c | 10 +- hw/arm/virt-acpi-build.c | 93 +-- hw/i386/acpi-build.c | 1072 +++----------------------------- hw/i386/pc.c | 198 +++--- hw/i386/pc_piix.c | 36 +- hw/i386/pc_q35.c | 22 +- hw/i386/xen/xen-hvm.c | 19 +- hw/pci-host/piix.c | 32 +- stubs/pci-host-piix.c | 6 - hw/acpi/Makefile.objs | 1 + stubs/Makefile.objs | 1 - 25 files changed, 1644 insertions(+), 1261 deletions(-) create mode 100644 include/hw/acpi/builder.h create mode 100644 include/hw/i386/acpi.h create mode 100644 hw/acpi/builder.c delete mode 100644 stubs/pci-host-piix.c
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 1/24 hw: i386: Decouple the ACPI build from the PC machine type
ACPI tables are platform and machine type and even architecture agnostic, and as such we want to provide an internal ACPI API that only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently from the PC or Q35 machine types, we are moving a few MachineState structure fields into a machine type agnostic structure called AcpiConfiguration. The structure fields we move are:
HotplugHandler *acpi_dev AcpiNVDIMMState acpi_nvdimm_state; FWCfgState *fw_cfg
ram_addr_t below_4g_mem_size, above_4g_mem_size bool apic_xrupt_override
unsigned apic_id_limit
uint64_t numa_nodes
uint64_t numa_mem
--- hw/i386/acpi-build.h | 4 +- include/hw/acpi/acpi.h | 44 ++++++++++ include/hw/i386/pc.h | 19 ++--- hw/acpi/cpu_hotplug.c | 9 +- hw/arm/virt-acpi-build.c | 10 --- hw/i386/acpi-build.c | 136 ++++++++++++++---------------- hw/i386/pc.c | 176 ++++++++++++++++++++++++--------------- hw/i386/pc_piix.c | 21 ++--- hw/i386/pc_q35.c | 21 ++--- hw/i386/xen/xen-hvm.c | 19 +++-- 10 files changed, 257 insertions(+), 202 deletions(-)
hw/i386/acpi-build.h +3 -1
@@ -2,6 +2,8 @@#ifndef HW_I386_ACPI_BUILD_H #define HW_I386_ACPI_BUILD_H -void acpi_setup (void ); +#include "hw/acpi/acpi.h" + +void acpi_setup (MachineState *machine,AcpiConfiguration *acpi_conf);#endif
include/hw/acpi/acpi.h +44 -0
56 lines not on this page · raw message
include/hw/i386/pc.h +5 -14
@@ -12,6 +12,7 @@#include "qemu/range.h" #include "qemu/bitmap.h" #include "sysemu/sysemu.h" +#include "hw/acpi/acpi.h" #include "hw/pci/pci.h" #include "hw/compat.h" #include "hw/mem/pc-dimm.h"
@@ -35,10 +36,8 @@ struct PCMachineState {Notifier machine_done;/* Pointers to devices and objects: */ -HotplugHandler *acpi_dev;ISADevice *rtc;PCIBus *bus; -FWCfgState *fw_cfg;qemu_irq *gsi;/* Configuration options: */
@@ -46,28 +45,20 @@ struct PCMachineState {OnOffAuto vmport;OnOffAuto smm; -AcpiNVDIMMState acpi_nvdimm_state; -bool acpi_build_enabled;bool smbus;bool sata;bool pit; -/* RAM information (sizes, addresses, configuration): */ -ram_addr_t below_4g_mem_size, above_4g_mem_size; - -/* CPU and apic information: */ -bool apic_xrupt_override; -unsigned apic_id_limit; +/* CPU information */ uint16_t boot_cpus; -/* NUMA information: */ -uint64_t numa_nodes; -uint64_t *node_mem; -/* Address space used by IOAPIC device. All IOAPIC interrupts * will be translated to MSI messages in the address space. */ AddressSpace *ioapic_as; + +/* ACPI configuration */ +AcpiConfiguration acpi_configuration; };#define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device"
hw/acpi/cpu_hotplug.c +5 -4
@@ -237,9 +237,9 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState *machine,/* The current AML generator can cover the APIC ID range [0..255], * inclusive, for VCPU hotplug. */ QEMU_BUILD_BUG_ON (ACPI_CPU_HOTPLUG_ID_LIMIT >256 ); -if (pcms->apic_id_limit >ACPI_CPU_HOTPLUG_ID_LIMIT ) { +if (pcms->acpi_configuration.apic_id_limit >ACPI_CPU_HOTPLUG_ID_LIMIT ) {error_report ("max_cpus is too large. APIC ID of last CPU is %u" , - pcms->apic_id_limit -1 ); + pcms->acpi_configuration.apic_id_limit -1 );exit (1 ); }
@@ -316,8 +316,9 @@ void build_legacy_cpu_hotplug_aml(Aml *ctx, MachineState *machine,* ith up to 255 elements. Windows guests up to win2k8 fail when * VarPackageOp is used. */ - pkg = pcms->apic_id_limit <=255 ?aml_package (pcms->apic_id_limit) : -aml_varpackage (pcms->apic_id_limit); + pkg = pcms->acpi_configuration.apic_id_limit <=255 ? +aml_package (pcms->acpi_configuration.apic_id_limit) : +aml_varpackage (pcms->acpi_configuration.apic_id_limit);for (i =0 , apic_idx =0 ; i < apic_ids->len; i++) {int apic_id = apic_ids->cpus[i].arch_id;
hw/arm/virt-acpi-build.c +0 -10
@@ -790,16 +790,6 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)free_aml_allocator (); } -typedef -struct AcpiBuildState { -/* Copy of table in RAM (for patching). */ -MemoryRegion *table_mr; -MemoryRegion *rsdp_mr; -MemoryRegion *linker_mr; -/* Is table patched? */ -bool patched; -}AcpiBuildState ; -static void virt_acpi_build (VirtMachineState *vms,AcpiBuildTables *tables) {
hw/i386/acpi-build.c +61 -75
342 lines not on this page · raw message
hw/i386/pc.c +107 -69
478 lines not on this page · raw message
hw/i386/pc_piix.c +11 -10
@@ -71,6 +71,7 @@ static void pc_init1(MachineState *machine, {PCMachineState *pcms =PC_MACHINE (machine);PCMachineClass *pcmc =PC_MACHINE_GET_CLASS (pcms); +AcpiConfiguration *acpi_conf = &pcms->acpi_configuration;MemoryRegion *system_memory =get_system_memory ();MemoryRegion *system_io =get_system_io ();int i;
@@ -142,11 +143,11 @@ static void pc_init1(MachineState *machine, }if (machine->ram_size >= lowmem) { - pcms->above_4g_mem_size = machine->ram_size - lowmem; - pcms->below_4g_mem_size = lowmem; + acpi_conf->above_4g_mem_size = machine->ram_size - lowmem; + acpi_conf->below_4g_mem_size = lowmem; }else { - pcms->above_4g_mem_size =0 ; - pcms->below_4g_mem_size = machine->ram_size; + acpi_conf->above_4g_mem_size =0 ; + acpi_conf->below_4g_mem_size = machine->ram_size; } }
@@ -199,8 +200,8 @@ static void pc_init1(MachineState *machine, pci_type, &i440fx_state, &piix3_devfn, &isa_bus, pcms->gsi, system_memory, system_io, machine->ram_size, - pcms->below_4g_mem_size, - pcms->above_4g_mem_size, + acpi_conf->below_4g_mem_size, + acpi_conf->above_4g_mem_size, pci_memory, ram_memory); pcms->bus = pci_bus; }else {
@@ -289,16 +290,16 @@ static void pc_init1(MachineState *machine,object_property_add_link (OBJECT (machine),PC_MACHINE_ACPI_DEVICE_PROP ,TYPE_HOTPLUG_HANDLER , - (Object **)&pcms->acpi_dev, + (Object **)&acpi_conf->acpi_dev, object_property_allow_set_link,OBJ_PROP_LINK_STRONG , &error_abort);object_property_set_link (OBJECT (machine),OBJECT (piix4_pm),PC_MACHINE_ACPI_DEVICE_PROP , &error_abort); } -if (pcms->acpi_nvdimm_state.is_enabled) { -nvdimm_init_acpi_state (&pcms->acpi_nvdimm_state, system_io, - pcms->fw_cfg,OBJECT (pcms)); +if (acpi_conf->acpi_nvdimm_state.is_enabled) { +nvdimm_init_acpi_state (&acpi_conf->acpi_nvdimm_state, system_io, + acpi_conf->fw_cfg,OBJECT (pcms)); } }
hw/i386/pc_q35.c +11 -10
@@ -63,6 +63,7 @@ static void pc_q35_init(MachineState *machine) {PCMachineState *pcms =PC_MACHINE (machine);PCMachineClass *pcmc =PC_MACHINE_GET_CLASS (pcms); +AcpiConfiguration *acpi_conf = &pcms->acpi_configuration;Q35PCIHost *q35_host;PCIHostState *phb;PCIBus *host_bus;
@@ -116,11 +117,11 @@ static void pc_q35_init(MachineState *machine) }if (machine->ram_size >= lowmem) { - pcms->above_4g_mem_size = machine->ram_size - lowmem; - pcms->below_4g_mem_size = lowmem; + acpi_conf->above_4g_mem_size = machine->ram_size - lowmem; + acpi_conf->below_4g_mem_size = lowmem; }else { - pcms->above_4g_mem_size =0 ; - pcms->below_4g_mem_size = machine->ram_size; + acpi_conf->above_4g_mem_size =0 ; + acpi_conf->below_4g_mem_size = machine->ram_size; }if (xen_enabled ()) {
@@ -179,9 +180,9 @@ static void pc_q35_init(MachineState *machine) MCH_HOST_PROP_SYSTEM_MEM, NULL);object_property_set_link (OBJECT (q35_host),OBJECT (system_io),MCH_HOST_PROP_IO_MEM ,NULL ); -object_property_set_int (OBJECT (q35_host), pcms->below_4g_mem_size, +object_property_set_int (OBJECT (q35_host), acpi_conf->below_4g_mem_size,PCI_HOST_BELOW_4G_MEM_SIZE ,NULL ); -object_property_set_int (OBJECT (q35_host), pcms->above_4g_mem_size, +object_property_set_int (OBJECT (q35_host), acpi_conf->above_4g_mem_size,PCI_HOST_ABOVE_4G_MEM_SIZE ,NULL );/* pci */ qdev_init_nofail (DEVICE (q35_host));
@@ -194,7 +195,7 @@ static void pc_q35_init(MachineState *machine)object_property_add_link (OBJECT (machine),PC_MACHINE_ACPI_DEVICE_PROP ,TYPE_HOTPLUG_HANDLER , - (Object **)&pcms->acpi_dev, + (Object **)&acpi_conf->acpi_dev, object_property_allow_set_link,OBJ_PROP_LINK_STRONG , &error_abort); object_property_set_link(OBJECT(machine), OBJECT(lpc),
@@ -276,9 +277,9 @@ static void pc_q35_init(MachineState *machine)pc_vga_init (isa_bus, host_bus);pc_nic_init (pcmc, isa_bus, host_bus); -if (pcms->acpi_nvdimm_state.is_enabled) { -nvdimm_init_acpi_state (&pcms->acpi_nvdimm_state, system_io, - pcms->fw_cfg,OBJECT (pcms)); +if (acpi_conf->acpi_nvdimm_state.is_enabled) { +nvdimm_init_acpi_state (&acpi_conf->acpi_nvdimm_state, system_io, + acpi_conf->fw_cfg,OBJECT (pcms)); } }
hw/i386/xen/xen-hvm.c +10 -9
@@ -190,6 +190,7 @@ qemu_irq *xen_interrupt_controller_init(void)static void xen_ram_init (PCMachineState *pcms,ram_addr_t ram_size,MemoryRegion **ram_memory_p) { +AcpiConfiguration *acpi_conf = &pcms->acpi_configuration;MemoryRegion *sysmem =get_system_memory ();ram_addr_t block_len; uint64_t user_lowmem = object_property_get_uint(qdev_get_machine(),
@@ -207,20 +208,20 @@ static void xen_ram_init(PCMachineState *pcms, }if (ram_size >= user_lowmem) { - pcms->above_4g_mem_size = ram_size - user_lowmem; - pcms->below_4g_mem_size = user_lowmem; + acpi_conf->above_4g_mem_size = ram_size - user_lowmem; + acpi_conf->below_4g_mem_size = user_lowmem; }else { - pcms->above_4g_mem_size =0 ; - pcms->below_4g_mem_size = ram_size; + acpi_conf->above_4g_mem_size =0 ; + acpi_conf->below_4g_mem_size = ram_size; } -if (!pcms->above_4g_mem_size) { +if (!acpi_conf->above_4g_mem_size) { block_len = ram_size; }else {/* * Xen does not allocate the memory continuously, it keeps a * hole of the size computed above or passed in. */ - block_len = (1ULL <<32 ) + pcms->above_4g_mem_size; + block_len = (1ULL <<32 ) + acpi_conf->above_4g_mem_size; }memory_region_init_ram (&ram_memory,NULL ,"xen.ram" , block_len, &error_fatal);
@@ -237,12 +238,12 @@ static void xen_ram_init(PCMachineState *pcms,*/ memory_region_init_alias (&ram_lo,NULL ,"xen.ram.lo" , &ram_memory,0xc0000 , - pcms->below_4g_mem_size -0xc0000 ); + acpi_conf->below_4g_mem_size -0xc0000 );memory_region_add_subregion (sysmem,0xc0000 , &ram_lo); -if (pcms->above_4g_mem_size >0 ) { +if (acpi_conf->above_4g_mem_size >0 ) {memory_region_init_alias (&ram_hi,NULL ,"xen.ram.hi" , &ram_memory,0x100000000ULL , - pcms->above_4g_mem_size); + acpi_conf->above_4g_mem_size);memory_region_add_subregion (sysmem,0x100000000ULL , &ram_hi); } }
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 01/24] hw: i386: Decouple the ACPI build from the PC machine type
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:24 +0100 Samuel Ortiz <[email protected]> wrote:
ACPI tables are platform and machine type and even architecture agnostic, and as such we want to provide an internal ACPI API that only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently from the PC or Q35 machine types, we are moving a few MachineState structure fields into a machine type agnostic structure called AcpiConfiguration. The structure fields we move are:
It's not obvious why new structure is needed, especially at the beginning of series. We probably should place this patch much later in the series (if we need it at all) and try generalize a much as possible without using it.
And try to come up with an API that doesn't need centralized collection of data somehow related to ACPI (most of the fields here are not generic and applicable to a specific board/target).
For generic API, I'd prefer a separate building blocks like build_fadt()/... that take as an input only parameters necessary to compose a table/aml part with occasional board interface hooks instead of all encompassing AcpiConfiguration and board specific 'acpi_build' that would use them when/if needed.
We probably should split series into several smaller
(if possible independent) ones, so people won't be scared of its sheer size and run away from reviewing it.
That way it would be easier to review, amend certain parts and merge.
acpi_setup() & co probably should be the last things that's are generalized as they are called by concrete boards and might collect board specific data and apply compat workarounds for building ACPI tables (assuming that we won't push non generic data into generic API).
See more comments below
Quoted 57 lines
HotplugHandler
*acpi_devAcpiNVDIMMStateacpi_nvdimm_state; FWCfgState*fw_cfg
ram_addr_tbelow_4g_mem_size,above_4g_mem_sizeboolapic_xrupt_override
unsignedapic_id_limit
uint64_tnuma_nodes
uint64_tnuma_memSigned-off-by Samuel Ortiz <[email protected]>--- hw/i386/acpi-build.h | 4 +- include/hw/acpi/acpi.h | 44 ++++++++++ include/hw/i386/pc.h | 19 ++--- hw/acpi/cpu_hotplug.c | 9 +- hw/arm/virt-acpi-build.c | 10 --- hw/i386/acpi-build.c | 136 ++++++++++++++---------------- hw/i386/pc.c | 176 ++++++++++++++++++++++++--------------- hw/i386/pc_piix.c | 21 ++--- hw/i386/pc_q35.c | 21 ++--- hw/i386/xen/xen-hvm.c | 19 +++-- 10 files changed, 257 insertions(+), 202 deletions(-)hw/i386/acpi-build.h +3
-1@@ -2,6 +2,8 @@#ifndef HW_I386_ACPI_BUILD_H #define HW_I386_ACPI_BUILD_H -void acpi_setup (void ); +#include "hw/acpi/acpi.h" + +void acpi_setup (MachineState *machine,AcpiConfiguration *acpi_conf);#endif include/hw/acpi/acpi.h +5
-0@@ -24,6 +24,8 @@#include "exec/memory.h" #include "hw/irq.h" #include "hw/acpi/acpi_dev_interface.h" +#include "hw/hotplug.h" +#include "hw/mem/nvdimm.h" /* * current device naming scheme supports up to 256 memory devices @@ -186,6 +188,48 @@ extern int acpi_enabled;extern char unsigned *acpi_tables;extern size_t acpi_tables_len; +typedef +struct AcpiBuildState { + /* Copy of table in RAM (for patching). */
include/hw/acpi/acpi.h extern int acpi_enabled; · line 203
Quoted 10 lines
include/hw/acpi/acpi.h +10
-0+MemoryRegion *table_mr; +/* Is table patched? */ +bool patched; +void *rsdp; +MemoryRegion *rsdp_mr; +MemoryRegion *linker_mr; +} AcpiBuildState; + +typedef +struct AcpiConfiguration {
We used to have a similar intermediate structure PcGuestInfo, but got rid of it in the end. Even with other questions aside I'm not quite convinced that it's good idea to reintroduce similar one again.
include/hw/acpi/acpi.h extern int acpi_enabled; · line 207
Quoted 4 lines
include/hw/acpi/acpi.h +4
-0+/* Machine class ACPI settings */ +int legacy_acpi_table_size; +bool rsdp_in_ram; +unsigned acpi_data_size;
(*) well, all 2 are the legacy stuff, I'd rather not to push it into
generic API and keep it in the caller as board specific/machine version code.
include/hw/acpi/acpi.h extern int acpi_enabled; · line 218
Quoted 11 lines
include/hw/acpi/acpi.h +11
-0+ +/* Machine state ACPI settings */ +HotplugHandler *acpi_dev; +AcpiNVDIMMState acpi_nvdimm_state; + +/* +* The fields below are machine settings that +* are not ACPI specific. However they are needed +* for building ACPI tables and as such should be +* carried through the ACPI configuration structure. +*/
if they are not ACPI specific, then it shouldn't be in acpi configuration. Some of the fields are compat hacks, which doesn't belong to generic API so I'd leave them in board specific code and some are target specific which also doesn't belong in generic place.
include/hw/acpi/acpi.h extern int acpi_enabled; · line 222
Quoted 5 lines
include/hw/acpi/acpi.h +4
-0+bool legacy_cpu_hotplug; +bool linuxboot_dma_enabled; +FWCfgState *fw_cfg; +ram_addr_t below_4g_mem_size, above_4g_mem_size;;
Just curious, how is this applicable to i386/virt machine? Does it also have memory split in 2 regions?
Is it possible to have only one region?
include/hw/acpi/acpi.h extern int acpi_enabled; · line 224
Quoted 2 lines
include/hw/acpi/acpi.h +2
-0+uint64_t numa_nodes; +uint64_t *node_mem;
that's kept in PCMachine for the sake of legacy SeaBIOS which builds ACPI tables on its own.
I'd suggest to use existing globals instead (like ARM does) so that we wouldn't have to hunt down extra copies later when those globals are re-factored to properties.
include/hw/acpi/acpi.h extern int acpi_enabled; · line 232
Quoted 8 lines
include/hw/acpi/acpi.h +8
-0+bool apic_xrupt_override; +unsigned apic_id_limit; +PCIHostState *pci_host; + +/* Build state */ +AcpiBuildState *build_state; +} AcpiConfiguration; +
[...]
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 01/24] hw: i386: Decouple the ACPI build from the PC machine type
Hi Igor,
Quoted 12 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:24 +0100 Samuel Ortiz <[email protected]> wrote:
ACPI tables are platform and machine type and even architecture agnostic, and as such we want to provide an internal ACPI API that only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently from the PC or Q35 machine types, we are moving a few MachineState structure fields into a machine type agnostic structure called AcpiConfiguration. The structure fields we move are:
Quoted 4 lines
It's not obvious why new structure is needed, especially at the beginning of series. We probably should place this patch much later in the series (if we need it at all) and try generalize a much as possible without using it.
Patches order set aside, this new structure is needed to make the existing API not completely bound to the pc machine type anymore and "Decouple the ACPI build from the PC machine type".
It was either creating a structure to build ACPI tables in a machine type independent fashion, or pass custom structures (or potentially long list of arguments) to the existing APIs. See below.
Quoted 9 lines
And try to come up with an API that doesn't need centralized collection of data somehow related to ACPI (most of the fields here are not generic and applicable to a specific board/target).
For generic API, I'd prefer a separate building blocks like build_fadt()/... that take as an input only parameters necessary to compose a table/aml part with occasional board interface hooks instead of all encompassing AcpiConfiguration and board specific '
acpi_build' that would use them when/if needed.
Let's take build_madt as an example. With my patch we define:
void build_madt(GArray *table_data, BIOSLinker *linker,
MachineState *ms, AcpiConfiguration *conf);
And you're suggesting we'd define:
void build_madt(GArray *table_data, BIOSLinker *linker,
MachineState *ms, HotplugHandler *acpi_dev, bool apic_xrupt_override);
instead. Is that correct?
Pros for the latter is the fact that, as you said, we would not need to define a centralized structure holding all possibly needed ACPI related fields.
Pros for the former is about defining a pointer to all needed ACPI fields once and for all and hiding the details of the API in the AML building implementation.
Quoted 3 lines
We probably should split series into several smaller (if possible independent) ones, so people won't be scared of its sheer size and run away from reviewing it.
I will try to split it in smaller chunks if that helps.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 01/24] hw: i386: Decouple the ACPI build from the PC machine type
Quoted 42 lines · On Wed, 21 Nov 2018 15:42:37 +0100 Samuel Ortiz <[email protected]> wrote:
Hi Igor,
Quoted 12 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:24 +0100 Samuel Ortiz <[email protected]> wrote:
ACPI tables are platform and machine type and even architecture agnostic, and as such we want to provide an internal ACPI API that only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently from the PC or Q35 machine types, we are moving a few MachineState structure fields into a machine type agnostic structure called AcpiConfiguration. The structure fields we move are:
Quoted 4 lines
It's not obvious why new structure is needed, especially at the beginning of series. We probably should place this patch much later in the series (if we need it at all) and try generalize a much as possible without using it.
Patches order set aside, this new structure is needed to make the existing API not completely bound to the pc machine type anymore and "Decouple the ACPI build from the PC machine type".
It was either creating a structure to build ACPI tables in a machine type independent fashion, or pass custom structures (or potentially long list of arguments) to the existing APIs. See below.
Quoted 9 lines
And try to come up with an API that doesn't need centralized collection of data somehow related to ACPI (most of the fields here are not generic and applicable to a specific board/target).
For generic API, I'd prefer a separate building blocks like build_fadt()/... that take as an input only parameters necessary to compose a table/aml part with occasional board interface hooks instead of all encompassing AcpiConfiguration and board specific '
acpi_build' that would use them when/if needed.Let's take
build_madtas an example. With my patch we define:void build_madt(GArray
*table_data, BIOSLinker *linker,MachineState *ms, AcpiConfiguration *conf);
Quoted 7 lines
And you're suggesting we'd define:
void build_madt(GArray
*table_data, BIOSLinker *linker,
MachineState *ms, HotplugHandler*acpi_dev, boolapic_xrupt_override);instead. Is that correct?
in general, yes
and let acpi_build() to fish out that info from board somehow.
In case of build_madt(), I doubt we can generalize it across targets. What we can do with it though, is to generalize entries that are placed into it. i.e. create helpers to create them instead of open-codding them like now, something like:
void build_append_madt_apic(*table, uid, apic_id, flags);
void build_append_madt_x2apic(*table, uid, apic_id, flags); void build_append_madt_ioapic(*table, io_apic_id, io_apic_addr, interrupt);
...
converting to build_append_int_noprefix() API ioapic entry example:
include/hw/acpi/acpi-defs.h +0 -10
@@ -242,16 +242,6 @@ struct AcpiMadtProcessorApic { }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;
include/hw/acpi/aml-build.h +3 -0
@@ -409,6 +409,9 @@ build_append_gas_from_struct(GArray *table, const struct AcpiGenericAddress *s) s->access_width, s->address); } +void build_append_madt_ioapic (GArray *tbl,uint8_t id,uint32_t addr, +uint32_t intr); +void build_srat_memory (AcpiSratMemoryAffinity *numamem,uint64_t base,uint64_t len,int node,MemoryAffinityFlags flags);
hw/acpi/aml-build.c +17 -0
@@ -1655,6 +1655,23 @@ void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base, }/* +* ACPI 1.0b: 5.2.8.2 IO APIC +<--- earliest spec where structure was introduced, that's the way +we avoid writing extra docs for things that are described in spec --> +*/ +void build_append_madt_ioapic (GArray *tbl,uint8_t id,uint32_t addr, +uint32_t intr) +{ +// comments are verbatim copy of the field name from spec +build_append_int_noprefix (tbl,1 /* I/O APIC structure */ ,1 );/* Type */ +build_append_int_noprefix (tbl,12 ,1 );/* Length */ +build_append_int_noprefix (tbl, id,1 );/* I/O APIC ID */ +build_append_int_noprefix (tbl,0 ,1 );/* Reserved */ +build_append_int_noprefix (tbl, addr,4 );/* I/O APIC Address */ +build_append_int_noprefix (tbl, intr,4 );/* Global System Interrupt Base */ +} + +/* * ACPI spec 5.2.17 System Locality Distance Information Table * (Revision 2.0 or later) */
hw/i386/acpi-build.c +2 -7
@@ -348,7 +348,6 @@ build_madt(GArray *table_data, BIOSLinker *linker, PCMachineState *pcms)bool x2apic_mode = false;AcpiMultipleApicTable *madt; -AcpiMadtIoApic *io_apic;AcpiMadtIntsrcovr *intsrcovr;int i;
@@ -363,12 +362,8 @@ build_madt(GArray *table_data, BIOSLinker *linker, PCMachineState *pcms) } } - io_apic =acpi_data_push (table_data,sizeof *io_apic); - io_apic->type =ACPI_APIC_IO ; - io_apic->length =sizeof (*io_apic); - io_apic->io_apic_id =ACPI_BUILD_IOAPIC_ID ; - io_apic->address =cpu_to_le32 (IO_APIC_DEFAULT_ADDRESS ); - io_apic->interrupt =cpu_to_le32 (0 ); +build_append_madt_ioapic (table_data, +ACPI_BUILD_IOAPIC_ID ,IO_APIC_DEFAULT_ADDRESS ,0 );if (pcms->apic_xrupt_override) { intsrcovr =acpi_data_push (table_data,sizeof *intsrcovr);
....
Then build_madt() is reduced to quite readable several lines only and if it makes sense having a custom board specific one, it is not an issue as there aren't much duplication.
In case of i386/virt, one probably can throw away all legacy stuff we have over there and have custom build_madt_virt().
Quoted 7 lines
Pros for the latter is the fact that, as you said, we would not need to define a centralized structure holding all possibly needed ACPI related fields.
Pros for the former is about defining a pointer to all needed ACPI fields once and for all and hiding the details of the API in the AML building implementation.
it's hard to create an maintain centralized structure for generic use, for example this series ended up with a bunch of x86 specific fields there and misplaced other fields that do not belong acpi but are used by it somehow. If one would thing about possible future refactorings, then it gets more difficult as changes to centralized structure affect whole codebase instead of being localized.
I suggest to keep board and acpi code as separate as possible and acpi_setup/acpi_build() being a glue that gets and feeds board/target specific data to an ACPI primitives/table builders. That way we would have a machine and in-depended acpi code, and custom glue that ties all together.
One would have to give up on generic acpi_build and AcpiBuilder callbacks, but acpi_build() is not a lot of code so it is not an issue to have several different ones (we can generalize parts of it is necessary).
Essentially this series would change from
----------pc.c:AcpiBuilder->build_a = pc_build_a; AcpiBuilder->build_b = pc_build_b;
...
virt_pc.c:AcpiBuilder->build_a = virt_pc_build_a;AcpiBuilder->build_b = virt_pc_build_b;
...
acpi...c:pc_acpi_build()
AcpiBuilder->build_a()
AcpiBuilder->build_b()
// some legacy hacks here
...virt_pc...c:virt_acpi_build()
AcpiBuilder->build_a()
AcpiBuilder->build_b()
...
... same for arm since set of tables is different and board/target depended ...
---------------acpi...c:pc_acpi_build()
pc_build_a()
pc_build_b()
...
virt_pc_..c:virt_acpi_build()
virt_pc_build_a()
virt_pc_build_b()
...
...
i.e. about the same as the former but without indirection and without headache how to generalize AcpiBuilder->build_foo() interface to work for every target/board.
Once we have hw/i386/acpi_reduced.c, working and used by i386/virt it would be easier to assess if we can generalize virt_pc_acpi_build() to be usable by arm, but right now it looks like premature action.
Quoted 7 lines
Quoted 3 lines
We probably should split series into several smaller (if possible independent) ones, so people won't be scared of its sheer size and run away from reviewing it.
I will try to split it in smaller chunks if that helps.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 2/24 hw: acpi: Export ACPI build alignment API
In reply to Samuel OrtizThis is going to be needed by the Hardware-reduced ACPI routines.
--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 8 ++++++++ hw/i386/acpi-build.c | 8 -------- 3 files changed, 10 insertions(+), 8 deletions(-)
include/hw/acpi/aml-build.h +2 -0
@@ -384,6 +384,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +/* Align AML blob size to a multiple of 'align' */ +void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre);
hw/acpi/aml-build.c +8 -0
@@ -1565,6 +1565,14 @@ unsigned acpi_data_len(GArray *table)return table->len; } +void acpi_align_size (GArray *blob,unsigned align) +{ +/* Align size to multiple of given size. This reduces the chance +* we need to change size in the future (breaking cross version migration). +*/ +g_array_set_size (blob,ROUND_UP (acpi_data_len (blob), align)); +} +void acpi_add_table (GArray *table_offsets,GArray *table_data) {uint32_t offset = table_data->len;
hw/i386/acpi-build.c +0 -8
@@ -282,14 +282,6 @@ static void acpi_get_pci_holes(Range *hole, Range *hole64) NULL)); } -static void acpi_align_size (GArray *blob,unsigned align) -{ -/* Align size to multiple of given size. This reduces the chance -* we need to change size in the future (breaking cross version migration). -*/ -g_array_set_size (blob,ROUND_UP (acpi_data_len (blob), align)); -} -/* FACS */ static void build_facs (GArray *table_data,BIOSLinker *linker)
Signature · 1 line
2.19.1
Re: [Qemu-arm] [PATCH v5 02/24] hw: acpi: Export ACPI build alignment API
Quoted 5 lines · On Mon, 5 Nov 2018 02:40:25 +0100 Samuel Ortiz <[email protected]> wrote:
This is going to be needed by the Hardware-reduced ACPI routines.
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>
the patch is probably misplaced withing series,
if there is an external user within this series then this patch should be squashed there, otherwise it doesn't belong to this series.
Quoted 47 lines
--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 8 ++++++++ hw/i386/acpi-build.c | 8 -------- 3 files changed, 10 insertions(+), 8 deletions(-)include/hw/acpi/aml-build.h +2
-0@@ -384,6 +384,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +/* Align AML blob size to a multiple of 'align' */ +void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre);hw/acpi/aml-build.c +8
-0@@ -1565,6 +1565,14 @@ unsigned acpi_data_len(GArray *table)return table->len; } +void acpi_align_size (GArray *blob,unsigned align) +{ +/* Align size to multiple of given size. This reduces the chance +* we need to change size in the future (breaking cross version migration). +*/ +g_array_set_size (blob,ROUND_UP (acpi_data_len (blob), align)); +} +void acpi_add_table (GArray *table_offsets,GArray *table_data) {uint32_t offset = table_data->len;hw/i386/acpi-build.c +0
-1@@ -282,14 +282,6 @@ static void acpi_get_pci_holes(Range *hole, Range *hole64) NULL)); } -static void acpi_align_size (GArray *blob,unsigned align)
hw/i386/acpi-build.c static void acpi_get_pci_holes(Range *hole, Range *hole64) · line 287
Quoted 10 lines
hw/i386/acpi-build.c +0
-7-{ -/* Align size to multiple of given size. This reduces the chance -* we need to change size in the future (breaking cross version migration). -*/ -g_array_set_size (blob,ROUND_UP (acpi_data_len (blob), align)); -} -/* FACS */ static void build_facs (GArray *table_data,BIOSLinker *linker)
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 02/24] hw: acpi: Export ACPI build alignment API
Quoted 11 lines · Igor Mammedov
Quoted 5 lines · On Mon, 5 Nov 2018 02:40:25 +0100 Samuel Ortiz <[email protected]> wrote:
This is going to be needed by the Hardware-reduced ACPI routines.
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>the patch is probably misplaced withing series,
if there is an external user within this series then this patch should be squashed there, otherwise it doesn't belong to this series.
hw/acpi/reduced.c needs it, I forgot to remove that patch when removing the hardware-reduced code from the serie. I will remove it.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 3/24 hw: acpi: The RSDP build API can return void
In reply to Samuel OrtizFor both x86 and ARM architectures, the internal RSDP build API can return void as the current return value is unused.
--- hw/arm/virt-acpi-build.c | 4 +--- hw/i386/acpi-build.c | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-)
hw/arm/virt-acpi-build.c +1 -3
@@ -367,7 +367,7 @@ static void acpi_dsdt_add_power_button(Aml *scope) }/* RSDP */ -static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
@@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; } static void
hw/i386/acpi-build.c +1 -3
@@ -2513,7 +2513,7 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned rsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
@@ -2535,8 +2535,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; }static bool acpi_get_mcfg (AcpiMcfgInfo *mcfg)
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void
Quoted 7 lines · Samuel Ortiz
/* RSDP */
hw/arm/virt-acpi-build.c +1
-1-static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
hw/arm/virt-acpi-build.c build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset) · line 396
Quoted 7 lines
hw/arm/virt-acpi-build.c +0
-2@@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; }
Better than v4. :)
Paolo
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void
Quoted 17 lines · Paolo Bonzini
Quoted 7 lines · Samuel Ortiz
/* RSDP */
hw/arm/virt-acpi-build.c +1
-1-static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);hw/arm/virt-acpi-build.c build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset) · line 396
Quoted 7 lines
hw/arm/virt-acpi-build.c +0
-2@@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; }Better than v4. :)
Right, I followed Philippe's advice and it does make things clearer :)
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void
In reply to Samuel OrtizQuoted 4 lines · On Mon, 5 Nov 2018 02:40:26 +0100 Samuel Ortiz <[email protected]> wrote:
For both x86 and ARM architectures, the internal RSDP build API can return void as the current return value is unused.
Signed-off-by Samuel Ortiz <[email protected]>
Quoted 41 lines
--- hw/arm/virt-acpi-build.c | 4 +--- hw/i386/acpi-build.c | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-)hw/arm/virt-acpi-build.c +1
-3@@ -367,7 +367,7 @@ static void acpi_dsdt_add_power_button(Aml *scope) }/* RSDP */ -static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);@@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; } static voidhw/i386/acpi-build.c +1
-1@@ -2513,7 +2513,7 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -static GArray * +static void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned rsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
hw/i386/acpi-build.c build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset) · line 2540
Quoted 8 lines
hw/i386/acpi-build.c +0
-2@@ -2535,8 +2535,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , (char *)rsdp - rsdp_table->data,sizeof *rsdp, (char *)&rsdp->checksum - rsdp_table->data); - -return rsdp_table; }static bool acpi_get_mcfg (AcpiMcfgInfo *mcfg)
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 4/24 hw: acpi: Export the RSDP build API
In reply to Samuel OrtizThe hardware-reduced API will need to build RSDP as well, so we should export this routine.
--- include/hw/acpi/aml-build.h | 3 +++ hw/arm/virt-acpi-build.c | 2 +- hw/i386/acpi-build.c | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-)
include/hw/acpi/aml-build.h +3 -0
@@ -390,6 +390,9 @@ void acpi_add_table(GArray *table_offsets, GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre);void +build_rsdp (GArray *table_data, +BIOSLinker *linker,unsigned rsdt_tbl_offset); +void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);void
hw/arm/virt-acpi-build.c +1 -1
@@ -367,7 +367,7 @@ static void acpi_dsdt_add_power_button(Aml *scope) }/* RSDP */ -static void +void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
hw/i386/acpi-build.c +1 -1
@@ -2513,7 +2513,7 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -static void +void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned rsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 5/24 hw: acpi: Implement XSDT support for RSDP
In reply to Samuel OrtizXSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
--- include/hw/acpi/aml-build.h | 3 +++ hw/acpi/aml-build.c | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)
include/hw/acpi/aml-build.h +3 -0
@@ -393,6 +393,9 @@ voidbuild_rsdp (GArray *table_data, BIOSLinker *linker, unsigned rsdt_tbl_offset);void +build_rsdp_xsdt (GArray *table_data, +BIOSLinker *linker,unsigned xsdt_tbl_offset); +void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);void
hw/acpi/aml-build.c +37 -0
@@ -1651,6 +1651,43 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id); } +/* RSDP pointing at an XSDT */ +void +build_rsdp_xsdt (GArray *rsdp_table, +BIOSLinker *linker,unsigned xsdt_tbl_offset) +{ +AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); +unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address); +unsigned xsdt_pa_offset = + (char *)&rsdp->xsdt_physical_address - rsdp_table->data; +unsigned xsdt_offset = + (char *)&rsdp->length - rsdp_table->data; + +bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , + true/* fseg memory */ ); + +memcpy (&rsdp->signature,"RSD PTR " ,8 ); +memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); + rsdp->length =cpu_to_le32 (sizeof (*rsdp)); +/* version 2, we will use the XSDT pointer */ + rsdp->revision =0x02 ; + +/* Address to be filled by Guest linker */ +bios_linker_loader_add_pointer (linker, +ACPI_BUILD_RSDP_FILE , xsdt_pa_offset, xsdt_pa_size, +ACPI_BUILD_TABLE_FILE , xsdt_tbl_offset); + +/* Legacy checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data, xsdt_offset, + (char *)&rsdp->checksum - rsdp_table->data); + +/* Extended checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data,sizeof *rsdp, + (char *)&rsdp->extended_checksum - rsdp_table->data); +} +void build_srat_memory (AcpiSratMemoryAffinity *numamem,uint64_t base,uint64_t len,int node,MemoryAffinityFlags flags) {
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug in virt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit 937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. to build_append_int_noprefix() API (commit 5d7a334f7)
... move out to aml-build.c
patch 5: reuse generalized arm's build_rsdp() for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commit dd1b2037a)
'make check V=1' shouldn't observe any ACPI tables changes after patch 2.
Quoted 58 lines
Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 3 +++ hw/acpi/aml-build.c | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)include/hw/acpi/aml-build.h +3
-0@@ -393,6 +393,9 @@ voidbuild_rsdp (GArray *table_data, BIOSLinker *linker, unsigned rsdt_tbl_offset);void +build_rsdp_xsdt (GArray *table_data, +BIOSLinker *linker,unsigned xsdt_tbl_offset); +void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);void hw/acpi/aml-build.c +30
-0@@ -1651,6 +1651,43 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id); } +/* RSDP pointing at an XSDT */ +void +build_rsdp_xsdt (GArray *rsdp_table, +BIOSLinker *linker,unsigned xsdt_tbl_offset) +{ +AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); +unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address); +unsigned xsdt_pa_offset = + (char *)&rsdp->xsdt_physical_address - rsdp_table->data; +unsigned xsdt_offset = + (char *)&rsdp->length - rsdp_table->data; + +bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , + true/* fseg memory */ ); + +memcpy (&rsdp->signature,"RSD PTR " ,8 ); +memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); + rsdp->length =cpu_to_le32 (sizeof (*rsdp)); +/* version 2, we will use the XSDT pointer */ + rsdp->revision =0x02 ; + +/* Address to be filled by Guest linker */ +bios_linker_loader_add_pointer (linker, +ACPI_BUILD_RSDP_FILE , xsdt_pa_offset, xsdt_pa_size, +ACPI_BUILD_TABLE_FILE , xsdt_tbl_offset); + +/* Legacy checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data, xsdt_offset, + (char *)&rsdp->checksum - rsdp_table->data);
hw/acpi/aml-build.c build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, · line 1693
Quoted 10 lines
hw/acpi/aml-build.c +7
-0+ +/* Extended checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data,sizeof *rsdp, + (char *)&rsdp->extended_checksum - rsdp_table->data); +} +void build_srat_memory (AcpiSratMemoryAffinity *numamem,uint64_t base,uint64_t len,int node,MemoryAffinityFlags flags) {
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
Hi Igor,
Quoted 12 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
Quoted 7 lines
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
I now see what you meant with the ACPI reference tables, thanks. I'll follow your advice.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
In reply to Igor MammedovOn Thu, 8 Nov 2018 15:16:23 +0100
Igor Mammedov <[email protected]> wrote:
[...]
Quoted 3 lines
patch 4: convert arm's impl. to
build_append_int_noprefix()API (commit5d7a334f7)... move out to
aml-build.c
my mistake, generally when we move something out,
we should do it in separate path preferably without any changes to the moved code so it would be easier to review. So it should be a separate patch.
[...]
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
In reply to Igor MammedovQuoted 27 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. tobuild_append_int_noprefix()API (commit5d7a334f7)
... move out toaml-build.c
patch 5: reuse generalized arm'sbuild_rsdp()for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commitdd1b2037a)
Quoted 1 line
'make check V=1' shouldn't observe any ACPI tables changes after patch 2.
And your next suggestion is to add patch 6. I guess it's doable but this will make a single patch a 6 patch series. At this rate this series will be at 200 patches easily.
Automated checks are cool but hey it's easy to see what changed in a disassembled table, and we do not update them blindly. So just note in the comment that there's a table change for ARM and expected files need to be updated and we should be fine IMHO.
Quoted 28 lines
Quoted 28 lines
Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 3 +++ hw/acpi/aml-build.c | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)include/hw/acpi/aml-build.h +3
-0@@ -393,6 +393,9 @@ voidbuild_rsdp (GArray *table_data, BIOSLinker *linker, unsigned rsdt_tbl_offset);void +build_rsdp_xsdt (GArray *table_data, +BIOSLinker *linker,unsigned xsdt_tbl_offset); +void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);void hw/acpi/aml-build.c +0
-0@@ -1651,6 +1651,43 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id); }
Quoted 11 lines
hw/acpi/aml-build.c build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, · line 1664
Quoted 11 lines
hw/acpi/aml-build.c +11
-0+/* RSDP pointing at an XSDT */ +void +build_rsdp_xsdt (GArray *rsdp_table, +BIOSLinker *linker,unsigned xsdt_tbl_offset) +{ +AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); +unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address); +unsigned xsdt_pa_offset = + (char *)&rsdp->xsdt_physical_address - rsdp_table->data; +unsigned xsdt_offset = + (char *)&rsdp->length - rsdp_table->data;
There's a cleaner way to get at the offsets than pointer math:
1. save rsdp_table length before you push
2. add offset_of for fields
If switching to build_append_int_noprefix then it's even easier - just save length before you append the int you intend to patch.
Quoted 21 lines
Quoted 21 lines
hw/acpi/aml-build.c +21
-0+ +bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , + true/* fseg memory */ ); + +memcpy (&rsdp->signature,"RSD PTR " ,8 ); +memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); + rsdp->length =cpu_to_le32 (sizeof (*rsdp)); +/* version 2, we will use the XSDT pointer */ + rsdp->revision =0x02 ; + +/* Address to be filled by Guest linker */ +bios_linker_loader_add_pointer (linker, +ACPI_BUILD_RSDP_FILE , xsdt_pa_offset, xsdt_pa_size, +ACPI_BUILD_TABLE_FILE , xsdt_tbl_offset); + +/* Legacy checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data, xsdt_offset, + (char *)&rsdp->checksum - rsdp_table->data); + +/* Extended checksum to be filled by Guest linker */
Quoted 8 lines
hw/acpi/aml-build.c build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, · line 1693
Quoted 8 lines
hw/acpi/aml-build.c +5
-0+bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data,sizeof *rsdp, + (char *)&rsdp->extended_checksum - rsdp_table->data); +} +void build_srat_memory (AcpiSratMemoryAffinity *numamem,uint64_t base,uint64_t len,int node,MemoryAffinityFlags flags) {
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
Quoted 30 lines · On Mon, 19 Nov 2018 13:27:14 -0500 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 27 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. tobuild_append_int_noprefix()API (commit5d7a334f7)
... move out toaml-build.c
patch 5: reuse generalized arm'sbuild_rsdp()for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commitdd1b2037a)Quoted 1 line
'make check V=1' shouldn't observe any ACPI tables changes after patch 2.
Quoted 8 lines
And your next suggestion is to add patch 6. I guess it's doable but this will make a single patch a 6 patch series. At this rate this series will be at 200 patches easily.
Automated checks are cool but hey it's easy to see what changed in a disassembled table, and we do not update them blindly. So just note in the comment that there's a table change for ARM and expected files need to be updated and we should be fine IMHO.
Point was to move patches that change tables content first, where we would pay extra attentions to changes in tables and then refactoring which shouldn't cause any changes will be mostly automatic (at least at that point we won't have to worry about tables correctness)
Quoted 70 lines
Quoted 28 lines
Quoted 28 lines
Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 3 +++ hw/acpi/aml-build.c | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)include/hw/acpi/aml-build.h +3
-0@@ -393,6 +393,9 @@ voidbuild_rsdp (GArray *table_data, BIOSLinker *linker, unsigned rsdt_tbl_offset);void +build_rsdp_xsdt (GArray *table_data, +BIOSLinker *linker,unsigned xsdt_tbl_offset); +void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);void hw/acpi/aml-build.c +0
-0@@ -1651,6 +1651,43 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id); }Quoted 11 lines
hw/acpi/aml-build.c build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, · line 1664
Quoted 11 lines
hw/acpi/aml-build.c +11
-0+/* RSDP pointing at an XSDT */ +void +build_rsdp_xsdt (GArray *rsdp_table, +BIOSLinker *linker,unsigned xsdt_tbl_offset) +{ +AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); +unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address); +unsigned xsdt_pa_offset = + (char *)&rsdp->xsdt_physical_address - rsdp_table->data; +unsigned xsdt_offset = + (char *)&rsdp->length - rsdp_table->data;There's a cleaner way to get at the offsets than pointer math:
1. saversdp_tablelength before you push
2. addoffset_offor fieldsIf switching to
build_append_int_noprefixthen it's even easier - just save length before you append the int you intend to patch.Quoted 21 lines
Quoted 21 lines
hw/acpi/aml-build.c +21
-0+ +bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , + true/* fseg memory */ ); + +memcpy (&rsdp->signature,"RSD PTR " ,8 ); +memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); + rsdp->length =cpu_to_le32 (sizeof (*rsdp)); +/* version 2, we will use the XSDT pointer */ + rsdp->revision =0x02 ; + +/* Address to be filled by Guest linker */ +bios_linker_loader_add_pointer (linker, +ACPI_BUILD_RSDP_FILE , xsdt_pa_offset, xsdt_pa_size, +ACPI_BUILD_TABLE_FILE , xsdt_tbl_offset); + +/* Legacy checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data, xsdt_offset, + (char *)&rsdp->checksum - rsdp_table->data); + +/* Extended checksum to be filled by Guest linker */
Quoted 8 lines
Quoted 8 lines
hw/acpi/aml-build.c build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, · line 1693
Quoted 8 lines
hw/acpi/aml-build.c +5
-0+bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data,sizeof *rsdp, + (char *)&rsdp->extended_checksum - rsdp_table->data); +} +void build_srat_memory (AcpiSratMemoryAffinity *numamem,uint64_t base,uint64_t len,int node,MemoryAffinityFlags flags) {
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
In reply to Igor MammedovHi Igor,
Quoted 23 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. tobuild_append_int_noprefix()API (commit5d7a334f7)
Quoted 4 lines
... move out to
aml-build.c
patch 5: reuse generalized arm'sbuild_rsdp()for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commitdd1b2037a)
I agree patches #1, #2 and #5 make sense. 3 and 4 as well, but here you're asking about something that's out of scope of the current serie. I'll move those patches from this serie and build a 6 patches new serie as suggested.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
Quoted 26 lines · On Wed, 21 Nov 2018 15:42:11 +0100 Samuel Ortiz <[email protected]> wrote:
Hi Igor,
Quoted 23 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. tobuild_append_int_noprefix()API (commit5d7a334f7)
Quoted 6 lines
Quoted 4 lines
... move out to
aml-build.c
patch 5: reuse generalized arm'sbuild_rsdp()for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commitdd1b2037a)I agree patches #1, #2 and #5 make sense. 3 and 4 as well, but here you're asking about something that's out of scope of the current serie.
/me guilty of that, but I have excuses for doing so:
* that's the only way to get rid of legacy approach given limited resources. So task goes to whomever touches old code. /others and me included/ I'd be glad if someone would volunteer and do clean ups but in absence of such, the victim is interested party.
* contributor to ACPI part learns how to use preferred approach, makes code more robust and clear as it's not possible to make endianness mistakes, very simple to review and notice mistakes as end result practically matches row by row a table described in spec.
* there could be exceptions, like acpi/nvdimm.c also contributed by Intel whole file written in legacy style (it probably started before I started enforcing conversions, anyways it's late now and should be done as whole), or odd fixes to existing tables, or too complex case. (depending on case I might still ask for conversion)
My ranting aside, conversions I've asked for here are trivial and for everyone's benefit /QEMU gets more maintainable code, users less bugs, contributor knows requirements hence his patches go through less iterations, hopefully if contributor stays around and does contributions/reviews to acpi code, QEMU could get another co-maintainer for acpi part/
Quoted 2 lines
I'll move those patches from this serie and build a 6 patches new serie as suggested.
Thanks!
Quoted 4 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 05/24] hw: acpi: Implement XSDT support for RSDP
Quoted 35 lines · Igor Mammedov
Quoted 26 lines · On Wed, 21 Nov 2018 15:42:11 +0100 Samuel Ortiz <[email protected]> wrote:
Hi Igor,
Quoted 23 lines · Igor Mammedov
Quoted 8 lines · On Mon, 5 Nov 2018 02:40:28 +0100 Samuel Ortiz <[email protected]> wrote:
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System Description Table). RSDT only allow for 32-bit addressses and have thus been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and no longer RSDTs, although RSDTs are still supported for backward compatibility.
Since version 2.0, RSDPs should add an extended checksum, a complete table length and a version field to the table.
This patch re-implements what arm/virt board already does and fixes checksum bug in the later and at the same time without a user (within the patch).
I'd suggest redo it a way similar to FADT refactoring
patch 1: fix checksum bug invirt/arm
patch 2: update reference tables in test
patch 3: introduce AcpiRsdpData similar to commit937d1b587
(both arm and x86) wich stores all data in hos byte order
patch 4: convert arm's impl. tobuild_append_int_noprefix()API (commit5d7a334f7)Quoted 6 lines
Quoted 4 lines
... move out to
aml-build.c
patch 5: reuse generalized arm'sbuild_rsdp()for x86, dropping x86 specific one
amending it to generate rev1 variant defined by revision in AcpiRsdpData (commitdd1b2037a)I agree patches #1, #2 and #5 make sense. 3 and 4 as well, but here you're asking about something that's out of scope of the current serie.
Quoted 9 lines
/me guilty of that, but I have excuses for doing so:
* that's the only way to get rid of legacy approach given limited resources. So task goes to whomever touches old code. /others and me included/ I'd be glad if someone would volunteer and do clean ups but in absence of such, the victim is interested party.
* contributor to ACPI part learns how to use preferred approach, makes code more robust and clear as it's not possible to make endianness mistakes, very simple to review and notice mistakes as end result practically matches row by row a table described in spec.
I understand and agree with that. And to be clear: I'm happy to contribute and work on that. But I'm also lucky to have an employer that can afford to let me spend as much time as needed to do this kind of refactoring/modernizing work. I just want to point out that other potential newcomers to the project may not have that luxury. I wonder (I sincerely do, I'm not making any assumptions) how much code is left unmerged because the original submitter did not have the time or budget to polish it up to the expected level.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 6/24 hw: acpi: Factorize the RSDP build API implementation
In reply to Samuel OrtizWe can now share the RSDP build between the ARM and x86 architectures. Here we make the default RSDP build use XSDT and keep the existing x86 ACPI build implementation using the legacy RSDT version.
--- include/hw/acpi/aml-build.h | 8 ++++---- hw/acpi/aml-build.c | 28 +++++++++++++++++++++++++--- hw/arm/virt-acpi-build.c | 28 ---------------------------- hw/i386/acpi-build.c | 26 +------------------------- 4 files changed, 30 insertions(+), 60 deletions(-)
include/hw/acpi/aml-build.h +4 -4
@@ -390,11 +390,11 @@ void acpi_add_table(GArray *table_offsets, GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre);void -build_rsdp (GArray *table_data, -BIOSLinker *linker,unsigned rsdt_tbl_offset); +build_rsdp_rsdt (GArray *table_data, +BIOSLinker *linker,unsigned rsdt_tbl_offset);void -build_rsdp_xsdt (GArray *table_data, -BIOSLinker *linker,unsigned xsdt_tbl_offset); +build_rsdp (GArray *table_data, +BIOSLinker *linker,unsigned xsdt_tbl_offset);void build_rsdt (GArray *table_data,BIOSLinker *linker,GArray *table_offsets,const char *oem_id,const char *oem_table_id);
hw/acpi/aml-build.c +25 -3
@@ -1651,10 +1651,32 @@ build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets, (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id); } +/* Legacy RSDP pointing at an RSDT. This is deprecated */ +void build_rsdp_rsdt (GArray *rsdp_table,BIOSLinker *linker,unsigned rsdt_tbl_offset) +{ +AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); +unsigned rsdt_pa_size =sizeof (rsdp->rsdt_physical_address); +unsigned rsdt_pa_offset = + (char *)&rsdp->rsdt_physical_address - rsdp_table->data; + +bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , + true/* fseg memory */ ); + +memcpy (&rsdp->signature,"RSD PTR " ,8 ); +memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); +/* Address to be filled by Guest linker */ +bios_linker_loader_add_pointer (linker, +ACPI_BUILD_RSDP_FILE , rsdt_pa_offset, rsdt_pa_size, +ACPI_BUILD_TABLE_FILE , rsdt_tbl_offset); + +/* Checksum to be filled by Guest linker */ +bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , + (char *)rsdp - rsdp_table->data,sizeof *rsdp, + (char *)&rsdp->checksum - rsdp_table->data); +} +/* RSDP pointing at an XSDT */ -void -build_rsdp_xsdt (GArray *rsdp_table, -BIOSLinker *linker,unsigned xsdt_tbl_offset) +void build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) {AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp);unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address);
hw/arm/virt-acpi-build.c +0 -28
@@ -366,34 +366,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)aml_append (scope, dev); } -/* RSDP */ -void -build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned xsdt_tbl_offset) -{ -AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); -unsigned xsdt_pa_size =sizeof (rsdp->xsdt_physical_address); -unsigned xsdt_pa_offset = - (char *)&rsdp->xsdt_physical_address - rsdp_table->data; - -bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , - true/* fseg memory */ ); - -memcpy (&rsdp->signature,"RSD PTR " ,sizeof (rsdp->signature)); -memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,sizeof (rsdp->oem_id)); - rsdp->length =cpu_to_le32 (sizeof (*rsdp)); - rsdp->revision =0x02 ; - -/* Address to be filled by Guest linker */ -bios_linker_loader_add_pointer (linker, -ACPI_BUILD_RSDP_FILE , xsdt_pa_offset, xsdt_pa_size, -ACPI_BUILD_TABLE_FILE , xsdt_tbl_offset); - -/* Checksum to be filled by Guest linker */ -bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , - (char *)rsdp - rsdp_table->data,sizeof *rsdp, - (char *)&rsdp->checksum - rsdp_table->data); -} -static void build_iort (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {
hw/i386/acpi-build.c +1 -25
@@ -2513,30 +2513,6 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -void -build_rsdp (GArray *rsdp_table,BIOSLinker *linker,unsigned rsdt_tbl_offset) -{ -AcpiRsdpDescriptor *rsdp =acpi_data_push (rsdp_table,sizeof *rsdp); -unsigned rsdt_pa_size =sizeof (rsdp->rsdt_physical_address); -unsigned rsdt_pa_offset = - (char *)&rsdp->rsdt_physical_address - rsdp_table->data; - -bios_linker_loader_alloc (linker,ACPI_BUILD_RSDP_FILE , rsdp_table,16 , - true/* fseg memory */ ); - -memcpy (&rsdp->signature,"RSD PTR " ,8 ); -memcpy (rsdp->oem_id,ACPI_BUILD_APPNAME6 ,6 ); -/* Address to be filled by Guest linker */ -bios_linker_loader_add_pointer (linker, -ACPI_BUILD_RSDP_FILE , rsdt_pa_offset, rsdt_pa_size, -ACPI_BUILD_TABLE_FILE , rsdt_tbl_offset); - -/* Checksum to be filled by Guest linker */ -bios_linker_loader_add_checksum (linker,ACPI_BUILD_RSDP_FILE , - (char *)rsdp - rsdp_table->data,sizeof *rsdp, - (char *)&rsdp->checksum - rsdp_table->data); -} -static bool acpi_get_mcfg (AcpiMcfgInfo *mcfg) {Object *pci_host;
@@ -2681,7 +2657,7 @@ void acpi_build(AcpiBuildTables *tables, slic_oem.id, slic_oem.table_id);/* RSDP is in FSEG memory, so allocate it separately */ -build_rsdp (tables->rsdp, tables->linker, rsdt); +build_rsdp_rsdt (tables->rsdp, tables->linker, rsdt);/* We'll expose it all to Guest so we want to reduce * chance of size changes.
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 7/24 hw: acpi: Generalize AML build routines
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
Most of the AML build routines under acpi-build are not even architecture specific. They can be moved to the more generic hw/acpi folder where they could be shared across machine types and architectures.
--- include/hw/acpi/aml-build.h | 25 ++ hw/acpi/aml-build.c | 498 ++++++++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 +- hw/i386/acpi-build.c | 518 +----------------------------------- 4 files changed, 528 insertions(+), 517 deletions(-)
include/hw/acpi/aml-build.h +25 -0
@@ -3,6 +3,7 @@#include "hw/acpi/acpi-defs.h" #include "hw/acpi/bios-linker-loader.h" +#include "hw/pci/pcie_host.h" /* Reserve RAM space for tables: add another order of magnitude. */ #define ACPI_BUILD_TABLE_MAX_SIZE 0x200000
@@ -223,6 +224,21 @@ struct AcpiBuildTables {BIOSLinker *linker; } AcpiBuildTables; +typedef struct AcpiMcfgInfo { +uint64_t mcfg_base; +uint32_t mcfg_size; +}AcpiMcfgInfo ; + +typedef struct CrsRangeEntry { +uint64_t base; +uint64_t limit; +}CrsRangeEntry ; + +typedef struct CrsRangeSet { +GPtrArray *io_ranges; +GPtrArray *mem_ranges; +GPtrArray *mem_64bit_ranges; +}CrsRangeSet ;/** * init_aml_allocator: *
@@ -389,6 +405,15 @@ void acpi_align_size(GArray *blob, unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre); +Aml *build_osc_method (void ); +void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info); +Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi); +Aml *build_prt (bool is_pci0_prt); +void crs_range_set_init (CrsRangeSet *range_set); +Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); +void crs_replace_with_free_ranges (GPtrArray *ranges, +uint64_t start,uint64_t end); +void crs_range_set_free (CrsRangeSet *range_set);void build_rsdp_rsdt (GArray *table_data,BIOSLinker *linker,unsigned rsdt_tbl_offset);
hw/acpi/aml-build.c +498 -0
510 lines not on this page · raw message
hw/arm/virt-acpi-build.c +2 -2
@@ -545,7 +545,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) }static void -build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {AcpiTableMcfg *mcfg;const MemMapEntry *memmap = vms->memmap;
@@ -790,7 +790,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)build_gtdt (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob); -build_mcfg (tables_blob, tables->linker, vms); +virt_build_mcfg (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob);build_spcr (tables_blob, tables->linker, vms);
hw/i386/acpi-build.c +3 -515
578 lines not on this page · raw message
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [PATCH v5 07/24] hw: acpi: Generalize AML build routines
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:30 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
Most of the AML build routines under acpi-build are not even architecture specific. They can be moved to the more generic hw/acpi folder where they could be shared across machine types and architectures.
I'd prefer if won't pull into aml-build PCI specific headers, Suggest to create hw/acpi/pci.c and move generic PCI related code there, with corresponding header the would export API (preferably without PCI dependencies in it)
Also patch is too big and does too much at a time.
Here I'd suggest to split it in smaller parts to make it more digestible
1. split it in 3 parts
* MCFG
* CRS
* PTR
2. mcfg between x86 and ARM look pretty much the same with ARM
open codding bus number calculation and missing migration hack
* a patch to make bus number calculation in ARM the same as x86
* a patch to bring migration hack (dummy MCFG table in case it's disabled) it's questionable if we actually need it in generic,
we most likely need it for legacy machines that predate
resizable MemeoryRegion, but we probably don't need it for
later machines as problem doesn't exists there.
So it might be better to push hack out from generic code
to a legacy caller and keep generic MCFG clean.
(this patch might be better at the beginning of the series as
it might affect acpi test results, and might need an update to reference tables I don't really sure)
* at this point arm and x86 impl. would be the same so
a patch to move mcfg build routine to a generic place and replace x86/arm with a single impl.
* a patch to convert mcfg build routine to build_append_int_noprefix() API and drop AcpiTableMcfg structure
Quoted 32 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Yang Zhong <[email protected]>--- include/hw/acpi/aml-build.h | 25 ++ hw/acpi/aml-build.c | 498 ++++++++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 +- hw/i386/acpi-build.c | 518 +----------------------------------- 4 files changed, 528 insertions(+), 517 deletions(-)include/hw/acpi/aml-build.h +7
-0@@ -3,6 +3,7 @@#include "hw/acpi/acpi-defs.h" #include "hw/acpi/bios-linker-loader.h" +#include "hw/pci/pcie_host.h" /* Reserve RAM space for tables: add another order of magnitude. */ #define ACPI_BUILD_TABLE_MAX_SIZE 0x200000@@ -223,6 +224,21 @@ struct AcpiBuildTables {BIOSLinker *linker; } AcpiBuildTables; +typedef struct AcpiMcfgInfo { +uint64_t mcfg_base; +uint32_t mcfg_size; +}AcpiMcfgInfo ; + +typedef struct CrsRangeEntry {
include/hw/acpi/aml-build.h struct AcpiBuildTables { · line 242
Quoted 10 lines
include/hw/acpi/aml-build.h +9
-0+uint64_t base; +uint64_t limit; +} CrsRangeEntry; + +typedef struct CrsRangeSet { +GPtrArray *io_ranges; +GPtrArray *mem_ranges; +GPtrArray *mem_64bit_ranges; +}CrsRangeSet ;/**
I'd prefer not to put these into aml-build.h, it's supposed to host ACPI spec primitives mostly so I'd suggest to move these to acpi-defs.h or PCI specific acpi header
Quoted 1,140 lines
include/hw/acpi/aml-build.h +9
-0* init_aml_allocator: * @@ -389,6 +405,15 @@ void acpi_align_size(GArray *blob, unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre); +Aml *build_osc_method (void ); +void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info); +Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi); +Aml *build_prt (bool is_pci0_prt); +void crs_range_set_init (CrsRangeSet *range_set); +Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); +void crs_replace_with_free_ranges (GPtrArray *ranges, +uint64_t start,uint64_t end); +void crs_range_set_free (CrsRangeSet *range_set);void build_rsdp_rsdt (GArray *table_data,BIOSLinker *linker,unsigned rsdt_tbl_offset);hw/acpi/aml-build.c +498
-0@@ -25,6 +25,10 @@#include "qemu/bswap.h" #include "qemu/bitops.h" #include "sysemu/numa.h" +#include "hw/pci/pci.h" +#include "hw/pci/pci_bus.h" +#include "qemu/range.h" +#include "hw/pci/pci_bridge.h" static GArray *build_alloc_array (void ) {@@ -1597,6 +1601,500 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } +static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) +{ +CrsRangeEntry *entry; + + entry =g_malloc (sizeof (*entry)); + entry->base = base; + entry->limit = limit; + +g_ptr_array_add (ranges, entry); +} + +static void crs_range_free (gpointer data) +{ +CrsRangeEntry *entry = (CrsRangeEntry *)data; +g_free (entry); +} + +void crs_range_set_init (CrsRangeSet *range_set) +{ + range_set->io_ranges =g_ptr_array_new_with_free_func (crs_range_free); + range_set->mem_ranges =g_ptr_array_new_with_free_func (crs_range_free); + range_set->mem_64bit_ranges = +g_ptr_array_new_with_free_func (crs_range_free); +} + +void crs_range_set_free (CrsRangeSet *range_set) +{ +g_ptr_array_free (range_set->io_ranges, true); +g_ptr_array_free (range_set->mem_ranges, true); +g_ptr_array_free (range_set->mem_64bit_ranges, true); +} + +static gint crs_range_compare (gconstpointer a,gconstpointer b) +{ +CrsRangeEntry *entry_a = *(CrsRangeEntry **)a; +CrsRangeEntry *entry_b = *(CrsRangeEntry **)b; + +return (int64_t )entry_a->base - (int64_t )entry_b->base; +} + +/* +* crs_replace_with_free_ranges - given the 'used' ranges within [start - end] +* interval, computes the 'free' ranges from the same interval. +* Example: If the input array is { [a1 - a2],[b1 - b2] }, the function +* will return { [base - a1], [a2 - b1], [b2 - limit] }. +*/ +void crs_replace_with_free_ranges (GPtrArray *ranges, +uint64_t start,uint64_t end) +{ +GPtrArray *free_ranges =g_ptr_array_new (); +uint64_t free_base = start; +int i; + +g_ptr_array_sort (ranges, crs_range_compare); +for (i =0 ; i < ranges->len; i++) { +CrsRangeEntry *used =g_ptr_array_index (ranges, i); + +if (free_base < used->base) { +crs_range_insert (free_ranges, free_base, used->base -1 ); + } + + free_base = used->limit +1 ; + } + +if (free_base < end) { +crs_range_insert (free_ranges, free_base, end); + } + +g_ptr_array_set_size (ranges,0 ); +for (i =0 ; i < free_ranges->len; i++) { +g_ptr_array_add (ranges,g_ptr_array_index (free_ranges, i)); + } + +g_ptr_array_free (free_ranges, true); +} + +/* +* crs_range_merge - merges adjacent ranges in the given array. +* Array elements are deleted and replaced with the merged ranges. +*/ +static void crs_range_merge (GPtrArray *range) +{ +GPtrArray *tmp =g_ptr_array_new_with_free_func (crs_range_free); +CrsRangeEntry *entry; +uint64_t range_base, range_limit; +int i; + +if (!range->len) { +return ; + } + +g_ptr_array_sort (range, crs_range_compare); + + entry =g_ptr_array_index (range,0 ); + range_base = entry->base; + range_limit = entry->limit; +for (i =1 ; i < range->len; i++) { + entry =g_ptr_array_index (range, i); +if (entry->base -1 == range_limit) { + range_limit = entry->limit; + }else { +crs_range_insert (tmp, range_base, range_limit); + range_base = entry->base; + range_limit = entry->limit; + } + } +crs_range_insert (tmp, range_base, range_limit); + +g_ptr_array_set_size (range,0 ); +for (i =0 ; i < tmp->len; i++) { + entry =g_ptr_array_index (tmp, i); +crs_range_insert (range, entry->base, entry->limit); + } +g_ptr_array_free (tmp, true); +} + +Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set) +{ +Aml *crs =aml_resource_template (); +CrsRangeSet temp_range_set; +CrsRangeEntry *entry; +uint8_t max_bus =pci_bus_num (host->bus); +uint8_t type; +int devfn; +int i; + +crs_range_set_init (&temp_range_set); +for (devfn =0 ; devfn <ARRAY_SIZE (host->bus->devices); devfn++) { +uint64_t range_base, range_limit; +PCIDevice *dev = host->bus->devices[devfn]; + +if (!dev) { +continue ; + } + +for (i =0 ; i <PCI_NUM_REGIONS ; i++) { +PCIIORegion *r = &dev->io_regions[i]; + + range_base = r->addr; + range_limit = r->addr + r->size -1 ; + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (!range_base || range_base > range_limit) { +continue ; + } + +if (r->type &PCI_BASE_ADDRESS_SPACE_IO ) { +crs_range_insert (temp_range_set.io_ranges, + range_base, range_limit); + }else {/* "memory" */ +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + } + } + + type = dev->config[PCI_HEADER_TYPE ] & ~PCI_HEADER_TYPE_MULTI_FUNCTION ; +if (type ==PCI_HEADER_TYPE_BRIDGE ) { +uint8_t subordinate = dev->config[PCI_SUBORDINATE_BUS ]; +if (subordinate > max_bus) { + max_bus = subordinate; + } + + range_base =pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_IO ); + range_limit =pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_IO ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +crs_range_insert (temp_range_set.io_ranges, + range_base, range_limit); + } + + range_base = +pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); + range_limit = +pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +uint64_t length = range_limit - range_base +1 ; +if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + }else { +crs_range_insert (temp_range_set.mem_64bit_ranges, + range_base, range_limit); + } + } + + range_base = +pci_bridge_get_base (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); + range_limit = +pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +uint64_t length = range_limit - range_base +1 ; +if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + }else { +crs_range_insert (temp_range_set.mem_64bit_ranges, + range_base, range_limit); + } + } + } + } + +crs_range_merge (temp_range_set.io_ranges); +for (i =0 ; i < temp_range_set.io_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.io_ranges, i); +aml_append (crs, +aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , +AML_POS_DECODE ,AML_ENTIRE_RANGE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->io_ranges, entry->base, entry->limit); + } + +crs_range_merge (temp_range_set.mem_ranges); +for (i =0 ; i < temp_range_set.mem_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.mem_ranges, i); +aml_append (crs, +aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED , +AML_MAX_FIXED ,AML_NON_CACHEABLE , +AML_READ_WRITE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->mem_ranges, entry->base, entry->limit); + } + +crs_range_merge (temp_range_set.mem_64bit_ranges); +for (i =0 ; i < temp_range_set.mem_64bit_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.mem_64bit_ranges, i); +aml_append (crs, +aml_qword_memory (AML_POS_DECODE ,AML_MIN_FIXED , +AML_MAX_FIXED ,AML_NON_CACHEABLE , +AML_READ_WRITE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->mem_64bit_ranges, + entry->base, entry->limit); + } + +crs_range_set_free (&temp_range_set); + +aml_append (crs, +aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , +0 , +pci_bus_num (host->bus), + max_bus, +0 , + max_bus -pci_bus_num (host->bus) +1 )); + +return crs; +} + +Aml *build_osc_method (void ) +{ +Aml *if_ctx; +Aml *if_ctx2; +Aml *else_ctx; +Aml *method; +Aml *a_cwd1 =aml_name ("CDW1" ); +Aml *a_ctrl =aml_local (0 ); + + method =aml_method ("_OSC" ,4 ,AML_NOTSERIALIZED ); +aml_append (method,aml_create_dword_field (aml_arg (3 ),aml_int (0 ),"CDW1" )); + + if_ctx =aml_if (aml_equal ( +aml_arg (0 ),aml_touuid ("33DB4D5B-1FF7-401C-9657-7441C03DD766" ))); +aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (4 ),"CDW2" )); +aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (8 ),"CDW3" )); + +aml_append (if_ctx,aml_store (aml_name ("CDW3" ), a_ctrl)); + +/* +* Always allow native PME, AER (no dependencies) +* Allow SHPC (PCI bridges can have SHPC controller) +*/ +aml_append (if_ctx,aml_and (a_ctrl,aml_int (0x1F ), a_ctrl)); + + if_ctx2 =aml_if (aml_lnot (aml_equal (aml_arg (1 ),aml_int (1 )))); +/* Unknown revision */ +aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x08 ), a_cwd1)); +aml_append (if_ctx, if_ctx2); + + if_ctx2 =aml_if (aml_lnot (aml_equal (aml_name ("CDW3" ), a_ctrl))); +/* Capabilities bits were masked */ +aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x10 ), a_cwd1)); +aml_append (if_ctx, if_ctx2); + +/* Update DWORD3 in the buffer */ +aml_append (if_ctx,aml_store (a_ctrl,aml_name ("CDW3" ))); +aml_append (method, if_ctx); + + else_ctx =aml_else (); +/* Unrecognized UUID */ +aml_append (else_ctx,aml_or (a_cwd1,aml_int (4 ), a_cwd1)); +aml_append (method, else_ctx); + +aml_append (method,aml_return (aml_arg (3 ))); +return method; +} + +void +build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info) +{ +AcpiTableMcfg *mcfg; +const char *sig; +int len =sizeof (*mcfg) +1 *sizeof (mcfg->allocation[0 ]); + + mcfg =acpi_data_push (table_data, len); + mcfg->allocation[0 ].address =cpu_to_le64 (info->mcfg_base); +/* Only a single allocation so no need to play with segments */ + mcfg->allocation[0 ].pci_segment =cpu_to_le16 (0 ); + mcfg->allocation[0 ].start_bus_number =0 ; + mcfg->allocation[0 ].end_bus_number =PCIE_MMCFG_BUS (info->mcfg_size -1 ); + +/* MCFG is used for ECAM which can be enabled or disabled by guest. +* To avoid table size changes (which create migration issues), +* always create the table even if there are no allocations, +* but set the signature to a reserved value in this case. +* ACPI spec requires OSPMs to ignore such tables. +*/ +if (info->mcfg_base ==PCIE_BASE_ADDR_UNMAPPED ) { +/* Reserved signature: ignored by OSPM */ + sig ="QEMU" ; + }else { + sig ="MCFG" ; + } +build_header (linker, table_data, (void *)mcfg, sig, len,1 ,NULL ,NULL ); +} + +Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi) +{ +Aml *dev; +Aml *crs; +Aml *method; +uint32_t irqs; + + dev =aml_device ("%s" , name); +aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0C0F" ))); +aml_append (dev,aml_name_decl ("_UID" ,aml_int (uid))); + + crs =aml_resource_template (); + irqs = gsi; +aml_append (crs,aml_interrupt (AML_CONSUMER ,AML_LEVEL ,AML_ACTIVE_HIGH , +AML_SHARED , &irqs,1 )); +aml_append (dev,aml_name_decl ("_PRS" , crs)); + +aml_append (dev,aml_name_decl ("_CRS" , crs)); + +/* +* _DIS can be no-op because the interrupt cannot be disabled. +*/ + method =aml_method ("_DIS" ,0 ,AML_NOTSERIALIZED ); +aml_append (dev, method); + + method =aml_method ("_SRS" ,1 ,AML_NOTSERIALIZED ); +aml_append (dev, method); + +return dev; +} + +/** +* build_prt_entry: +* @link_name: link name for PCI route entry +* +* build AML package containing a PCI route entry for @link_name +*/ +static Aml *build_prt_entry (const char *link_name) +{ +Aml *a_zero =aml_int (0 ); +Aml *pkg =aml_package (4 ); +aml_append (pkg, a_zero); +aml_append (pkg, a_zero); +aml_append (pkg,aml_name ("%s" , link_name)); +aml_append (pkg, a_zero); +return pkg; +} + +/* +* initialize_route - Initialize the interrupt routing rule +* through a specific LINK: +* if (lnk_idx == idx) +* route using link 'link_name' +*/ +static Aml *initialize_route (Aml *route,const char *link_name, +Aml *lnk_idx,int idx) +{ +Aml *if_ctx =aml_if (aml_equal (lnk_idx,aml_int (idx))); +Aml *pkg =build_prt_entry (link_name); + +aml_append (if_ctx,aml_store (pkg, route)); + +return if_ctx; +} + +/* +* build_prt - Define interrupt rounting rules +* +* Returns an array of 128 routes, one for each device, +* based on device location. +* The main goal is to equaly distribute the interrupts +* over the 4 existing ACPI links (works only for i440fx). +* The hash function is (slot + pin) & 3 -> "LNK[D|A|B|C]". +* +*/ +Aml *build_prt (bool is_pci0_prt) +{ +Aml *method, *while_ctx, *pin, *res; + + method =aml_method ("_PRT" ,0 ,AML_NOTSERIALIZED ); + res =aml_local (0 ); + pin =aml_local (1 ); +aml_append (method,aml_store (aml_package (128 ), res)); +aml_append (method,aml_store (aml_int (0 ), pin)); + +/* while (pin < 128) */ + while_ctx =aml_while (aml_lless (pin,aml_int (128 ))); + { +Aml *slot =aml_local (2 ); +Aml *lnk_idx =aml_local (3 ); +Aml *route =aml_local (4 ); + +/* slot = pin >> 2 */ +aml_append (while_ctx, +aml_store (aml_shiftright (pin,aml_int (2 ),NULL ), slot)); +/* lnk_idx = (slot + pin) & 3 */ +aml_append (while_ctx, +aml_store (aml_and (aml_add (pin, slot,NULL ),aml_int (3 ),NULL ), + lnk_idx)); + +/* route[2] = "LNK[D|A|B|C]", selection based on pin % 3 */ +aml_append (while_ctx,initialize_route (route,"LNKD" , lnk_idx,0 )); +if (is_pci0_prt) { +Aml *if_device_1, *if_pin_4, *else_pin_4; + +/* device 1 is the power-management device, needs SCI */ + if_device_1 =aml_if (aml_equal (lnk_idx,aml_int (1 ))); + { + if_pin_4 =aml_if (aml_equal (pin,aml_int (4 ))); + { +aml_append (if_pin_4, +aml_store (build_prt_entry ("LNKS" ), route)); + } +aml_append (if_device_1, if_pin_4); + else_pin_4 =aml_else (); + { +aml_append (else_pin_4, +aml_store (build_prt_entry ("LNKA" ), route)); + } +aml_append (if_device_1, else_pin_4); + } +aml_append (while_ctx, if_device_1); + }else { +aml_append (while_ctx,initialize_route (route,"LNKA" , lnk_idx,1 )); + } +aml_append (while_ctx,initialize_route (route,"LNKB" , lnk_idx,2 )); +aml_append (while_ctx,initialize_route (route,"LNKC" , lnk_idx,3 )); + +/* route[0] = 0x[slot]FFFF */ +aml_append (while_ctx, +aml_store (aml_or (aml_shiftleft (slot,aml_int (16 )),aml_int (0xFFFF ), +NULL ), +aml_index (route,aml_int (0 )))); +/* route[1] = pin & 3 */ +aml_append (while_ctx, +aml_store (aml_and (pin,aml_int (3 ),NULL ), +aml_index (route,aml_int (1 )))); +/* res[pin] = route */ +aml_append (while_ctx,aml_store (route,aml_index (res, pin))); +/* pin++ */ +aml_append (while_ctx,aml_increment (pin)); + } +aml_append (method, while_ctx); +/* return res*/ +aml_append (method,aml_return (res)); + +return method; +} +/* Build rsdt table */ void build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,hw/arm/virt-acpi-build.c +2
-2@@ -545,7 +545,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) }static void -build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {AcpiTableMcfg *mcfg;const MemMapEntry *memmap = vms->memmap;@@ -790,7 +790,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)build_gtdt (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob); -build_mcfg (tables_blob, tables->linker, vms); +virt_build_mcfg (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob);build_spcr (tables_blob, tables->linker, vms);hw/i386/acpi-build.c +2
-514@@ -27,7 +27,6 @@#include "qemu-common.h" #include "qemu/bitmap.h" #include "qemu/error-report.h" -#include "hw/pci/pci.h" #include "qom/cpu.h" #include "target/i386/cpu.h" #include "hw/misc/pvpanic.h" @@ -53,7 +52,6 @@#include "hw/acpi/piix4.h" #include "hw/acpi/pcihp.h" #include "hw/i386/ich9.h" -#include "hw/pci/pci_bus.h" #include "hw/pci-host/q35.h" #include "hw/i386/x86-iommu.h" @@ -86,11 +84,6 @@/* Default IOAPIC ID */ #define ACPI_BUILD_IOAPIC_ID 0x0 -typedef struct AcpiMcfgInfo { -uint64_t mcfg_base; -uint32_t mcfg_size; -}AcpiMcfgInfo ; - typedef struct AcpiPmInfo { bool s3_disabled; bool s4_disabled;@@ -567,403 +560,6 @@ static void build_append_pci_bus_devices(Aml *parent_scope, PCIBus *bus,qobject_unref (bsel); } -/** -* build_prt_entry: -* @link_name: link name for PCI route entry -* -* build AML package containing a PCI route entry for @link_name -*/ -static Aml *build_prt_entry (const char *link_name) -{ -Aml *a_zero =aml_int (0 ); -Aml *pkg =aml_package (4 ); -aml_append (pkg, a_zero); -aml_append (pkg, a_zero); -aml_append (pkg,aml_name ("%s" , link_name)); -aml_append (pkg, a_zero); -return pkg; -} - -/* -* initialize_route - Initialize the interrupt routing rule -* through a specific LINK: -* if (lnk_idx == idx) -* route using link 'link_name' -*/ -static Aml *initialize_route (Aml *route,const char *link_name, -Aml *lnk_idx,int idx) -{ -Aml *if_ctx =aml_if (aml_equal (lnk_idx,aml_int (idx))); -Aml *pkg =build_prt_entry (link_name); - -aml_append (if_ctx,aml_store (pkg, route)); - -return if_ctx; -} - -/* -* build_prt - Define interrupt rounting rules -* -* Returns an array of 128 routes, one for each device, -* based on device location. -* The main goal is to equaly distribute the interrupts -* over the 4 existing ACPI links (works only for i440fx). -* The hash function is (slot + pin) & 3 -> "LNK[D|A|B|C]". -* -*/ -static Aml *build_prt (bool is_pci0_prt) -{ -Aml *method, *while_ctx, *pin, *res; - - method =aml_method ("_PRT" ,0 ,AML_NOTSERIALIZED ); - res =aml_local (0 ); - pin =aml_local (1 ); -aml_append (method,aml_store (aml_package (128 ), res)); -aml_append (method,aml_store (aml_int (0 ), pin)); - -/* while (pin < 128) */ - while_ctx =aml_while (aml_lless (pin,aml_int (128 ))); - { -Aml *slot =aml_local (2 ); -Aml *lnk_idx =aml_local (3 ); -Aml *route =aml_local (4 ); - -/* slot = pin >> 2 */ -aml_append (while_ctx, -aml_store (aml_shiftright (pin,aml_int (2 ),NULL ), slot)); -/* lnk_idx = (slot + pin) & 3 */ -aml_append (while_ctx, -aml_store (aml_and (aml_add (pin, slot,NULL ),aml_int (3 ),NULL ), - lnk_idx)); - -/* route[2] = "LNK[D|A|B|C]", selection based on pin % 3 */ -aml_append (while_ctx,initialize_route (route,"LNKD" , lnk_idx,0 )); -if (is_pci0_prt) { -Aml *if_device_1, *if_pin_4, *else_pin_4; - -/* device 1 is the power-management device, needs SCI */ - if_device_1 =aml_if (aml_equal (lnk_idx,aml_int (1 ))); - { - if_pin_4 =aml_if (aml_equal (pin,aml_int (4 ))); - { -aml_append (if_pin_4, -aml_store (build_prt_entry ("LNKS" ), route)); - } -aml_append (if_device_1, if_pin_4); - else_pin_4 =aml_else (); - { -aml_append (else_pin_4, -aml_store (build_prt_entry ("LNKA" ), route)); - } -aml_append (if_device_1, else_pin_4); - } -aml_append (while_ctx, if_device_1); - }else { -aml_append (while_ctx,initialize_route (route,"LNKA" , lnk_idx,1 )); - } -aml_append (while_ctx,initialize_route (route,"LNKB" , lnk_idx,2 )); -aml_append (while_ctx,initialize_route (route,"LNKC" , lnk_idx,3 )); - -/* route[0] = 0x[slot]FFFF */ -aml_append (while_ctx, -aml_store (aml_or (aml_shiftleft (slot,aml_int (16 )),aml_int (0xFFFF ), -NULL ), -aml_index (route,aml_int (0 )))); -/* route[1] = pin & 3 */ -aml_append (while_ctx, -aml_store (aml_and (pin,aml_int (3 ),NULL ), -aml_index (route,aml_int (1 )))); -/* res[pin] = route */ -aml_append (while_ctx,aml_store (route,aml_index (res, pin))); -/* pin++ */ -aml_append (while_ctx,aml_increment (pin)); - } -aml_append (method, while_ctx); -/* return res*/ -aml_append (method,aml_return (res)); - -return method; -} - -typedef struct CrsRangeEntry { -uint64_t base; -uint64_t limit; -}CrsRangeEntry ; - -static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) -{ -CrsRangeEntry *entry; - - entry =g_malloc (sizeof (*entry)); - entry->base = base; - entry->limit = limit; - -g_ptr_array_add (ranges, entry); -} - -static void crs_range_free (gpointer data) -{ -CrsRangeEntry *entry = (CrsRangeEntry *)data; -g_free (entry); -} - -typedef struct CrsRangeSet { -GPtrArray *io_ranges; -GPtrArray *mem_ranges; -GPtrArray *mem_64bit_ranges; - }CrsRangeSet ; - -static void crs_range_set_init (CrsRangeSet *range_set) -{ - range_set->io_ranges =g_ptr_array_new_with_free_func (crs_range_free); - range_set->mem_ranges =g_ptr_array_new_with_free_func (crs_range_free); - range_set->mem_64bit_ranges = -g_ptr_array_new_with_free_func (crs_range_free); -} - -static void crs_range_set_free (CrsRangeSet *range_set) -{ -g_ptr_array_free (range_set->io_ranges, true); -g_ptr_array_free (range_set->mem_ranges, true); -g_ptr_array_free (range_set->mem_64bit_ranges, true); -} - -static gint crs_range_compare (gconstpointer a,gconstpointer b) -{ -CrsRangeEntry *entry_a = *(CrsRangeEntry **)a; -CrsRangeEntry *entry_b = *(CrsRangeEntry **)b; - -return (int64_t )entry_a->base - (int64_t )entry_b->base; -} - -/* -* crs_replace_with_free_ranges - given the 'used' ranges within [start - end] -* interval, computes the 'free' ranges from the same interval. -* Example: If the input array is { [a1 - a2],[b1 - b2] }, the function -* will return { [base - a1], [a2 - b1], [b2 - limit] }. -*/ -static void crs_replace_with_free_ranges (GPtrArray *ranges, -uint64_t start,uint64_t end) -{ -GPtrArray *free_ranges =g_ptr_array_new (); -uint64_t free_base = start; -int i; - -g_ptr_array_sort (ranges, crs_range_compare); -for (i =0 ; i < ranges->len; i++) { -CrsRangeEntry *used =g_ptr_array_index (ranges, i); - -if (free_base < used->base) { -crs_range_insert (free_ranges, free_base, used->base -1 ); - } - - free_base = used->limit +1 ; - } - -if (free_base < end) { -crs_range_insert (free_ranges, free_base, end); - } - -g_ptr_array_set_size (ranges,0 ); -for (i =0 ; i < free_ranges->len; i++) { -g_ptr_array_add (ranges,g_ptr_array_index (free_ranges, i)); - } - -g_ptr_array_free (free_ranges, true); -} - -/* -* crs_range_merge - merges adjacent ranges in the given array. -* Array elements are deleted and replaced with the merged ranges. -*/ -static void crs_range_merge (GPtrArray *range) -{ -GPtrArray *tmp =g_ptr_array_new_with_free_func (crs_range_free); -CrsRangeEntry *entry; -uint64_t range_base, range_limit; -int i; - -if (!range->len) { -return ; - } - -g_ptr_array_sort (range, crs_range_compare); - - entry =g_ptr_array_index (range,0 ); - range_base = entry->base; - range_limit = entry->limit; -for (i =1 ; i < range->len; i++) { - entry =g_ptr_array_index (range, i); -if (entry->base -1 == range_limit) { - range_limit = entry->limit; - }else { -crs_range_insert (tmp, range_base, range_limit); - range_base = entry->base; - range_limit = entry->limit; - } - } -crs_range_insert (tmp, range_base, range_limit); - -g_ptr_array_set_size (range,0 ); -for (i =0 ; i < tmp->len; i++) { - entry =g_ptr_array_index (tmp, i); -crs_range_insert (range, entry->base, entry->limit); - } -g_ptr_array_free (tmp, true); -} - -static Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set) -{ -Aml *crs =aml_resource_template (); -CrsRangeSet temp_range_set; -CrsRangeEntry *entry; -uint8_t max_bus =pci_bus_num (host->bus); -uint8_t type; -int devfn; -int i; - -crs_range_set_init (&temp_range_set); -for (devfn =0 ; devfn <ARRAY_SIZE (host->bus->devices); devfn++) { -uint64_t range_base, range_limit; -PCIDevice *dev = host->bus->devices[devfn]; - -if (!dev) { -continue ; - } - -for (i =0 ; i <PCI_NUM_REGIONS ; i++) { -PCIIORegion *r = &dev->io_regions[i]; - - range_base = r->addr; - range_limit = r->addr + r->size -1 ; - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (!range_base || range_base > range_limit) { -continue ; - } - -if (r->type &PCI_BASE_ADDRESS_SPACE_IO ) { -crs_range_insert (temp_range_set.io_ranges, - range_base, range_limit); - }else {/* "memory" */ -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - } - } - - type = dev->config[PCI_HEADER_TYPE ] & ~PCI_HEADER_TYPE_MULTI_FUNCTION ; -if (type ==PCI_HEADER_TYPE_BRIDGE ) { -uint8_t subordinate = dev->config[PCI_SUBORDINATE_BUS ]; -if (subordinate > max_bus) { - max_bus = subordinate; - } - - range_base =pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_IO ); - range_limit =pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_IO ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -crs_range_insert (temp_range_set.io_ranges, - range_base, range_limit); - } - - range_base = -pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); - range_limit = -pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -uint64_t length = range_limit - range_base +1 ; -if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - }else { -crs_range_insert (temp_range_set.mem_64bit_ranges, - range_base, range_limit); - } - } - - range_base = -pci_bridge_get_base (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); - range_limit = -pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -uint64_t length = range_limit - range_base +1 ; -if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - }else { -crs_range_insert (temp_range_set.mem_64bit_ranges, - range_base, range_limit); - } - } - } - } - -crs_range_merge (temp_range_set.io_ranges); -for (i =0 ; i < temp_range_set.io_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.io_ranges, i); -aml_append (crs, -aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , -AML_POS_DECODE ,AML_ENTIRE_RANGE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->io_ranges, entry->base, entry->limit); - } - -crs_range_merge (temp_range_set.mem_ranges); -for (i =0 ; i < temp_range_set.mem_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.mem_ranges, i); -aml_append (crs, -aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED , -AML_MAX_FIXED ,AML_NON_CACHEABLE , -AML_READ_WRITE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->mem_ranges, entry->base, entry->limit); - } - -crs_range_merge (temp_range_set.mem_64bit_ranges); -for (i =0 ; i < temp_range_set.mem_64bit_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.mem_64bit_ranges, i); -aml_append (crs, -aml_qword_memory (AML_POS_DECODE ,AML_MIN_FIXED , -AML_MAX_FIXED ,AML_NON_CACHEABLE , -AML_READ_WRITE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->mem_64bit_ranges, - entry->base, entry->limit); - } - -crs_range_set_free (&temp_range_set); - -aml_append (crs, -aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , -0 , -pci_bus_num (host->bus), - max_bus, -0 , - max_bus -pci_bus_num (host->bus) +1 )); - -return crs; -} -static void build_hpet_aml (Aml *table) {Aml *crs;@@ -1334,37 +930,6 @@ static Aml *build_link_dev(const char *name, uint8_t uid, Aml *reg)return dev; } -static Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi) -{ -Aml *dev; -Aml *crs; -Aml *method; -uint32_t irqs; - - dev =aml_device ("%s" , name); -aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0C0F" ))); -aml_append (dev,aml_name_decl ("_UID" ,aml_int (uid))); - - crs =aml_resource_template (); - irqs = gsi; -aml_append (crs,aml_interrupt (AML_CONSUMER ,AML_LEVEL ,AML_ACTIVE_HIGH , -AML_SHARED , &irqs,1 )); -aml_append (dev,aml_name_decl ("_PRS" , crs)); - -aml_append (dev,aml_name_decl ("_CRS" , crs)); - -/* -* _DIS can be no-op because the interrupt cannot be disabled. -*/ - method =aml_method ("_DIS" ,0 ,AML_NOTSERIALIZED ); -aml_append (dev, method); - - method =aml_method ("_SRS" ,1 ,AML_NOTSERIALIZED ); -aml_append (dev, method); - -return dev; -} -/* _CRS method - get current settings */ static Aml *build_iqcr_method (bool is_piix4) {@@ -1728,54 +1293,6 @@ static void build_piix4_pci_hotplug(Aml *table)aml_append (table, scope); } -static Aml *build_q35_osc_method (void ) -{ -Aml *if_ctx; -Aml *if_ctx2; -Aml *else_ctx; -Aml *method; -Aml *a_cwd1 =aml_name ("CDW1" ); -Aml *a_ctrl =aml_local (0 ); - - method =aml_method ("_OSC" ,4 ,AML_NOTSERIALIZED ); -aml_append (method,aml_create_dword_field (aml_arg (3 ),aml_int (0 ),"CDW1" )); - - if_ctx =aml_if (aml_equal ( -aml_arg (0 ),aml_touuid ("33DB4D5B-1FF7-401C-9657-7441C03DD766" ))); -aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (4 ),"CDW2" )); -aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (8 ),"CDW3" )); - -aml_append (if_ctx,aml_store (aml_name ("CDW3" ), a_ctrl)); - -/* -* Always allow native PME, AER (no dependencies) -* Allow SHPC (PCI bridges can have SHPC controller) -*/ -aml_append (if_ctx,aml_and (a_ctrl,aml_int (0x1F ), a_ctrl)); - - if_ctx2 =aml_if (aml_lnot (aml_equal (aml_arg (1 ),aml_int (1 )))); -/* Unknown revision */ -aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x08 ), a_cwd1)); -aml_append (if_ctx, if_ctx2); - - if_ctx2 =aml_if (aml_lnot (aml_equal (aml_name ("CDW3" ), a_ctrl))); -/* Capabilities bits were masked */ -aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x10 ), a_cwd1)); -aml_append (if_ctx, if_ctx2); - -/* Update DWORD3 in the buffer */ -aml_append (if_ctx,aml_store (a_ctrl,aml_name ("CDW3" ))); -aml_append (method, if_ctx); - - else_ctx =aml_else (); -/* Unrecognized UUID */ -aml_append (else_ctx,aml_or (a_cwd1,aml_int (4 ), a_cwd1)); -aml_append (method, else_ctx); - -aml_append (method,aml_return (aml_arg (3 ))); -return method; -} - static void build_dsdt(GArray *table_data, BIOSLinker *linker, AcpiPmInfo *pm, AcpiMiscInfo *misc,@@ -1818,7 +1335,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_CID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_ADR" ,aml_int (0 )));aml_append (dev,aml_name_decl ("_UID" ,aml_int (1 ))); -aml_append (dev,build_q35_osc_method ()); +aml_append (dev,build_osc_method ());aml_append (sb_scope, dev);aml_append (dsdt, sb_scope);@@ -1883,7 +1400,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num)));if (pci_bus_is_express (bus)) { -aml_append (dev,build_q35_osc_method ()); +aml_append (dev,build_osc_method ()); }if (numa_node !=NUMA_NODE_UNASSIGNED ) {@@ -2370,35 +1887,6 @@ build_srat(GArray *table_data, BIOSLinker *linker, table_data->len - srat_start, 1, NULL, NULL); } -static void -build_mcfg_q35 (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info) -{ -AcpiTableMcfg *mcfg; -const char *sig; -int len =sizeof (*mcfg) +1 *sizeof (mcfg->allocation[0 ]); - - mcfg =acpi_data_push (table_data, len); - mcfg->allocation[0 ].address =cpu_to_le64 (info->mcfg_base); -/* Only a single allocation so no need to play with segments */ - mcfg->allocation[0 ].pci_segment =cpu_to_le16 (0 ); - mcfg->allocation[0 ].start_bus_number =0 ; - mcfg->allocation[0 ].end_bus_number =PCIE_MMCFG_BUS (info->mcfg_size -1 ); - -/* MCFG is used for ECAM which can be enabled or disabled by guest. -* To avoid table size changes (which create migration issues), -* always create the table even if there are no allocations, -* but set the signature to a reserved value in this case. -* ACPI spec requires OSPMs to ignore such tables. -*/ -if (info->mcfg_base ==PCIE_BASE_ADDR_UNMAPPED ) { -/* Reserved signature: ignored by OSPM */ - sig ="QEMU" ; - }else { - sig ="MCFG" ; - } -build_header (linker, table_data, (void *)mcfg, sig, len,1 ,NULL ,NULL ); -} -/* * VT-d spec 8.1 DMA Remapping Reporting Structure * (version Oct. 2014 or later)
hw/i386/acpi-build.c void acpi_build(AcpiBuildTables *tables, · line 2120
Quoted 8 lines
hw/i386/acpi-build.c +1
-1@@ -2626,7 +2114,7 @@ void acpi_build(AcpiBuildTables *tables, }if (acpi_get_mcfg (&mcfg)) {acpi_add_table (table_offsets, tables_blob); -build_mcfg_q35 (tables_blob, tables->linker, &mcfg); +build_mcfg (tables_blob, tables->linker, &mcfg); }if (x86_iommu_get_default ()) {IommuType IOMMUType =x86_iommu_get_type ();
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 07/24] hw: acpi: Generalize AML build routines
In reply to Samuel OrtizQuoted 6 lines · On Mon, 5 Nov 2018 02:40:30 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
Most of the AML build routines under acpi-build are not even architecture specific. They can be moved to the more generic hw/acpi folder where they could be shared across machine types and architectures.
I'd prefer if won't pull into aml-build PCI specific headers, Suggest to create hw/acpi/pci.c and move generic PCI related code there, with corresponding header the would export API (preferably without PCI dependencies in it)
Also patch is too big and does too much at a time.
Here I'd suggest to split it in smaller parts to make it more digestible
1. split it in 3 parts
* MCFG
* CRS
* PTR
2. mcfg between x86 and ARM look pretty much the same with ARM
open codding bus number calculation and missing migration hack
* a patch to make bus number calculation in ARM the same as x86
* a patch to bring migration hack (dummy MCFG table in case it's disabled) it's questionable if we actually need it in generic,
we most likely need it for legacy machines that predate
resizable MemeoryRegion, but we probably don't need it for
later machines as problem doesn't exists there.
So it might be better to push hack out from generic code
to a legacy caller and keep generic MCFG clean.
(this patch might be better at the beginning of the series as
it might affect acpi test results, and might need an update to reference tables I don't really sure)
* at this point arm and x86 impl. would be the same so
a patch to move mcfg build routine to a generic place and replace x86/arm with a single impl.
* a patch to convert mcfg build routine to build_append_int_noprefix() API and drop AcpiTableMcfg structure
Quoted 32 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Yang Zhong <[email protected]>--- include/hw/acpi/aml-build.h | 25 ++ hw/acpi/aml-build.c | 498 ++++++++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 +- hw/i386/acpi-build.c | 518 +----------------------------------- 4 files changed, 528 insertions(+), 517 deletions(-)include/hw/acpi/aml-build.h +7
-0@@ -3,6 +3,7 @@#include "hw/acpi/acpi-defs.h" #include "hw/acpi/bios-linker-loader.h" +#include "hw/pci/pcie_host.h" /* Reserve RAM space for tables: add another order of magnitude. */ #define ACPI_BUILD_TABLE_MAX_SIZE 0x200000@@ -223,6 +224,21 @@ struct AcpiBuildTables {BIOSLinker *linker; } AcpiBuildTables; +typedef struct AcpiMcfgInfo { +uint64_t mcfg_base; +uint32_t mcfg_size; +}AcpiMcfgInfo ; + +typedef struct CrsRangeEntry {
include/hw/acpi/aml-build.h struct AcpiBuildTables { · line 242
Quoted 10 lines
include/hw/acpi/aml-build.h +9
-0+uint64_t base; +uint64_t limit; +} CrsRangeEntry; + +typedef struct CrsRangeSet { +GPtrArray *io_ranges; +GPtrArray *mem_ranges; +GPtrArray *mem_64bit_ranges; +}CrsRangeSet ;/**
I'd prefer not to put these into aml-build.h, it's supposed to host ACPI spec primitives mostly so I'd suggest to move these to acpi-defs.h or PCI specific acpi header
Quoted 1,148 lines
include/hw/acpi/aml-build.h +9
-0* init_aml_allocator: * @@ -389,6 +405,15 @@ void acpi_align_size(GArray *blob, unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre); +Aml *build_osc_method (void ); +void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info); +Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi); +Aml *build_prt (bool is_pci0_prt); +void crs_range_set_init (CrsRangeSet *range_set); +Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); +void crs_replace_with_free_ranges (GPtrArray *ranges, +uint64_t start,uint64_t end); +void crs_range_set_free (CrsRangeSet *range_set);void build_rsdp_rsdt (GArray *table_data,BIOSLinker *linker,unsigned rsdt_tbl_offset);hw/acpi/aml-build.c +498
-0@@ -25,6 +25,10 @@#include "qemu/bswap.h" #include "qemu/bitops.h" #include "sysemu/numa.h" +#include "hw/pci/pci.h" +#include "hw/pci/pci_bus.h" +#include "qemu/range.h" +#include "hw/pci/pci_bridge.h" static GArray *build_alloc_array (void ) {@@ -1597,6 +1601,500 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } +static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) +{ +CrsRangeEntry *entry; + + entry =g_malloc (sizeof (*entry)); + entry->base = base; + entry->limit = limit; + +g_ptr_array_add (ranges, entry); +} + +static void crs_range_free (gpointer data) +{ +CrsRangeEntry *entry = (CrsRangeEntry *)data; +g_free (entry); +} + +void crs_range_set_init (CrsRangeSet *range_set) +{ + range_set->io_ranges =g_ptr_array_new_with_free_func (crs_range_free); + range_set->mem_ranges =g_ptr_array_new_with_free_func (crs_range_free); + range_set->mem_64bit_ranges = +g_ptr_array_new_with_free_func (crs_range_free); +} + +void crs_range_set_free (CrsRangeSet *range_set) +{ +g_ptr_array_free (range_set->io_ranges, true); +g_ptr_array_free (range_set->mem_ranges, true); +g_ptr_array_free (range_set->mem_64bit_ranges, true); +} + +static gint crs_range_compare (gconstpointer a,gconstpointer b) +{ +CrsRangeEntry *entry_a = *(CrsRangeEntry **)a; +CrsRangeEntry *entry_b = *(CrsRangeEntry **)b; + +return (int64_t )entry_a->base - (int64_t )entry_b->base; +} + +/* +* crs_replace_with_free_ranges - given the 'used' ranges within [start - end] +* interval, computes the 'free' ranges from the same interval. +* Example: If the input array is { [a1 - a2],[b1 - b2] }, the function +* will return { [base - a1], [a2 - b1], [b2 - limit] }. +*/ +void crs_replace_with_free_ranges (GPtrArray *ranges, +uint64_t start,uint64_t end) +{ +GPtrArray *free_ranges =g_ptr_array_new (); +uint64_t free_base = start; +int i; + +g_ptr_array_sort (ranges, crs_range_compare); +for (i =0 ; i < ranges->len; i++) { +CrsRangeEntry *used =g_ptr_array_index (ranges, i); + +if (free_base < used->base) { +crs_range_insert (free_ranges, free_base, used->base -1 ); + } + + free_base = used->limit +1 ; + } + +if (free_base < end) { +crs_range_insert (free_ranges, free_base, end); + } + +g_ptr_array_set_size (ranges,0 ); +for (i =0 ; i < free_ranges->len; i++) { +g_ptr_array_add (ranges,g_ptr_array_index (free_ranges, i)); + } + +g_ptr_array_free (free_ranges, true); +} + +/* +* crs_range_merge - merges adjacent ranges in the given array. +* Array elements are deleted and replaced with the merged ranges. +*/ +static void crs_range_merge (GPtrArray *range) +{ +GPtrArray *tmp =g_ptr_array_new_with_free_func (crs_range_free); +CrsRangeEntry *entry; +uint64_t range_base, range_limit; +int i; + +if (!range->len) { +return ; + } + +g_ptr_array_sort (range, crs_range_compare); + + entry =g_ptr_array_index (range,0 ); + range_base = entry->base; + range_limit = entry->limit; +for (i =1 ; i < range->len; i++) { + entry =g_ptr_array_index (range, i); +if (entry->base -1 == range_limit) { + range_limit = entry->limit; + }else { +crs_range_insert (tmp, range_base, range_limit); + range_base = entry->base; + range_limit = entry->limit; + } + } +crs_range_insert (tmp, range_base, range_limit); + +g_ptr_array_set_size (range,0 ); +for (i =0 ; i < tmp->len; i++) { + entry =g_ptr_array_index (tmp, i); +crs_range_insert (range, entry->base, entry->limit); + } +g_ptr_array_free (tmp, true); +} + +Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set) +{ +Aml *crs =aml_resource_template (); +CrsRangeSet temp_range_set; +CrsRangeEntry *entry; +uint8_t max_bus =pci_bus_num (host->bus); +uint8_t type; +int devfn; +int i; + +crs_range_set_init (&temp_range_set); +for (devfn =0 ; devfn <ARRAY_SIZE (host->bus->devices); devfn++) { +uint64_t range_base, range_limit; +PCIDevice *dev = host->bus->devices[devfn]; + +if (!dev) { +continue ; + } + +for (i =0 ; i <PCI_NUM_REGIONS ; i++) { +PCIIORegion *r = &dev->io_regions[i]; + + range_base = r->addr; + range_limit = r->addr + r->size -1 ; + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (!range_base || range_base > range_limit) { +continue ; + } + +if (r->type &PCI_BASE_ADDRESS_SPACE_IO ) { +crs_range_insert (temp_range_set.io_ranges, + range_base, range_limit); + }else {/* "memory" */ +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + } + } + + type = dev->config[PCI_HEADER_TYPE ] & ~PCI_HEADER_TYPE_MULTI_FUNCTION ; +if (type ==PCI_HEADER_TYPE_BRIDGE ) { +uint8_t subordinate = dev->config[PCI_SUBORDINATE_BUS ]; +if (subordinate > max_bus) { + max_bus = subordinate; + } + + range_base =pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_IO ); + range_limit =pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_IO ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +crs_range_insert (temp_range_set.io_ranges, + range_base, range_limit); + } + + range_base = +pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); + range_limit = +pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +uint64_t length = range_limit - range_base +1 ; +if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + }else { +crs_range_insert (temp_range_set.mem_64bit_ranges, + range_base, range_limit); + } + } + + range_base = +pci_bridge_get_base (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); + range_limit = +pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); + +/* +* Work-around for old bioses +* that do not support multiple root buses +*/ +if (range_base && range_base <= range_limit) { +uint64_t length = range_limit - range_base +1 ; +if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { +crs_range_insert (temp_range_set.mem_ranges, + range_base, range_limit); + }else { +crs_range_insert (temp_range_set.mem_64bit_ranges, + range_base, range_limit); + } + } + } + } + +crs_range_merge (temp_range_set.io_ranges); +for (i =0 ; i < temp_range_set.io_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.io_ranges, i); +aml_append (crs, +aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , +AML_POS_DECODE ,AML_ENTIRE_RANGE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->io_ranges, entry->base, entry->limit); + } + +crs_range_merge (temp_range_set.mem_ranges); +for (i =0 ; i < temp_range_set.mem_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.mem_ranges, i); +aml_append (crs, +aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED , +AML_MAX_FIXED ,AML_NON_CACHEABLE , +AML_READ_WRITE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->mem_ranges, entry->base, entry->limit); + } + +crs_range_merge (temp_range_set.mem_64bit_ranges); +for (i =0 ; i < temp_range_set.mem_64bit_ranges->len; i++) { + entry =g_ptr_array_index (temp_range_set.mem_64bit_ranges, i); +aml_append (crs, +aml_qword_memory (AML_POS_DECODE ,AML_MIN_FIXED , +AML_MAX_FIXED ,AML_NON_CACHEABLE , +AML_READ_WRITE , +0 , entry->base, entry->limit,0 , + entry->limit - entry->base +1 )); +crs_range_insert (range_set->mem_64bit_ranges, + entry->base, entry->limit); + } + +crs_range_set_free (&temp_range_set); + +aml_append (crs, +aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , +0 , +pci_bus_num (host->bus), + max_bus, +0 , + max_bus -pci_bus_num (host->bus) +1 )); + +return crs; +} + +Aml *build_osc_method (void ) +{ +Aml *if_ctx; +Aml *if_ctx2; +Aml *else_ctx; +Aml *method; +Aml *a_cwd1 =aml_name ("CDW1" ); +Aml *a_ctrl =aml_local (0 ); + + method =aml_method ("_OSC" ,4 ,AML_NOTSERIALIZED ); +aml_append (method,aml_create_dword_field (aml_arg (3 ),aml_int (0 ),"CDW1" )); + + if_ctx =aml_if (aml_equal ( +aml_arg (0 ),aml_touuid ("33DB4D5B-1FF7-401C-9657-7441C03DD766" ))); +aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (4 ),"CDW2" )); +aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (8 ),"CDW3" )); + +aml_append (if_ctx,aml_store (aml_name ("CDW3" ), a_ctrl)); + +/* +* Always allow native PME, AER (no dependencies) +* Allow SHPC (PCI bridges can have SHPC controller) +*/ +aml_append (if_ctx,aml_and (a_ctrl,aml_int (0x1F ), a_ctrl)); + + if_ctx2 =aml_if (aml_lnot (aml_equal (aml_arg (1 ),aml_int (1 )))); +/* Unknown revision */ +aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x08 ), a_cwd1)); +aml_append (if_ctx, if_ctx2); + + if_ctx2 =aml_if (aml_lnot (aml_equal (aml_name ("CDW3" ), a_ctrl))); +/* Capabilities bits were masked */ +aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x10 ), a_cwd1)); +aml_append (if_ctx, if_ctx2); + +/* Update DWORD3 in the buffer */ +aml_append (if_ctx,aml_store (a_ctrl,aml_name ("CDW3" ))); +aml_append (method, if_ctx); + + else_ctx =aml_else (); +/* Unrecognized UUID */ +aml_append (else_ctx,aml_or (a_cwd1,aml_int (4 ), a_cwd1)); +aml_append (method, else_ctx); + +aml_append (method,aml_return (aml_arg (3 ))); +return method; +} + +void +build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info) +{ +AcpiTableMcfg *mcfg; +const char *sig; +int len =sizeof (*mcfg) +1 *sizeof (mcfg->allocation[0 ]); + + mcfg =acpi_data_push (table_data, len); + mcfg->allocation[0 ].address =cpu_to_le64 (info->mcfg_base); +/* Only a single allocation so no need to play with segments */ + mcfg->allocation[0 ].pci_segment =cpu_to_le16 (0 ); + mcfg->allocation[0 ].start_bus_number =0 ; + mcfg->allocation[0 ].end_bus_number =PCIE_MMCFG_BUS (info->mcfg_size -1 ); + +/* MCFG is used for ECAM which can be enabled or disabled by guest. +* To avoid table size changes (which create migration issues), +* always create the table even if there are no allocations, +* but set the signature to a reserved value in this case. +* ACPI spec requires OSPMs to ignore such tables. +*/ +if (info->mcfg_base ==PCIE_BASE_ADDR_UNMAPPED ) { +/* Reserved signature: ignored by OSPM */ + sig ="QEMU" ; + }else { + sig ="MCFG" ; + } +build_header (linker, table_data, (void *)mcfg, sig, len,1 ,NULL ,NULL ); +} + +Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi) +{ +Aml *dev; +Aml *crs; +Aml *method; +uint32_t irqs; + + dev =aml_device ("%s" , name); +aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0C0F" ))); +aml_append (dev,aml_name_decl ("_UID" ,aml_int (uid))); + + crs =aml_resource_template (); + irqs = gsi; +aml_append (crs,aml_interrupt (AML_CONSUMER ,AML_LEVEL ,AML_ACTIVE_HIGH , +AML_SHARED , &irqs,1 )); +aml_append (dev,aml_name_decl ("_PRS" , crs)); + +aml_append (dev,aml_name_decl ("_CRS" , crs)); + +/* +* _DIS can be no-op because the interrupt cannot be disabled. +*/ + method =aml_method ("_DIS" ,0 ,AML_NOTSERIALIZED ); +aml_append (dev, method); + + method =aml_method ("_SRS" ,1 ,AML_NOTSERIALIZED ); +aml_append (dev, method); + +return dev; +} + +/** +* build_prt_entry: +* @link_name: link name for PCI route entry +* +* build AML package containing a PCI route entry for @link_name +*/ +static Aml *build_prt_entry (const char *link_name) +{ +Aml *a_zero =aml_int (0 ); +Aml *pkg =aml_package (4 ); +aml_append (pkg, a_zero); +aml_append (pkg, a_zero); +aml_append (pkg,aml_name ("%s" , link_name)); +aml_append (pkg, a_zero); +return pkg; +} + +/* +* initialize_route - Initialize the interrupt routing rule +* through a specific LINK: +* if (lnk_idx == idx) +* route using link 'link_name' +*/ +static Aml *initialize_route (Aml *route,const char *link_name, +Aml *lnk_idx,int idx) +{ +Aml *if_ctx =aml_if (aml_equal (lnk_idx,aml_int (idx))); +Aml *pkg =build_prt_entry (link_name); + +aml_append (if_ctx,aml_store (pkg, route)); + +return if_ctx; +} + +/* +* build_prt - Define interrupt rounting rules +* +* Returns an array of 128 routes, one for each device, +* based on device location. +* The main goal is to equaly distribute the interrupts +* over the 4 existing ACPI links (works only for i440fx). +* The hash function is (slot + pin) & 3 -> "LNK[D|A|B|C]". +* +*/ +Aml *build_prt (bool is_pci0_prt) +{ +Aml *method, *while_ctx, *pin, *res; + + method =aml_method ("_PRT" ,0 ,AML_NOTSERIALIZED ); + res =aml_local (0 ); + pin =aml_local (1 ); +aml_append (method,aml_store (aml_package (128 ), res)); +aml_append (method,aml_store (aml_int (0 ), pin)); + +/* while (pin < 128) */ + while_ctx =aml_while (aml_lless (pin,aml_int (128 ))); + { +Aml *slot =aml_local (2 ); +Aml *lnk_idx =aml_local (3 ); +Aml *route =aml_local (4 ); + +/* slot = pin >> 2 */ +aml_append (while_ctx, +aml_store (aml_shiftright (pin,aml_int (2 ),NULL ), slot)); +/* lnk_idx = (slot + pin) & 3 */ +aml_append (while_ctx, +aml_store (aml_and (aml_add (pin, slot,NULL ),aml_int (3 ),NULL ), + lnk_idx)); + +/* route[2] = "LNK[D|A|B|C]", selection based on pin % 3 */ +aml_append (while_ctx,initialize_route (route,"LNKD" , lnk_idx,0 )); +if (is_pci0_prt) { +Aml *if_device_1, *if_pin_4, *else_pin_4; + +/* device 1 is the power-management device, needs SCI */ + if_device_1 =aml_if (aml_equal (lnk_idx,aml_int (1 ))); + { + if_pin_4 =aml_if (aml_equal (pin,aml_int (4 ))); + { +aml_append (if_pin_4, +aml_store (build_prt_entry ("LNKS" ), route)); + } +aml_append (if_device_1, if_pin_4); + else_pin_4 =aml_else (); + { +aml_append (else_pin_4, +aml_store (build_prt_entry ("LNKA" ), route)); + } +aml_append (if_device_1, else_pin_4); + } +aml_append (while_ctx, if_device_1); + }else { +aml_append (while_ctx,initialize_route (route,"LNKA" , lnk_idx,1 )); + } +aml_append (while_ctx,initialize_route (route,"LNKB" , lnk_idx,2 )); +aml_append (while_ctx,initialize_route (route,"LNKC" , lnk_idx,3 )); + +/* route[0] = 0x[slot]FFFF */ +aml_append (while_ctx, +aml_store (aml_or (aml_shiftleft (slot,aml_int (16 )),aml_int (0xFFFF ), +NULL ), +aml_index (route,aml_int (0 )))); +/* route[1] = pin & 3 */ +aml_append (while_ctx, +aml_store (aml_and (pin,aml_int (3 ),NULL ), +aml_index (route,aml_int (1 )))); +/* res[pin] = route */ +aml_append (while_ctx,aml_store (route,aml_index (res, pin))); +/* pin++ */ +aml_append (while_ctx,aml_increment (pin)); + } +aml_append (method, while_ctx); +/* return res*/ +aml_append (method,aml_return (res)); + +return method; +} +/* Build rsdt table */ void build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,hw/arm/virt-acpi-build.c +2
-2@@ -545,7 +545,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) }static void -build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_mcfg (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {AcpiTableMcfg *mcfg;const MemMapEntry *memmap = vms->memmap;@@ -790,7 +790,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)build_gtdt (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob); -build_mcfg (tables_blob, tables->linker, vms); +virt_build_mcfg (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob);build_spcr (tables_blob, tables->linker, vms);hw/i386/acpi-build.c +3
-515@@ -27,7 +27,6 @@#include "qemu-common.h" #include "qemu/bitmap.h" #include "qemu/error-report.h" -#include "hw/pci/pci.h" #include "qom/cpu.h" #include "target/i386/cpu.h" #include "hw/misc/pvpanic.h" @@ -53,7 +52,6 @@#include "hw/acpi/piix4.h" #include "hw/acpi/pcihp.h" #include "hw/i386/ich9.h" -#include "hw/pci/pci_bus.h" #include "hw/pci-host/q35.h" #include "hw/i386/x86-iommu.h" @@ -86,11 +84,6 @@/* Default IOAPIC ID */ #define ACPI_BUILD_IOAPIC_ID 0x0 -typedef struct AcpiMcfgInfo { -uint64_t mcfg_base; -uint32_t mcfg_size; -}AcpiMcfgInfo ; - typedef struct AcpiPmInfo { bool s3_disabled; bool s4_disabled;@@ -567,403 +560,6 @@ static void build_append_pci_bus_devices(Aml *parent_scope, PCIBus *bus,qobject_unref (bsel); } -/** -* build_prt_entry: -* @link_name: link name for PCI route entry -* -* build AML package containing a PCI route entry for @link_name -*/ -static Aml *build_prt_entry (const char *link_name) -{ -Aml *a_zero =aml_int (0 ); -Aml *pkg =aml_package (4 ); -aml_append (pkg, a_zero); -aml_append (pkg, a_zero); -aml_append (pkg,aml_name ("%s" , link_name)); -aml_append (pkg, a_zero); -return pkg; -} - -/* -* initialize_route - Initialize the interrupt routing rule -* through a specific LINK: -* if (lnk_idx == idx) -* route using link 'link_name' -*/ -static Aml *initialize_route (Aml *route,const char *link_name, -Aml *lnk_idx,int idx) -{ -Aml *if_ctx =aml_if (aml_equal (lnk_idx,aml_int (idx))); -Aml *pkg =build_prt_entry (link_name); - -aml_append (if_ctx,aml_store (pkg, route)); - -return if_ctx; -} - -/* -* build_prt - Define interrupt rounting rules -* -* Returns an array of 128 routes, one for each device, -* based on device location. -* The main goal is to equaly distribute the interrupts -* over the 4 existing ACPI links (works only for i440fx). -* The hash function is (slot + pin) & 3 -> "LNK[D|A|B|C]". -* -*/ -static Aml *build_prt (bool is_pci0_prt) -{ -Aml *method, *while_ctx, *pin, *res; - - method =aml_method ("_PRT" ,0 ,AML_NOTSERIALIZED ); - res =aml_local (0 ); - pin =aml_local (1 ); -aml_append (method,aml_store (aml_package (128 ), res)); -aml_append (method,aml_store (aml_int (0 ), pin)); - -/* while (pin < 128) */ - while_ctx =aml_while (aml_lless (pin,aml_int (128 ))); - { -Aml *slot =aml_local (2 ); -Aml *lnk_idx =aml_local (3 ); -Aml *route =aml_local (4 ); - -/* slot = pin >> 2 */ -aml_append (while_ctx, -aml_store (aml_shiftright (pin,aml_int (2 ),NULL ), slot)); -/* lnk_idx = (slot + pin) & 3 */ -aml_append (while_ctx, -aml_store (aml_and (aml_add (pin, slot,NULL ),aml_int (3 ),NULL ), - lnk_idx)); - -/* route[2] = "LNK[D|A|B|C]", selection based on pin % 3 */ -aml_append (while_ctx,initialize_route (route,"LNKD" , lnk_idx,0 )); -if (is_pci0_prt) { -Aml *if_device_1, *if_pin_4, *else_pin_4; - -/* device 1 is the power-management device, needs SCI */ - if_device_1 =aml_if (aml_equal (lnk_idx,aml_int (1 ))); - { - if_pin_4 =aml_if (aml_equal (pin,aml_int (4 ))); - { -aml_append (if_pin_4, -aml_store (build_prt_entry ("LNKS" ), route)); - } -aml_append (if_device_1, if_pin_4); - else_pin_4 =aml_else (); - { -aml_append (else_pin_4, -aml_store (build_prt_entry ("LNKA" ), route)); - } -aml_append (if_device_1, else_pin_4); - } -aml_append (while_ctx, if_device_1); - }else { -aml_append (while_ctx,initialize_route (route,"LNKA" , lnk_idx,1 )); - } -aml_append (while_ctx,initialize_route (route,"LNKB" , lnk_idx,2 )); -aml_append (while_ctx,initialize_route (route,"LNKC" , lnk_idx,3 )); - -/* route[0] = 0x[slot]FFFF */ -aml_append (while_ctx, -aml_store (aml_or (aml_shiftleft (slot,aml_int (16 )),aml_int (0xFFFF ), -NULL ), -aml_index (route,aml_int (0 )))); -/* route[1] = pin & 3 */ -aml_append (while_ctx, -aml_store (aml_and (pin,aml_int (3 ),NULL ), -aml_index (route,aml_int (1 )))); -/* res[pin] = route */ -aml_append (while_ctx,aml_store (route,aml_index (res, pin))); -/* pin++ */ -aml_append (while_ctx,aml_increment (pin)); - } -aml_append (method, while_ctx); -/* return res*/ -aml_append (method,aml_return (res)); - -return method; -} - -typedef struct CrsRangeEntry { -uint64_t base; -uint64_t limit; -}CrsRangeEntry ; - -static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) -{ -CrsRangeEntry *entry; - - entry =g_malloc (sizeof (*entry)); - entry->base = base; - entry->limit = limit; - -g_ptr_array_add (ranges, entry); -} - -static void crs_range_free (gpointer data) -{ -CrsRangeEntry *entry = (CrsRangeEntry *)data; -g_free (entry); -} - -typedef struct CrsRangeSet { -GPtrArray *io_ranges; -GPtrArray *mem_ranges; -GPtrArray *mem_64bit_ranges; - }CrsRangeSet ; - -static void crs_range_set_init (CrsRangeSet *range_set) -{ - range_set->io_ranges =g_ptr_array_new_with_free_func (crs_range_free); - range_set->mem_ranges =g_ptr_array_new_with_free_func (crs_range_free); - range_set->mem_64bit_ranges = -g_ptr_array_new_with_free_func (crs_range_free); -} - -static void crs_range_set_free (CrsRangeSet *range_set) -{ -g_ptr_array_free (range_set->io_ranges, true); -g_ptr_array_free (range_set->mem_ranges, true); -g_ptr_array_free (range_set->mem_64bit_ranges, true); -} - -static gint crs_range_compare (gconstpointer a,gconstpointer b) -{ -CrsRangeEntry *entry_a = *(CrsRangeEntry **)a; -CrsRangeEntry *entry_b = *(CrsRangeEntry **)b; - -return (int64_t )entry_a->base - (int64_t )entry_b->base; -} - -/* -* crs_replace_with_free_ranges - given the 'used' ranges within [start - end] -* interval, computes the 'free' ranges from the same interval. -* Example: If the input array is { [a1 - a2],[b1 - b2] }, the function -* will return { [base - a1], [a2 - b1], [b2 - limit] }. -*/ -static void crs_replace_with_free_ranges (GPtrArray *ranges, -uint64_t start,uint64_t end) -{ -GPtrArray *free_ranges =g_ptr_array_new (); -uint64_t free_base = start; -int i; - -g_ptr_array_sort (ranges, crs_range_compare); -for (i =0 ; i < ranges->len; i++) { -CrsRangeEntry *used =g_ptr_array_index (ranges, i); - -if (free_base < used->base) { -crs_range_insert (free_ranges, free_base, used->base -1 ); - } - - free_base = used->limit +1 ; - } - -if (free_base < end) { -crs_range_insert (free_ranges, free_base, end); - } - -g_ptr_array_set_size (ranges,0 ); -for (i =0 ; i < free_ranges->len; i++) { -g_ptr_array_add (ranges,g_ptr_array_index (free_ranges, i)); - } - -g_ptr_array_free (free_ranges, true); -} - -/* -* crs_range_merge - merges adjacent ranges in the given array. -* Array elements are deleted and replaced with the merged ranges. -*/ -static void crs_range_merge (GPtrArray *range) -{ -GPtrArray *tmp =g_ptr_array_new_with_free_func (crs_range_free); -CrsRangeEntry *entry; -uint64_t range_base, range_limit; -int i; - -if (!range->len) { -return ; - } - -g_ptr_array_sort (range, crs_range_compare); - - entry =g_ptr_array_index (range,0 ); - range_base = entry->base; - range_limit = entry->limit; -for (i =1 ; i < range->len; i++) { - entry =g_ptr_array_index (range, i); -if (entry->base -1 == range_limit) { - range_limit = entry->limit; - }else { -crs_range_insert (tmp, range_base, range_limit); - range_base = entry->base; - range_limit = entry->limit; - } - } -crs_range_insert (tmp, range_base, range_limit); - -g_ptr_array_set_size (range,0 ); -for (i =0 ; i < tmp->len; i++) { - entry =g_ptr_array_index (tmp, i); -crs_range_insert (range, entry->base, entry->limit); - } -g_ptr_array_free (tmp, true); -} - -static Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set) -{ -Aml *crs =aml_resource_template (); -CrsRangeSet temp_range_set; -CrsRangeEntry *entry; -uint8_t max_bus =pci_bus_num (host->bus); -uint8_t type; -int devfn; -int i; - -crs_range_set_init (&temp_range_set); -for (devfn =0 ; devfn <ARRAY_SIZE (host->bus->devices); devfn++) { -uint64_t range_base, range_limit; -PCIDevice *dev = host->bus->devices[devfn]; - -if (!dev) { -continue ; - } - -for (i =0 ; i <PCI_NUM_REGIONS ; i++) { -PCIIORegion *r = &dev->io_regions[i]; - - range_base = r->addr; - range_limit = r->addr + r->size -1 ; - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (!range_base || range_base > range_limit) { -continue ; - } - -if (r->type &PCI_BASE_ADDRESS_SPACE_IO ) { -crs_range_insert (temp_range_set.io_ranges, - range_base, range_limit); - }else {/* "memory" */ -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - } - } - - type = dev->config[PCI_HEADER_TYPE ] & ~PCI_HEADER_TYPE_MULTI_FUNCTION ; -if (type ==PCI_HEADER_TYPE_BRIDGE ) { -uint8_t subordinate = dev->config[PCI_SUBORDINATE_BUS ]; -if (subordinate > max_bus) { - max_bus = subordinate; - } - - range_base =pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_IO ); - range_limit =pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_IO ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -crs_range_insert (temp_range_set.io_ranges, - range_base, range_limit); - } - - range_base = -pci_bridge_get_base (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); - range_limit = -pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_SPACE_MEMORY ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -uint64_t length = range_limit - range_base +1 ; -if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - }else { -crs_range_insert (temp_range_set.mem_64bit_ranges, - range_base, range_limit); - } - } - - range_base = -pci_bridge_get_base (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); - range_limit = -pci_bridge_get_limit (dev,PCI_BASE_ADDRESS_MEM_PREFETCH ); - -/* -* Work-around for old bioses -* that do not support multiple root buses -*/ -if (range_base && range_base <= range_limit) { -uint64_t length = range_limit - range_base +1 ; -if (range_limit <=UINT32_MAX && length <=UINT32_MAX ) { -crs_range_insert (temp_range_set.mem_ranges, - range_base, range_limit); - }else { -crs_range_insert (temp_range_set.mem_64bit_ranges, - range_base, range_limit); - } - } - } - } - -crs_range_merge (temp_range_set.io_ranges); -for (i =0 ; i < temp_range_set.io_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.io_ranges, i); -aml_append (crs, -aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , -AML_POS_DECODE ,AML_ENTIRE_RANGE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->io_ranges, entry->base, entry->limit); - } - -crs_range_merge (temp_range_set.mem_ranges); -for (i =0 ; i < temp_range_set.mem_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.mem_ranges, i); -aml_append (crs, -aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED , -AML_MAX_FIXED ,AML_NON_CACHEABLE , -AML_READ_WRITE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->mem_ranges, entry->base, entry->limit); - } - -crs_range_merge (temp_range_set.mem_64bit_ranges); -for (i =0 ; i < temp_range_set.mem_64bit_ranges->len; i++) { - entry =g_ptr_array_index (temp_range_set.mem_64bit_ranges, i); -aml_append (crs, -aml_qword_memory (AML_POS_DECODE ,AML_MIN_FIXED , -AML_MAX_FIXED ,AML_NON_CACHEABLE , -AML_READ_WRITE , -0 , entry->base, entry->limit,0 , - entry->limit - entry->base +1 )); -crs_range_insert (range_set->mem_64bit_ranges, - entry->base, entry->limit); - } - -crs_range_set_free (&temp_range_set); - -aml_append (crs, -aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , -0 , -pci_bus_num (host->bus), - max_bus, -0 , - max_bus -pci_bus_num (host->bus) +1 )); - -return crs; -} -static void build_hpet_aml (Aml *table) {Aml *crs;@@ -1334,37 +930,6 @@ static Aml *build_link_dev(const char *name, uint8_t uid, Aml *reg)return dev; } -static Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi) -{ -Aml *dev; -Aml *crs; -Aml *method; -uint32_t irqs; - - dev =aml_device ("%s" , name); -aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0C0F" ))); -aml_append (dev,aml_name_decl ("_UID" ,aml_int (uid))); - - crs =aml_resource_template (); - irqs = gsi; -aml_append (crs,aml_interrupt (AML_CONSUMER ,AML_LEVEL ,AML_ACTIVE_HIGH , -AML_SHARED , &irqs,1 )); -aml_append (dev,aml_name_decl ("_PRS" , crs)); - -aml_append (dev,aml_name_decl ("_CRS" , crs)); - -/* -* _DIS can be no-op because the interrupt cannot be disabled. -*/ - method =aml_method ("_DIS" ,0 ,AML_NOTSERIALIZED ); -aml_append (dev, method); - - method =aml_method ("_SRS" ,1 ,AML_NOTSERIALIZED ); -aml_append (dev, method); - -return dev; -} -/* _CRS method - get current settings */ static Aml *build_iqcr_method (bool is_piix4) {@@ -1728,54 +1293,6 @@ static void build_piix4_pci_hotplug(Aml *table)aml_append (table, scope); } -static Aml *build_q35_osc_method (void ) -{ -Aml *if_ctx; -Aml *if_ctx2; -Aml *else_ctx; -Aml *method; -Aml *a_cwd1 =aml_name ("CDW1" ); -Aml *a_ctrl =aml_local (0 ); - - method =aml_method ("_OSC" ,4 ,AML_NOTSERIALIZED ); -aml_append (method,aml_create_dword_field (aml_arg (3 ),aml_int (0 ),"CDW1" )); - - if_ctx =aml_if (aml_equal ( -aml_arg (0 ),aml_touuid ("33DB4D5B-1FF7-401C-9657-7441C03DD766" ))); -aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (4 ),"CDW2" )); -aml_append (if_ctx,aml_create_dword_field (aml_arg (3 ),aml_int (8 ),"CDW3" )); - -aml_append (if_ctx,aml_store (aml_name ("CDW3" ), a_ctrl)); - -/* -* Always allow native PME, AER (no dependencies) -* Allow SHPC (PCI bridges can have SHPC controller) -*/ -aml_append (if_ctx,aml_and (a_ctrl,aml_int (0x1F ), a_ctrl)); - - if_ctx2 =aml_if (aml_lnot (aml_equal (aml_arg (1 ),aml_int (1 )))); -/* Unknown revision */ -aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x08 ), a_cwd1)); -aml_append (if_ctx, if_ctx2); - - if_ctx2 =aml_if (aml_lnot (aml_equal (aml_name ("CDW3" ), a_ctrl))); -/* Capabilities bits were masked */ -aml_append (if_ctx2,aml_or (a_cwd1,aml_int (0x10 ), a_cwd1)); -aml_append (if_ctx, if_ctx2); - -/* Update DWORD3 in the buffer */ -aml_append (if_ctx,aml_store (a_ctrl,aml_name ("CDW3" ))); -aml_append (method, if_ctx); - - else_ctx =aml_else (); -/* Unrecognized UUID */ -aml_append (else_ctx,aml_or (a_cwd1,aml_int (4 ), a_cwd1)); -aml_append (method, else_ctx); - -aml_append (method,aml_return (aml_arg (3 ))); -return method; -} - static void build_dsdt(GArray *table_data, BIOSLinker *linker, AcpiPmInfo *pm, AcpiMiscInfo *misc,@@ -1818,7 +1335,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_CID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_ADR" ,aml_int (0 )));aml_append (dev,aml_name_decl ("_UID" ,aml_int (1 ))); -aml_append (dev,build_q35_osc_method ()); +aml_append (dev,build_osc_method ());aml_append (sb_scope, dev);aml_append (dsdt, sb_scope);@@ -1883,7 +1400,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num)));if (pci_bus_is_express (bus)) { -aml_append (dev,build_q35_osc_method ()); +aml_append (dev,build_osc_method ()); }if (numa_node !=NUMA_NODE_UNASSIGNED ) {@@ -2370,35 +1887,6 @@ build_srat(GArray *table_data, BIOSLinker *linker, table_data->len - srat_start, 1, NULL, NULL); } -static void -build_mcfg_q35 (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info) -{ -AcpiTableMcfg *mcfg; -const char *sig; -int len =sizeof (*mcfg) +1 *sizeof (mcfg->allocation[0 ]); - - mcfg =acpi_data_push (table_data, len); - mcfg->allocation[0 ].address =cpu_to_le64 (info->mcfg_base); -/* Only a single allocation so no need to play with segments */ - mcfg->allocation[0 ].pci_segment =cpu_to_le16 (0 ); - mcfg->allocation[0 ].start_bus_number =0 ; - mcfg->allocation[0 ].end_bus_number =PCIE_MMCFG_BUS (info->mcfg_size -1 ); - -/* MCFG is used for ECAM which can be enabled or disabled by guest. -* To avoid table size changes (which create migration issues), -* always create the table even if there are no allocations, -* but set the signature to a reserved value in this case. -* ACPI spec requires OSPMs to ignore such tables. -*/ -if (info->mcfg_base ==PCIE_BASE_ADDR_UNMAPPED ) { -/* Reserved signature: ignored by OSPM */ - sig ="QEMU" ; - }else { - sig ="MCFG" ; - } -build_header (linker, table_data, (void *)mcfg, sig, len,1 ,NULL ,NULL ); -} -/* * VT-d spec 8.1 DMA Remapping Reporting Structure * (version Oct. 2014 or later) @@ -2626,7 +2114,7 @@ void acpi_build(AcpiBuildTables *tables, }if (acpi_get_mcfg (&mcfg)) {acpi_add_table (table_offsets, tables_blob); -build_mcfg_q35 (tables_blob, tables->linker, &mcfg); +build_mcfg (tables_blob, tables->linker, &mcfg); }if (x86_iommu_get_default ()) {IommuType IOMMUType =x86_iommu_get_type ();
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 07/24] hw: acpi: Generalize AML build routines
Hi Igor,
Quoted 33 lines · Igor Mammedov
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:30 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
Most of the AML build routines under acpi-build are not even architecture specific. They can be moved to the more generic hw/acpi folder where they could be shared across machine types and architectures.
I'd prefer if won't pull into aml-build PCI specific headers, Suggest to create
hw/acpi/pci.cand move generic PCI related code there, with corresponding header the would export API (preferably without PCI dependencies in it)Also patch is too big and does too much at a time.
Here I'd suggest to split it in smaller parts to make it more digestible1. split it in 3 parts
* MCFG
* CRS
* PTR
2. mcfg between x86 and ARM look pretty much the same with ARM open codding bus number calculation and missing migration hack
* a patch to make bus number calculation in ARM the same as x86
* a patch to bring migration hack (dummy MCFG table in case it's disabled) it's questionable if we actually need it in generic,
we most likely need it for legacy machines that predate resizable MemeoryRegion, but we probably don't need it for later machines as problem doesn't exists there.
So it might be better to push hack out from generic code
to a legacy caller and keep generic MCFG clean.
Quoted 8 lines
(this patch might be better at the beginning of the series as
it might affect acpi test results, and might need an update to reference tables I don't really sure)
* at this point arm and x86 impl. would be the same so
a patch to move mcfg build routine to a generic place and replace x86/arm with a single impl.
* a patch to convert mcfg build routine tobuild_append_int_noprefix()API and drop AcpiTableMcfg structure
Ok, I'll build another patch serie for that one then.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 8/24 hw: acpi: Factorize _OSC AML across architectures
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
The _OSC AML table is almost identical between the i386 Q35 and arm virt machine types. We can make it slightly more generic and share it across all PCIe architectures.
--- include/hw/acpi/acpi-defs.h | 14 +++++++ include/hw/acpi/aml-build.h | 2 +- hw/acpi/aml-build.c | 84 +++++++++++++++++++------------------ hw/arm/virt-acpi-build.c | 45 ++------------------ hw/i386/acpi-build.c | 6 ++- 5 files changed, 66 insertions(+), 85 deletions(-)
include/hw/acpi/acpi-defs.h +14 -0
@@ -652,4 +652,18 @@ struct AcpiIortRC { } QEMU_PACKED;typedef struct AcpiIortRC AcpiIortRC ; +/* _OSC */ + +#define ACPI_OSC_CTRL_PCIE_NATIVE_HP (1 << 0) +#define ACPI_OSC_CTRL_SHPC_NATIVE_HP (1 << 1) +#define ACPI_OSC_CTRL_PCIE_PM_EVT (1 << 2) +#define ACPI_OSC_CTRL_PCIE_AER (1 << 3) +#define ACPI_OSC_CTRL_PCIE_CAP_CTRL (1 << 4) +#define ACPI_OSC_CTRL_PCI_ALL \ + (ACPI_OSC_CTRL_PCIE_NATIVE_HP | \ + ACPI_OSC_CTRL_SHPC_NATIVE_HP | \ + ACPI_OSC_CTRL_PCIE_PM_EVT | \ + ACPI_OSC_CTRL_PCIE_AER | \ + ACPI_OSC_CTRL_PCIE_CAP_CTRL) +#endif
include/hw/acpi/aml-build.h +1 -1
@@ -405,7 +405,7 @@ void acpi_align_size(GArray *blob, unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);void acpi_build_tables_init (AcpiBuildTables *tables);void acpi_build_tables_cleanup (AcpiBuildTables *tables,bool mfre); -Aml *build_osc_method (void ); +Aml *build_osc_method (uint32_t value);void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info);Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi);Aml *build_prt (bool is_pci0_prt);
hw/acpi/aml-build.c +44 -40
95 lines not on this page · raw message
hw/arm/virt-acpi-build.c +3 -42
57 lines not on this page · raw message
hw/i386/acpi-build.c +4 -2
@@ -1335,7 +1335,9 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_CID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_ADR" ,aml_int (0 )));aml_append (dev,aml_name_decl ("_UID" ,aml_int (1 ))); -aml_append (dev,build_osc_method ()); +aml_append (dev,aml_name_decl ("SUPP" ,aml_int (0 ))); +aml_append (dev,aml_name_decl ("CTRL" ,aml_int (0 ))); +aml_append (dev,build_osc_method (ACPI_OSC_CTRL_PCI_ALL ));aml_append (sb_scope, dev);aml_append (dsdt, sb_scope);
@@ -1400,7 +1402,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" )));aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num)));if (pci_bus_is_express (bus)) { -aml_append (dev,build_osc_method ()); +aml_append (dev,build_osc_method (ACPI_OSC_CTRL_PCI_ALL )); }if (numa_node !=NUMA_NODE_UNASSIGNED ) {
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 9/24 hw: i386: Move PCI host definitions to pci_host.h
In reply to Samuel OrtizThe PCI hole properties are not pc or i386 specific. They belong to the PCI host header instead.
--- include/hw/i386/pc.h | 5 ----- include/hw/pci/pci_host.h | 6 ++++++ 2 files changed, 6 insertions(+), 5 deletions(-)
include/hw/i386/pc.h +0 -5
@@ -182,11 +182,6 @@ void pc_acpi_init(const char *default_dsdt);void pc_guest_info_init (PCMachineState *pcms); -#define PCI_HOST_PROP_PCI_HOLE_START "pci-hole-start" -#define PCI_HOST_PROP_PCI_HOLE_END "pci-hole-end" -#define PCI_HOST_PROP_PCI_HOLE64_START "pci-hole64-start" -#define PCI_HOST_PROP_PCI_HOLE64_END "pci-hole64-end" -#define PCI_HOST_PROP_PCI_HOLE64_SIZE "pci-hole64-size"#define PCI_HOST_BELOW_4G_MEM_SIZE "below-4g-mem-size"#define PCI_HOST_ABOVE_4G_MEM_SIZE "above-4g-mem-size"
include/hw/pci/pci_host.h +6 -0
@@ -38,6 +38,12 @@#define PCI_HOST_BRIDGE_GET_CLASS (obj) \ OBJECT_GET_CLASS(PCIHostBridgeClass, (obj), TYPE_PCI_HOST_BRIDGE) +#define PCI_HOST_PROP_PCI_HOLE_START "pci-hole-start" +#define PCI_HOST_PROP_PCI_HOLE_END "pci-hole-end" +#define PCI_HOST_PROP_PCI_HOLE64_START "pci-hole64-start" +#define PCI_HOST_PROP_PCI_HOLE64_END "pci-hole64-end" +#define PCI_HOST_PROP_PCI_HOLE64_SIZE "pci-hole64-size" +struct PCIHostState {SysBusDevice busdev;
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 09/24] hw: i386: Move PCI host definitions to pci_host.h
Quoted 30 lines · On Mon, 5 Nov 2018 02:40:32 +0100 Samuel Ortiz <[email protected]> wrote:
The PCI hole properties are not pc or i386 specific. They belong to the PCI host header instead.
Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/i386/pc.h | 5 ----- include/hw/pci/pci_host.h | 6 ++++++ 2 files changed, 6 insertions(+), 5 deletions(-)include/hw/i386/pc.h +0
-5@@ -182,11 +182,6 @@ void pc_acpi_init(const char *default_dsdt);void pc_guest_info_init (PCMachineState *pcms); -#define PCI_HOST_PROP_PCI_HOLE_START "pci-hole-start" -#define PCI_HOST_PROP_PCI_HOLE_END "pci-hole-end" -#define PCI_HOST_PROP_PCI_HOLE64_START "pci-hole64-start" -#define PCI_HOST_PROP_PCI_HOLE64_END "pci-hole64-end" -#define PCI_HOST_PROP_PCI_HOLE64_SIZE "pci-hole64-size"#define PCI_HOST_BELOW_4G_MEM_SIZE "below-4g-mem-size"#define PCI_HOST_ABOVE_4G_MEM_SIZE "above-4g-mem-size"include/hw/pci/pci_host.h +0
-0
include/hw/pci/pci_host.h line 45
Quoted 8 lines
include/hw/pci/pci_host.h +5
-0@@ -38,6 +38,12 @@#define PCI_HOST_BRIDGE_GET_CLASS (obj) \ OBJECT_GET_CLASS(PCIHostBridgeClass, (obj), TYPE_PCI_HOST_BRIDGE) +#define PCI_HOST_PROP_PCI_HOLE_START "pci-hole-start" +#define PCI_HOST_PROP_PCI_HOLE_END "pci-hole-end" +#define PCI_HOST_PROP_PCI_HOLE64_START "pci-hole64-start" +#define PCI_HOST_PROP_PCI_HOLE64_END "pci-hole64-end" +#define PCI_HOST_PROP_PCI_HOLE64_SIZE "pci-hole64-size"
these are pc/q53 machine specific properties and do not belong here
include/hw/pci/pci_host.h line 49
Quoted 4 lines
include/hw/pci/pci_host.h +1
-0+struct PCIHostState {SysBusDevice busdev;
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 10/24 hw: acpi: Export the PCI host and holes getters
In reply to Samuel OrtizThis is going to be needed by the hardware reduced implementation, so let's export it.
Once the ACPI builder methods and getters will be implemented, the acpi_get_pci_host() implementation will become hardware agnostic.
--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 43 +++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 47 ++----------------------------------- 3 files changed, 47 insertions(+), 45 deletions(-)
include/hw/acpi/aml-build.h +2 -0
@@ -400,6 +400,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +Object *acpi_get_pci_host (void ); +void acpi_get_pci_holes (Range *hole,Range *hole64);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);
hw/acpi/aml-build.c +43 -0
49 lines not on this page · raw message
hw/i386/acpi-build.c +2 -45
65 lines not on this page · raw message
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 10/24] hw: acpi: Export the PCI host and holes getters
Quoted 41 lines · On Mon, 5 Nov 2018 02:40:33 +0100 Samuel Ortiz <[email protected]> wrote:
This is going to be needed by the hardware reduced implementation, so let's export it.
Once the ACPI builder methods and getters will be implemented, theacpi_get_pci_host()implementation will become hardware agnostic.Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 43 +++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 47 ++----------------------------------- 3 files changed, 47 insertions(+), 45 deletions(-)include/hw/acpi/aml-build.h +2
-0@@ -400,6 +400,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +Object *acpi_get_pci_host (void ); +void acpi_get_pci_holes (Range *hole,Range *hole64);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);hw/acpi/aml-build.c +8
-0@@ -1601,6 +1601,49 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } +/* +* Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE. +*/ +Object *acpi_get_pci_host (void ) +{ +PCIHostState *host; + + host = OBJECT_CHECK(PCIHostState,
hw/acpi/aml-build.c void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre) · line 1621
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+object_resolve_path ("/machine/i440fx" ,NULL ), + TYPE_PCI_HOST_BRIDGE); +if (!host) { + host =OBJECT_CHECK (PCIHostState, +object_resolve_path ("/machine/q35" ,NULL ), +TYPE_PCI_HOST_BRIDGE ); + } + +return OBJECT (host); +}
in general aml-build.c is a place to put ACPI spec primitives, so I'd suggest to move it somewhere else.
Considering it's x86 code (so far), maybe move it to something like hw/i386/acpi-pci.c
Also it might be good to get rid of acpi_get_pci_host() and pass a pointer to pci_host as acpi_setup() an argument, since it's static for life of boar we can keep it in AcpiBuildState, and reuse for mfg/pci_hole/pci bus accesses.
That way we can simplify code a bit and avoid lookup cost of object_resolve_path() that's called several times unnecessarily.
Quoted 90 lines
hw/acpi/aml-build.c +23
-0+void acpi_get_pci_holes (Range *hole,Range *hole64) +{ +Object *pci_host; + + pci_host =acpi_get_pci_host (); +g_assert (pci_host); + +range_set_bounds1 (hole, +object_property_get_uint (pci_host, +PCI_HOST_PROP_PCI_HOLE_START , +NULL ), +object_property_get_uint (pci_host, +PCI_HOST_PROP_PCI_HOLE_END , +NULL )); +range_set_bounds1 (hole64, +object_property_get_uint (pci_host, +PCI_HOST_PROP_PCI_HOLE64_START , +NULL ), +object_property_get_uint (pci_host, +PCI_HOST_PROP_PCI_HOLE64_END , +NULL )); +} +static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) {CrsRangeEntry *entry;hw/i386/acpi-build.c +1
-44@@ -232,49 +232,6 @@ static void acpi_get_misc_info(AcpiMiscInfo *info) info->applesmc_io_base =applesmc_port (); } -/* -* Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE. -* On i386 arch we only have two pci hosts, so we can look only for them. -*/ -static Object *acpi_get_i386_pci_host (void ) -{ -PCIHostState *host; - - host =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/i440fx" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); -if (!host) { - host =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/q35" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); - } - -return OBJECT (host); -} - -static void acpi_get_pci_holes (Range *hole,Range *hole64) -{ -Object *pci_host; - - pci_host =acpi_get_i386_pci_host (); -g_assert (pci_host); - -range_set_bounds1 (hole, -object_property_get_uint (pci_host, -PCI_HOST_PROP_PCI_HOLE_START , -NULL ), -object_property_get_uint (pci_host, -PCI_HOST_PROP_PCI_HOLE_END , -NULL )); -range_set_bounds1 (hole64, -object_property_get_uint (pci_host, -PCI_HOST_PROP_PCI_HOLE64_START , -NULL ), -object_property_get_uint (pci_host, -PCI_HOST_PROP_PCI_HOLE64_END , -NULL )); -} -/* FACS */ static void build_facs (GArray *table_data,BIOSLinker *linker)@@ -1634,7 +1591,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,Object *pci_host;PCIBus *bus =NULL ; - pci_host =acpi_get_i386_pci_host (); + pci_host =acpi_get_pci_host ();if (pci_host) { bus =PCI_HOST_BRIDGE (pci_host)->bus; }
hw/i386/acpi-build.c static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg) · line 1971
Quoted 8 lines
hw/i386/acpi-build.c +1
-1@@ -2008,7 +1965,7 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)Object *pci_host;QObject *o; - pci_host =acpi_get_i386_pci_host (); + pci_host =acpi_get_pci_host ();g_assert (pci_host); o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_BASE ,NULL );
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 10/24] hw: acpi: Export the PCI host and holes getters
Quoted 57 lines · Igor Mammedov
Quoted 41 lines · On Mon, 5 Nov 2018 02:40:33 +0100 Samuel Ortiz <[email protected]> wrote:
This is going to be needed by the hardware reduced implementation, so let's export it.
Once the ACPI builder methods and getters will be implemented, theacpi_get_pci_host()implementation will become hardware agnostic.Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 43 +++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 47 ++----------------------------------- 3 files changed, 47 insertions(+), 45 deletions(-)include/hw/acpi/aml-build.h +2
-0@@ -400,6 +400,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +Object *acpi_get_pci_host (void ); +void acpi_get_pci_holes (Range *hole,Range *hole64);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);hw/acpi/aml-build.c +8
-0@@ -1601,6 +1601,49 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } +/* +* Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE. +*/ +Object *acpi_get_pci_host (void ) +{ +PCIHostState *host; + + host = OBJECT_CHECK(PCIHostState,hw/acpi/aml-build.c void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre) · line 1621
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+object_resolve_path ("/machine/i440fx" ,NULL ), + TYPE_PCI_HOST_BRIDGE); +if (!host) { + host =OBJECT_CHECK (PCIHostState, +object_resolve_path ("/machine/q35" ,NULL ), +TYPE_PCI_HOST_BRIDGE ); + } + +return OBJECT (host); +}in general
aml-build.cis a place to put ACPI spec primitives, so I'd suggest to move it somewhere else.
Quoted 7 lines
Considering it's x86 code (so far), maybe move it to something like
hw/i386/acpi-pci.cAlso it might be good to get rid of
acpi_get_pci_host()and pass a pointer topci_hostasacpi_setup()an argument, since it's static for life of boar we can keep it in AcpiBuildState, and reuse for mfg/pci_hole/pci bus accesses.
That's what I'm trying to do with patches #23 and 24, but through the ACPI configuration structure. I could try using the build state instead, as it's platform agnostic as well.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 10/24] hw: acpi: Export the PCI host and holes getters
Quoted 61 lines · On Wed, 21 Nov 2018 16:43:12 +0100 Samuel Ortiz <[email protected]> wrote:
Quoted 60 lines · Igor Mammedov
Quoted 41 lines · On Mon, 5 Nov 2018 02:40:33 +0100 Samuel Ortiz <[email protected]> wrote:
This is going to be needed by the hardware reduced implementation, so let's export it.
Once the ACPI builder methods and getters will be implemented, theacpi_get_pci_host()implementation will become hardware agnostic.Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 2 ++ hw/acpi/aml-build.c | 43 +++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 47 ++----------------------------------- 3 files changed, 47 insertions(+), 45 deletions(-)include/hw/acpi/aml-build.h +2
-0@@ -400,6 +400,8 @@ build_header(BIOSLinker *linker, GArray *table_data, const char *oem_id, const char *oem_table_id);void *acpi_data_push (GArray *table_data,unsigned size);unsigned acpi_data_len (GArray *table); +Object *acpi_get_pci_host (void ); +void acpi_get_pci_holes (Range *hole,Range *hole64);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);hw/acpi/aml-build.c +8
-0@@ -1601,6 +1601,49 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } +/* +* Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE. +*/ +Object *acpi_get_pci_host (void ) +{ +PCIHostState *host; + + host = OBJECT_CHECK(PCIHostState,hw/acpi/aml-build.c void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre) · line 1621
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+object_resolve_path ("/machine/i440fx" ,NULL ), + TYPE_PCI_HOST_BRIDGE); +if (!host) { + host =OBJECT_CHECK (PCIHostState, +object_resolve_path ("/machine/q35" ,NULL ), +TYPE_PCI_HOST_BRIDGE ); + } + +return OBJECT (host); +}in general
aml-build.cis a place to put ACPI spec primitives, so I'd suggest to move it somewhere else.Considering it's x86 code (so far), maybe move it to something like
hw/i386/acpi-pci.c
Quoted 7 lines
Quoted 4 lines
Also it might be good to get rid of
acpi_get_pci_host()and pass a pointer topci_hostasacpi_setup()an argument, since it's static for life of boar we can keep it in AcpiBuildState, and reuse for mfg/pci_hole/pci bus accesses.That's what I'm trying to do with patches #23 and 24, but through the ACPI configuration structure. I could try using the build state instead, as it's platform agnostic as well.
May be it will work.
Note:
try not to pass whole build_state to concrete tables builders and use arguments/dedicated structures to pass data needed for that concrete table.
Quoted 4 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 11/24 hw: acpi: Export and generalize the PCI host AML API
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
The AML build routines for the PCI host bridge and the corresponding DSDT addition are neither x86 nor PC machine type specific. We can move them to the architecture agnostic hw/acpi folder, and by carrying all the needed information through a new AcpiPciBus structure, we can make them PC machine type independent.
--- include/hw/acpi/aml-build.h | 8 ++ hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 115 ++------------------------ 3 files changed, 173 insertions(+), 107 deletions(-)
include/hw/acpi/aml-build.h +8 -0
@@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo {uint32_t mcfg_size; } AcpiMcfgInfo; +typedef struct AcpiPciBus { +PCIBus *pci_bus; +Range *pci_hole; +Range *pci_hole64; +}AcpiPciBus ; + typedef struct CrsRangeEntry { uint64_t base; uint64_t limit;
@@ -411,6 +417,8 @@ Aml *build_osc_method(uint32_t value);void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info);Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi);Aml *build_prt (bool is_pci0_prt); +void acpi_dsdt_add_pci_bus (Aml *dsdt,AcpiPciBus *pci_host); +Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host);void crs_range_set_init (CrsRangeSet *range_set);Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); void crs_replace_with_free_ranges(GPtrArray *ranges,
hw/acpi/aml-build.c +157 -0
169 lines not on this page · raw message
hw/i386/acpi-build.c +8 -107
149 lines not on this page · raw message
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 11/24] hw: acpi: Export and generalize the PCI host AML API
Quoted 7 lines · On Mon, 5 Nov 2018 02:40:34 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The AML build routines for the PCI host bridge and the corresponding DSDT addition are neither x86 nor PC machine type specific. We can move them to the architecture agnostic hw/acpi folder, and by carrying all the needed information through a new AcpiPciBus structure, we can make them PC machine type independent.
I'm don't know anything about PCI, but functional changes doesn't look correct to me. See more detailed comments below.
Marcel,
could you take a look on this patch (in particular main csr changes), pls?
Quoted 15 lines
Signed-off-by Yang Zhong <[email protected]>Signed-off-by Rob Bradford <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 8 ++ hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 115 ++------------------------ 3 files changed, 173 insertions(+), 107 deletions(-)include/hw/acpi/aml-build.h +0
-0
include/hw/acpi/aml-build.h typedef struct AcpiMcfgInfo { · line 236
Quoted 8 lines
include/hw/acpi/aml-build.h +5
-0@@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo {uint32_t mcfg_size; } AcpiMcfgInfo; +typedef struct AcpiPciBus { +PCIBus *pci_bus; +Range *pci_hole; +Range *pci_hole64; +}AcpiPciBus ;
Again, this and all below is not aml-build material. Consider adding/using pci specific acpi file for it.
Also even though pci AML in arm/virt is to a large degree a subset of x86 target and it would be much better to unify ARM part with x86, it probably will be to big/complex of a change if we take on it in one go.
So not to derail you from the goal too much, we probably should generalize this a little bit less, limiting refactoring to x86 target for now.
For example, move generic x86 pci parts to hw/i386/acpi-pci.[hc], and structure it so that building blocks in acpi-pci.c could be reused for x86 reduced profile later.
Once it's been done, it might be easier and less complex to unify a bit more generic code in i386/acpi-pci.c with corresponding ARM code.
Patch is too big and should be split into smaller logical chunks and you should separate code movement vs functional changes you're a making here.
Once you split patch properly, it should be easier to assess changes.
Quoted 37 lines
include/hw/acpi/aml-build.h +2
-0typedef struct CrsRangeEntry { uint64_t base; uint64_t limit;@@ -411,6 +417,8 @@ Aml *build_osc_method(uint32_t value);void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info);Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi);Aml *build_prt (bool is_pci0_prt); +void acpi_dsdt_add_pci_bus (Aml *dsdt,AcpiPciBus *pci_host); +Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host);void crs_range_set_init (CrsRangeSet *range_set);Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); void crs_replace_with_free_ranges(GPtrArray *ranges,hw/acpi/aml-build.c +13
-0@@ -29,6 +29,19 @@#include "hw/pci/pci_bus.h" #include "qemu/range.h" #include "hw/pci/pci_bridge.h" +#include "hw/i386/pc.h" +#include "sysemu/tpm.h" +#include "hw/acpi/tpm.h" + +#define PCI_HOST_BRIDGE_CONFIG_ADDR 0xcf8 +#define PCI_HOST_BRIDGE_IO_0_MIN_ADDR 0x0000 +#define PCI_HOST_BRIDGE_IO_0_MAX_ADDR 0x0cf7 +#define PCI_HOST_BRIDGE_IO_1_MIN_ADDR 0x0d00 +#define PCI_HOST_BRIDGE_IO_1_MAX_ADDR 0xffff +#define PCI_VGA_MEM_BASE_ADDR 0x000a0000 +#define PCI_VGA_MEM_MAX_ADDR 0x000bffff +#define IO_0_LEN 0xcf8 +#define VGA_MEM_LEN 0x20000static GArray *build_alloc_array (void ) {
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2158
Quoted 4 lines
hw/acpi/aml-build.c +1
-0@@ -2142,6 +2155,150 @@ Aml *build_prt(bool is_pci0_prt)return method; } +Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host)
name doesn't reflect exactly what function does,
it builds device descriptions for expander buses (including their csr) and then it builds csr for for main pci host but not pci device description.
I'd suggest to split out expander buses part into separate function that returns an expander bus device description, updates crs_range_set and let the caller to enumerate buses and add descriptions to dsdt.
Then after it we could do a generic csr generation function for the main pci host if it's possible at all (main pci host csr seems heavily board depended)
Instead of taking table and adding stuff directly in to it
it should be cleaner to take as argument empty csr (crs = aml_resource_template();) add stuff to it and let the caller to add/extend csr as/where necessary.
Quoted 47 lines
hw/acpi/aml-build.c +47
-0+{ +CrsRangeEntry *entry; +Aml *scope, *dev, *crs; +CrsRangeSet crs_range_set; +Range *pci_hole =NULL ; +Range *pci_hole64 =NULL ; +PCIBus *bus =NULL ; +int root_bus_limit =0xFF ; +int i; + + bus = pci_host->pci_bus; +assert (bus); + pci_hole = pci_host->pci_hole; + pci_hole64 = pci_host->pci_hole64; + +crs_range_set_init (&crs_range_set); + QLIST_FOREACH(bus, &bus->child, sibling) { +uint8_t bus_num =pci_bus_num (bus); +uint8_t numa_node =pci_bus_numa_node (bus); + +/* look only for expander root buses */ +if (!pci_bus_is_root (bus)) { +continue ; + } + +if (bus_num < root_bus_limit) { + root_bus_limit = bus_num -1 ; + } + + scope =aml_scope ("\\_SB" ); + dev =aml_device ("PC%.02X" , bus_num); +aml_append (dev,aml_name_decl ("_UID" ,aml_int (bus_num))); +aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" ))); +aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num))); +if (pci_bus_is_express (bus)) { +aml_append (dev,aml_name_decl ("SUPP" ,aml_int (0 ))); +aml_append (dev,aml_name_decl ("CTRL" ,aml_int (0 ))); +aml_append (dev,build_osc_method (0x1F )); + } +if (numa_node !=NUMA_NODE_UNASSIGNED ) { +aml_append (dev,aml_name_decl ("_PXM" ,aml_int (numa_node))); + } + +aml_append (dev,build_prt (false)); + crs =build_crs (PCI_HOST_BRIDGE (BUS (bus)->parent), &crs_range_set); +aml_append (dev,aml_name_decl ("_CRS" , crs)); +aml_append (scope, dev);
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2215
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+aml_append (table, scope); + } + scope =aml_scope ("\\_SB.PCI0" ); +/* build PCI0._CRS */ + crs =aml_resource_template (); +/* set the pcie bus num */ +aml_append (crs, +aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , +0x0000 ,0x0 , root_bus_limit, +0x0000 , root_bus_limit +1 ));
vvvv
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2228
Quoted 13 lines
hw/acpi/aml-build.c +13
-0+aml_append (crs,aml_io (AML_DECODE16 ,PCI_HOST_BRIDGE_CONFIG_ADDR , +PCI_HOST_BRIDGE_CONFIG_ADDR ,0x01 ,0x08 )); +/* set the io region 0 in pci host bridge */ +aml_append (crs, +aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , +AML_POS_DECODE ,AML_ENTIRE_RANGE , +0x0000 ,PCI_HOST_BRIDGE_IO_0_MIN_ADDR , +PCI_HOST_BRIDGE_IO_0_MAX_ADDR ,0x0000 ,IO_0_LEN )); + +/* set the io region 1 in pci host bridge */ +crs_replace_with_free_ranges (crs_range_set.io_ranges, +PCI_HOST_BRIDGE_IO_1_MIN_ADDR , +PCI_HOST_BRIDGE_IO_1_MAX_ADDR );
above code doesn't look as just a movement, it's something totally new, so it should be in it's own patch with a justification why it's ok to replace concrete addresses with some kind of window.
Quoted 6 lines
hw/acpi/aml-build.c +6
-0+for (i =0 ; i < crs_range_set.io_ranges->len; i++) { + entry =g_ptr_array_index (crs_range_set.io_ranges, i); + aml_append(crs, + aml_word_io(AML_MIN_FIXED, AML_MAX_FIXED, + AML_POS_DECODE, AML_ENTIRE_RANGE, + 0x0000, entry->base, entry->limit,
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2243
Quoted 10 lines
hw/acpi/aml-build.c +9
-0+ 0x0000, entry->limit - entry->base + 1)); + } + +/* set the vga mem region(0) in pci host bridge */ +aml_append (crs, +aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED ,AML_MAX_FIXED , +AML_CACHEABLE ,AML_READ_WRITE , +0 ,PCI_VGA_MEM_BASE_ADDR ,PCI_VGA_MEM_MAX_ADDR , +0 ,VGA_MEM_LEN ));
this part doesn't look generic enough.
I'd assume new shiny i386/virt won't have VGA and
assuming one day we would reuse this code for ARM it probably doesn't make sense to put it in generic code.
Quoted 23 lines
hw/acpi/aml-build.c +23
-0+ +/* set the mem region 1 in pci host bridge */ +crs_replace_with_free_ranges (crs_range_set.mem_ranges, +range_lob (pci_hole), +range_upb (pci_hole)); +for (i =0 ; i < crs_range_set.mem_ranges->len; i++) { + entry =g_ptr_array_index (crs_range_set.mem_ranges, i); +aml_append (crs, +aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED ,AML_MAX_FIXED , +AML_NON_CACHEABLE ,AML_READ_WRITE , +0 , entry->base, entry->limit, +0 , entry->limit - entry->base +1 )); + } + +/* set the mem region 2 in pci host bridge */ +if (!range_is_empty (pci_hole64)) { +crs_replace_with_free_ranges (crs_range_set.mem_64bit_ranges, +range_lob (pci_hole64), +range_upb (pci_hole64)); +for (i =0 ; i < crs_range_set.mem_64bit_ranges->len; i++) { + entry =g_ptr_array_index (crs_range_set.mem_64bit_ranges, i); + aml_append(crs, + aml_qword_memory(AML_POS_DECODE, AML_MIN_FIXED,
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2276
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+AML_MAX_FIXED , +AML_CACHEABLE ,AML_READ_WRITE , +0 , entry->base, entry->limit, + 0, entry->limit - entry->base + 1)); + } + } + +if (TPM_IS_TIS (tpm_find ())) { +aml_append (crs,aml_memory32_fixed (TPM_TIS_ADDR_BASE , +TPM_TIS_ADDR_SIZE ,AML_READ_WRITE ));
ditto, board depended and not generic enough to go here
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2284
Quoted 8 lines
hw/acpi/aml-build.c +8
-0+ } + +aml_append (scope,aml_name_decl ("_CRS" , crs)); +crs_range_set_free (&crs_range_set); +return scope; +} + +void acpi_dsdt_add_pci_bus (Aml *dsdt,AcpiPciBus *pci_host)
not used in this patch, drop it for now.
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2295
Quoted 11 lines
hw/acpi/aml-build.c +11
-0+{ +Aml *dev, *pci_scope; + + dev =aml_device ("\\_SB.PCI0" ); +aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A08" ))); +aml_append (dev,aml_name_decl ("_CID" ,aml_eisaid ("PNP0A03" ))); +aml_append (dev,aml_name_decl ("_ADR" ,aml_int (0 ))); +aml_append (dev,aml_name_decl ("_UID" ,aml_int (1 ))); +aml_append (dev,aml_name_decl ("SUPP" ,aml_int (0 ))); +aml_append (dev,aml_name_decl ("CTRL" ,aml_int (0 ))); +aml_append (dev,build_osc_method (0x1F ));
Does above description applicable to all boards (pc/q35/future i386/virt)? current code builds PCI differently depending on board.
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2296
Quoted 1 line
hw/acpi/aml-build.c +1
-0+aml_append (dsdt, dev);
it would be better to return PCI dev and let caller to add it to dsdt.
Quoted 158 lines
hw/acpi/aml-build.c +5
-0+ + pci_scope =build_pci_host_bridge (dsdt, pci_host); +aml_append (dsdt, pci_scope); +} +/* Build rsdt table */ void build_rsdt(GArray
*table_data, BIOSLinker *linker, GArray*table_offsets,hw/i386/acpi-build.c +7
-106@@ -1253,16 +1253,11 @@ static void build_piix4_pci_hotplug(Aml *table)static void build_dsdt (GArray *table_data,BIOSLinker *linker,AcpiPmInfo *pm,AcpiMiscInfo *misc, -Range *pci_hole,Range *pci_hole64, +AcpiPciBus *pci_host,MachineState *machine,AcpiConfiguration *acpi_conf) { -CrsRangeEntry *entry;Aml *dsdt, *sb_scope, *scope, *dev, *method, *field, *pkg, *crs; -CrsRangeSet crs_range_set;uint32_t nr_mem = machine->ram_slots; -int root_bus_limit =0xFF ; -PCIBus *bus =NULL ; -int i; dsdt =init_aml_allocator ();@@ -1337,104 +1332,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, }aml_append (dsdt, scope); -crs_range_set_init (&crs_range_set); - bus =PC_MACHINE (machine)->bus; -if (bus) { - QLIST_FOREACH(bus, &bus->child, sibling) { -uint8_t bus_num =pci_bus_num (bus); -uint8_t numa_node =pci_bus_numa_node (bus); - -/* look only for expander root buses */ -if (!pci_bus_is_root (bus)) { -continue ; - } - -if (bus_num < root_bus_limit) { - root_bus_limit = bus_num -1 ; - } - - scope =aml_scope ("\\_SB" ); - dev =aml_device ("PC%.02X" , bus_num); -aml_append (dev,aml_name_decl ("_UID" ,aml_int (bus_num))); -aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" ))); -aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num))); -if (pci_bus_is_express (bus)) { -aml_append (dev,build_osc_method (ACPI_OSC_CTRL_PCI_ALL )); - } - -if (numa_node !=NUMA_NODE_UNASSIGNED ) { -aml_append (dev,aml_name_decl ("_PXM" ,aml_int (numa_node))); - } - -aml_append (dev,build_prt (false)); - crs =build_crs (PCI_HOST_BRIDGE (BUS (bus)->parent), &crs_range_set); -aml_append (dev,aml_name_decl ("_CRS" , crs)); -aml_append (scope, dev); -aml_append (dsdt, scope); - } - } - - scope =aml_scope ("\\_SB.PCI0" ); -/* build PCI0._CRS */ - crs =aml_resource_template (); -aml_append (crs, -aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , -0x0000 ,0x0 , root_bus_limit, -0x0000 , root_bus_limit +1 )); -aml_append (crs,aml_io (AML_DECODE16 ,0x0CF8 ,0x0CF8 ,0x01 ,0x08 )); - -aml_append (crs, -aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , -AML_POS_DECODE ,AML_ENTIRE_RANGE , -0x0000 ,0x0000 ,0x0CF7 ,0x0000 ,0x0CF8 )); - -crs_replace_with_free_ranges (crs_range_set.io_ranges,0x0D00 ,0xFFFF ); -for (i =0 ; i < crs_range_set.io_ranges->len; i++) { - entry =g_ptr_array_index (crs_range_set.io_ranges, i); -aml_append (crs, -aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , -AML_POS_DECODE ,AML_ENTIRE_RANGE , -0x0000 , entry->base, entry->limit, -0x0000 , entry->limit - entry->base +1 )); - } - -aml_append (crs, -aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED ,AML_MAX_FIXED , -AML_CACHEABLE ,AML_READ_WRITE , -0 ,0x000A0000 ,0x000BFFFF ,0 ,0x00020000 )); - -crs_replace_with_free_ranges (crs_range_set.mem_ranges, -range_lob (pci_hole), -range_upb (pci_hole)); -for (i =0 ; i < crs_range_set.mem_ranges->len; i++) { - entry =g_ptr_array_index (crs_range_set.mem_ranges, i); -aml_append (crs, -aml_dword_memory (AML_POS_DECODE ,AML_MIN_FIXED ,AML_MAX_FIXED , -AML_NON_CACHEABLE ,AML_READ_WRITE , -0 , entry->base, entry->limit, -0 , entry->limit - entry->base +1 )); - } - -if (!range_is_empty (pci_hole64)) { -crs_replace_with_free_ranges (crs_range_set.mem_64bit_ranges, -range_lob (pci_hole64), -range_upb (pci_hole64)); -for (i =0 ; i < crs_range_set.mem_64bit_ranges->len; i++) { - entry =g_ptr_array_index (crs_range_set.mem_64bit_ranges, i); -aml_append (crs, -aml_qword_memory (AML_POS_DECODE ,AML_MIN_FIXED , -AML_MAX_FIXED , -AML_CACHEABLE ,AML_READ_WRITE , -0 , entry->base, entry->limit, -0 , entry->limit - entry->base +1 )); - } - } - -if (TPM_IS_TIS (tpm_find ())) { -aml_append (crs,aml_memory32_fixed (TPM_TIS_ADDR_BASE , -TPM_TIS_ADDR_SIZE ,AML_READ_WRITE )); - } -aml_append (scope,aml_name_decl ("_CRS" , crs)); + scope =build_pci_host_bridge (dsdt, pci_host);/* reserve GPE0 block resources */ dev =aml_device ("GPE0" );@@ -1454,8 +1352,6 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,aml_append (dev,aml_name_decl ("_CRS" , crs));aml_append (scope, dev); -crs_range_set_free (&crs_range_set); -/* reserve PCIHP resources */ if (pm->pcihp_io_len) { dev =aml_device ("PHPR" );@@ -2012,6 +1908,11 @@ void acpi_build(AcpiBuildTables *tables,64 /* Ensure FACS is aligned */ , false /* high memory */); +AcpiPciBus pci_host = { + .pci_bus =PC_MACHINE (machine)->bus, + .pci_hole = &pci_hole, + .pci_hole64 = &pci_hole64, + };/* * FACS is pointed to by FADT. * We place it first since it's the only table that has alignment
hw/i386/acpi-build.c void acpi_build(AcpiBuildTables *tables, · line 1930
Quoted 8 lines
hw/i386/acpi-build.c +1
-1@@ -2023,7 +1924,7 @@ void acpi_build(AcpiBuildTables *tables,/* DSDT is pointed to by FADT */ dsdt = tables_blob->len;build_dsdt (tables_blob, tables->linker, &pm, &misc, - &pci_hole, &pci_hole64, machine, acpi_conf); + &pci_host, machine, acpi_conf);/* Count the size of the DSDT and SSDT, we will need it for legacy * sizing of ACPI tables.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 11/24] hw: acpi: Export and generalize the PCI host AML API
Hi Igor,
Quoted 45 lines · Igor Mammedov
Quoted 7 lines · On Mon, 5 Nov 2018 02:40:34 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The AML build routines for the PCI host bridge and the corresponding DSDT addition are neither x86 nor PC machine type specific. We can move them to the architecture agnostic hw/acpi folder, and by carrying all the needed information through a new AcpiPciBus structure, we can make them PC machine type independent.
I'm don't know anything about PCI, but functional changes doesn't look correct to me.
See more detailed comments below.
Marcel,
could you take a look on this patch (in particular main csr changes), pls?Quoted 15 lines
Signed-off-by Yang Zhong <[email protected]>Signed-off-by Rob Bradford <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 8 ++ hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 115 ++------------------------ 3 files changed, 173 insertions(+), 107 deletions(-)include/hw/acpi/aml-build.h +0
-0include/hw/acpi/aml-build.h typedef struct AcpiMcfgInfo { · line 236
Quoted 8 lines
include/hw/acpi/aml-build.h +5
-0@@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo {uint32_t mcfg_size; } AcpiMcfgInfo; +typedef struct AcpiPciBus { +PCIBus *pci_bus; +Range *pci_hole; +Range *pci_hole64; +}AcpiPciBus ;Again, this and all below is not aml-build material. Consider adding/using pci specific acpi file for it.
Quoted 8 lines
Also even though pci AML in arm/virt is to a large degree a subset of x86 target and it would be much better to unify ARM part with x86, it probably will be to big/complex of a change if we take on it in one go.
So not to derail you from the goal too much, we probably should generalize this a little bit less, limiting refactoring to x86 target for now.
So keeping it under i386 means it won't be accessible through hw/acpi/, which means we won't be able to have a generic hw/acpi/reduced.c implementation. From our perspective, this is the problem with keeping things under i386 because we're not sure yet how much generic it is: It still won't be shareable for a generic hardware-reduced ACPI implementation which means we'll have to temporarily have yet another hardware-reduced ACPI implementation under hw/i386 this time. I guess this is what Michael meant by keeping some parts of the code duplicated for now.
I feel it'd be easier to move those APIs under a shareable location, to make it easier for ARM to consume it even if it's not entirely generic yet. But you guys are the maintainers and if you think we should restric the generalization to x86 only for now, we can go for it.
Quoted 142 lines
For example, move generic x86 pci parts to hw/i386/acpi-pci.[hc], and structure it so that building blocks in
acpi-pci.ccould be reused for x86 reduced profile later.
Once it's been done, it might be easier and less complex to unify a bit more generic code ini386/acpi-pci.cwith corresponding ARM code.Patch is too big and should be split into smaller logical chunks and you should separate code movement vs functional changes you're a making here.
Once you split patch properly, it should be easier to assess changes.
Quoted 37 lines
include/hw/acpi/aml-build.h +2
-0typedef struct CrsRangeEntry { uint64_t base; uint64_t limit;@@ -411,6 +417,8 @@ Aml *build_osc_method(uint32_t value);void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info);Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi);Aml *build_prt (bool is_pci0_prt); +void acpi_dsdt_add_pci_bus (Aml *dsdt,AcpiPciBus *pci_host); +Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host);void crs_range_set_init (CrsRangeSet *range_set);Aml *build_crs (PCIHostState *host,CrsRangeSet *range_set); void crs_replace_with_free_ranges(GPtrArray *ranges,hw/acpi/aml-build.c +13
-0@@ -29,6 +29,19 @@#include "hw/pci/pci_bus.h" #include "qemu/range.h" #include "hw/pci/pci_bridge.h" +#include "hw/i386/pc.h" +#include "sysemu/tpm.h" +#include "hw/acpi/tpm.h" + +#define PCI_HOST_BRIDGE_CONFIG_ADDR 0xcf8 +#define PCI_HOST_BRIDGE_IO_0_MIN_ADDR 0x0000 +#define PCI_HOST_BRIDGE_IO_0_MAX_ADDR 0x0cf7 +#define PCI_HOST_BRIDGE_IO_1_MIN_ADDR 0x0d00 +#define PCI_HOST_BRIDGE_IO_1_MAX_ADDR 0xffff +#define PCI_VGA_MEM_BASE_ADDR 0x000a0000 +#define PCI_VGA_MEM_MAX_ADDR 0x000bffff +#define IO_0_LEN 0xcf8 +#define VGA_MEM_LEN 0x20000static GArray *build_alloc_array (void ) {hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2158
Quoted 4 lines
hw/acpi/aml-build.c +1
-0@@ -2142,6 +2155,150 @@ Aml *build_prt(bool is_pci0_prt)return method; } +Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host)name doesn't reflect exactly what function does,
it builds device descriptions for expander buses (including their csr) and then it builds csr for for main pci host but not pci device description.I'd suggest to split out expander buses part into separate function that returns an expander bus device description, updates
crs_range_setand let the caller to enumerate buses and add descriptions to dsdt.Then after it we could do a generic csr generation function for the main pci host if it's possible at all (main pci host csr seems heavily board depended)
Instead of taking table and adding stuff directly in to it
it should be cleaner to take as argument empty csr (crs =aml_resource_template();) add stuff to it and let the caller to add/extend csr as/where necessary.Quoted 47 lines
hw/acpi/aml-build.c +47
-0+{ +CrsRangeEntry *entry; +Aml *scope, *dev, *crs; +CrsRangeSet crs_range_set; +Range *pci_hole =NULL ; +Range *pci_hole64 =NULL ; +PCIBus *bus =NULL ; +int root_bus_limit =0xFF ; +int i; + + bus = pci_host->pci_bus; +assert (bus); + pci_hole = pci_host->pci_hole; + pci_hole64 = pci_host->pci_hole64; + +crs_range_set_init (&crs_range_set); + QLIST_FOREACH(bus, &bus->child, sibling) { +uint8_t bus_num =pci_bus_num (bus); +uint8_t numa_node =pci_bus_numa_node (bus); + +/* look only for expander root buses */ +if (!pci_bus_is_root (bus)) { +continue ; + } + +if (bus_num < root_bus_limit) { + root_bus_limit = bus_num -1 ; + } + + scope =aml_scope ("\\_SB" ); + dev =aml_device ("PC%.02X" , bus_num); +aml_append (dev,aml_name_decl ("_UID" ,aml_int (bus_num))); +aml_append (dev,aml_name_decl ("_HID" ,aml_eisaid ("PNP0A03" ))); +aml_append (dev,aml_name_decl ("_BBN" ,aml_int (bus_num))); +if (pci_bus_is_express (bus)) { +aml_append (dev,aml_name_decl ("SUPP" ,aml_int (0 ))); +aml_append (dev,aml_name_decl ("CTRL" ,aml_int (0 ))); +aml_append (dev,build_osc_method (0x1F )); + } +if (numa_node !=NUMA_NODE_UNASSIGNED ) { +aml_append (dev,aml_name_decl ("_PXM" ,aml_int (numa_node))); + } + +aml_append (dev,build_prt (false)); + crs =build_crs (PCI_HOST_BRIDGE (BUS (bus)->parent), &crs_range_set); +aml_append (dev,aml_name_decl ("_CRS" , crs)); +aml_append (scope, dev);hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2215
Quoted 10 lines
hw/acpi/aml-build.c +10
-0+aml_append (table, scope); + } + scope =aml_scope ("\\_SB.PCI0" ); +/* build PCI0._CRS */ + crs =aml_resource_template (); +/* set the pcie bus num */ +aml_append (crs, +aml_word_bus_number (AML_MIN_FIXED ,AML_MAX_FIXED ,AML_POS_DECODE , +0x0000 ,0x0 , root_bus_limit, +0x0000 , root_bus_limit +1 ));vvvv
hw/acpi/aml-build.c Aml *build_prt(bool is_pci0_prt) · line 2228
Quoted 13 lines
hw/acpi/aml-build.c +13
-0+aml_append (crs,aml_io (AML_DECODE16 ,PCI_HOST_BRIDGE_CONFIG_ADDR , +PCI_HOST_BRIDGE_CONFIG_ADDR ,0x01 ,0x08 )); +/* set the io region 0 in pci host bridge */ +aml_append (crs, +aml_word_io (AML_MIN_FIXED ,AML_MAX_FIXED , +AML_POS_DECODE ,AML_ENTIRE_RANGE , +0x0000 ,PCI_HOST_BRIDGE_IO_0_MIN_ADDR , +PCI_HOST_BRIDGE_IO_0_MAX_ADDR ,0x0000 ,IO_0_LEN )); + +/* set the io region 1 in pci host bridge */ +crs_replace_with_free_ranges (crs_range_set.io_ranges, +PCI_HOST_BRIDGE_IO_1_MIN_ADDR , +PCI_HOST_BRIDGE_IO_1_MAX_ADDR );
Quoted 3 lines
above code doesn't look as just a movement, it's something totally new, so it should be in it's own patch with a justification why it's ok to replace concrete addresses with some kind of window.
Ah I see your point now. Yes, I agree this should be in a separate patch.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 11/24] hw: acpi: Export and generalize the PCI host AML API
Quoted 66 lines · On Thu, 22 Nov 2018 00:12:17 +0100 Samuel Ortiz <[email protected]> wrote:
Hi Igor,
Quoted 45 lines · Igor Mammedov
Quoted 7 lines · On Mon, 5 Nov 2018 02:40:34 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The AML build routines for the PCI host bridge and the corresponding DSDT addition are neither x86 nor PC machine type specific. We can move them to the architecture agnostic hw/acpi folder, and by carrying all the needed information through a new AcpiPciBus structure, we can make them PC machine type independent.
I'm don't know anything about PCI, but functional changes doesn't look correct to me.
See more detailed comments below.
Marcel,
could you take a look on this patch (in particular main csr changes), pls?Quoted 15 lines
Signed-off-by Yang Zhong <[email protected]>Signed-off-by Rob Bradford <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/aml-build.h | 8 ++ hw/acpi/aml-build.c | 157 ++++++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 115 ++------------------------ 3 files changed, 173 insertions(+), 107 deletions(-)include/hw/acpi/aml-build.h +0
-0include/hw/acpi/aml-build.h typedef struct AcpiMcfgInfo { · line 236
Quoted 8 lines
include/hw/acpi/aml-build.h +5
-0@@ -229,6 +229,12 @@ typedef struct AcpiMcfgInfo {uint32_t mcfg_size; } AcpiMcfgInfo; +typedef struct AcpiPciBus { +PCIBus *pci_bus; +Range *pci_hole; +Range *pci_hole64; +}AcpiPciBus ;Again, this and all below is not aml-build material. Consider adding/using pci specific acpi file for it.
Quoted 8 lines
Also even though pci AML in arm/virt is to a large degree a subset of x86 target and it would be much better to unify ARM part with x86, it probably will be to big/complex of a change if we take on it in one go.
So not to derail you from the goal too much, we probably should generalize this a little bit less, limiting refactoring to x86 target for now.
So keeping it under i386 means it won't be accessible through hw/acpi/, which means we won't be able to have a generic
hw/acpi/reduced.cimplementation. From our perspective, this is the problem with keeping things under i386 because we're not sure yet how much generic it is: It still won't be shareable for a generic hardware-reduced ACPI implementation which means we'll have to temporarily have yet another hardware-reduced ACPI implementation under hw/i386 this time. I guess this is what Michael meant by keeping some parts of the code duplicated for now.
Quoted 4 lines
I feel it'd be easier to move those APIs under a shareable location, to make it easier for ARM to consume it even if it's not entirely generic yet. But you guys are the maintainers and if you think we should restric the generalization to x86 only for now, we can go for it.
If code is generic (you can reuse it with arm/virt in the same series) then place it in hw/acpi otherwise if it's semi-generic put to hw/i386. If it would be a separate file it would be easier to move it to generic place when we are able to resuse it with arm/virt.
Quoted 2 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 12/24 hw: acpi: Export the MCFG getter
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
The ACPI MCFG getter is not x86 specific and could be called from anywhere within generic ACPI API, so let's export it.
--- include/hw/acpi/aml-build.h | 1 + hw/acpi/aml-build.c | 24 ++++++++++++++++++++++++ hw/i386/acpi-build.c | 22 ---------------------- 3 files changed, 25 insertions(+), 22 deletions(-)
include/hw/acpi/aml-build.h +1 -0
@@ -408,6 +408,7 @@ void *acpi_data_push(GArray *table_data, unsigned size);unsigned acpi_data_len (GArray *table);Object *acpi_get_pci_host (void );void acpi_get_pci_holes (Range *hole,Range *hole64); +bool acpi_get_mcfg (AcpiMcfgInfo *mcfg);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);
hw/acpi/aml-build.c +24 -0
@@ -32,6 +32,8 @@#include "hw/i386/pc.h" #include "sysemu/tpm.h" #include "hw/acpi/tpm.h" +#include "qom/qom-qobject.h" +#include "qapi/qmp/qnum.h" #define PCI_HOST_BRIDGE_CONFIG_ADDR 0xcf8#define PCI_HOST_BRIDGE_IO_0_MIN_ADDR 0x0000
@@ -1657,6 +1659,28 @@ void acpi_get_pci_holes(Range *hole, Range *hole64) NULL)); } +bool acpi_get_mcfg (AcpiMcfgInfo *mcfg) +{ +Object *pci_host; +QObject *o; + + pci_host =acpi_get_pci_host (); +g_assert (pci_host); + + o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_BASE ,NULL ); +if (!o) { +return false; + } + mcfg->mcfg_base =qnum_get_uint (qobject_to (QNum, o)); +qobject_unref (o); + + o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_SIZE ,NULL ); +assert (o); + mcfg->mcfg_size =qnum_get_uint (qobject_to (QNum, o)); +qobject_unref (o); +return true; +} +static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) {CrsRangeEntry *entry;
hw/i386/acpi-build.c +0 -22
@@ -1856,28 +1856,6 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -static bool acpi_get_mcfg (AcpiMcfgInfo *mcfg) -{ -Object *pci_host; -QObject *o; - - pci_host =acpi_get_pci_host (); -g_assert (pci_host); - - o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_BASE ,NULL ); -if (!o) { -return false; - } - mcfg->mcfg_base =qnum_get_uint (qobject_to (QNum, o)); -qobject_unref (o); - - o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_SIZE ,NULL ); -assert (o); - mcfg->mcfg_size =qnum_get_uint (qobject_to (QNum, o)); -qobject_unref (o); -return true; -} -static void acpi_build (AcpiBuildTables *tables,MachineState *machine,AcpiConfiguration *acpi_conf)
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 12/24] hw: acpi: Export the MCFG getter
Quoted 4 lines · On Mon, 5 Nov 2018 02:40:35 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The ACPI MCFG getter is not x86 specific and could be called from anywhere within generic ACPI API, so let's export it.
So far it's x86 or more exactly q35 specific thing, for example it won't work with arm/virt without refactoring the later.
We probably over-engineered it and could get by without properties here at all, but that's not related to this series.
So for now I'd suggest to move it to x86/acpi-pci.c for now and we can generalize the way we get address/size later, but if you feel like replacing all this property complications and making it simpler go ahead.
Quoted 35 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Yang Zhong <[email protected]>--- include/hw/acpi/aml-build.h | 1 + hw/acpi/aml-build.c | 24 ++++++++++++++++++++++++ hw/i386/acpi-build.c | 22 ---------------------- 3 files changed, 25 insertions(+), 22 deletions(-)include/hw/acpi/aml-build.h +1
-0@@ -408,6 +408,7 @@ void *acpi_data_push(GArray *table_data, unsigned size);unsigned acpi_data_len (GArray *table);Object *acpi_get_pci_host (void );void acpi_get_pci_holes (Range *hole,Range *hole64); +bool acpi_get_mcfg (AcpiMcfgInfo *mcfg);/* Align AML blob size to a multiple of 'align' */ void acpi_align_size (GArray *blob,unsigned align);void acpi_add_table (GArray *table_offsets,GArray *table_data);hw/acpi/aml-build.c +2
-0@@ -32,6 +32,8 @@#include "hw/i386/pc.h" #include "sysemu/tpm.h" #include "hw/acpi/tpm.h" +#include "qom/qom-qobject.h" +#include "qapi/qmp/qnum.h" #define PCI_HOST_BRIDGE_CONFIG_ADDR 0xcf8#define PCI_HOST_BRIDGE_IO_0_MIN_ADDR 0x0000
hw/acpi/aml-build.c void acpi_get_pci_holes(Range *hole, Range *hole64) · line 1667
Quoted 9 lines
hw/acpi/aml-build.c +6
-0@@ -1657,6 +1659,28 @@ void acpi_get_pci_holes(Range *hole, Range *hole64) NULL)); } +bool acpi_get_mcfg (AcpiMcfgInfo *mcfg) +{ +Object *pci_host; +QObject *o; + + pci_host =acpi_get_pci_host ();
it would be better to get bus from struct AcpiPciBus
instead of doing lookup again. (that's a separate patch from moving function around)
Quoted 42 lines
hw/acpi/aml-build.c +16
-0+g_assert (pci_host); + + o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_BASE ,NULL ); +if (!o) { +return false; + } + mcfg->mcfg_base =qnum_get_uint (qobject_to (QNum, o)); +qobject_unref (o); + + o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_SIZE ,NULL ); +assert (o); + mcfg->mcfg_size =qnum_get_uint (qobject_to (QNum, o)); +qobject_unref (o); +return true; +} +static void crs_range_insert (GPtrArray *ranges,uint64_t base,uint64_t limit) {CrsRangeEntry *entry;hw/i386/acpi-build.c +0
-15@@ -1856,28 +1856,6 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker) "IVRS", table_data->len - iommu_start, 1, NULL, NULL); } -static bool acpi_get_mcfg (AcpiMcfgInfo *mcfg) -{ -Object *pci_host; -QObject *o; - - pci_host =acpi_get_pci_host (); -g_assert (pci_host); - - o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_BASE ,NULL ); -if (!o) { -return false; - } - mcfg->mcfg_base =qnum_get_uint (qobject_to (QNum, o)); -qobject_unref (o); -
hw/i386/acpi-build.c build_amd_iommu(GArray *table_data, BIOSLinker *linker) · line 1861
Quoted 10 lines
hw/i386/acpi-build.c +0
-7- o =object_property_get_qobject (pci_host,PCIE_HOST_MCFG_SIZE ,NULL ); -assert (o); - mcfg->mcfg_size =qnum_get_uint (qobject_to (QNum, o)); -qobject_unref (o); -return true; -} -static void acpi_build (AcpiBuildTables *tables,MachineState *machine,AcpiConfiguration *acpi_conf)
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 12/24] hw: acpi: Export the MCFG getter
Hi Igor,
Quoted 8 lines · Igor Mammedov
Quoted 4 lines · On Mon, 5 Nov 2018 02:40:35 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The ACPI MCFG getter is not x86 specific and could be called from anywhere within generic ACPI API, so let's export it.
So far it's x86 or more exactly q35 specific thing,
It's property based, and it's using a generic PCIE property afaict. So it's up to each machine type to define those properties. I'm curious here: What's the idiomatic way to define a machine setting/attribute/property, let each instance define it or not, and make it available at run time?
Would you be getting the PCI host pointer from the ACPI build state and getting that information back from there?
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 12/24] hw: acpi: Export the MCFG getter
Quoted 10 lines · On Thu, 22 Nov 2018 00:21:06 +0100 Samuel Ortiz <[email protected]> wrote:
Hi Igor,
Quoted 7 lines · Igor Mammedov
Quoted 4 lines · On Mon, 5 Nov 2018 02:40:35 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
The ACPI MCFG getter is not x86 specific and could be called from anywhere within generic ACPI API, so let's export it.
Quoted 8 lines
Quoted 1 line
So far it's x86 or more exactly q35 specific thing,
It's property based, and it's using a generic PCIE property afaict. So it's up to each machine type to define those properties. I'm curious here: What's the idiomatic way to define a machine setting/attribute/property, let each instance define it or not, and make it available at run time?
Would you be getting the PCI host pointer from the ACPI build state and getting that information back from there?
Cleaner way would be make arm/virt board set PCIE_HOST_MCFG_BASE/ PCIE_HOST_MCFG_SIZE properties and then use common build_mcfg()(in aml-build.c). Something like this:
acpi_setup_reduced()
AcpiMcfgInfo mcfg_info = {
.base = object_property_get_uint(pcie, PCIE_HOST_MCFG_BASE, NULL),
.size = object_property_get_uint(pcie, PCIE_HOST_MCFG_SIZE, NULL)
};
acpi_build() {
build_mcfg("MCFG", &info);
}
}
and for legacy q35
acpi_build() {
if (pcie) {
AcpiMcfgInfo mcfg_info = {
.base = object_property_get_uint(pcie, PCIE_HOST_MCFG_BASE, NULL),
.size = object_property_get_uint(pcie, PCIE_HOST_MCFG_SIZE, NULL)
};
if (mcfg_info.base != PCIE_BASE_ADDR_UNMAPPED)
build_mcfg("MCFG", &info);
else
/* move comment here why we are doing it */
build_mcfg("QEMU", &info);
}}
The thing I don't like about acpi_get_mcfg() is that it does lookup acpi_get_i386_pci_host() each time it's called and judges if it's PCI-E host by presence of properties.
I'd rather be explicit where PCI host be fetched once somewhere in acpi_setup() or possibly passed down from the board as an argument and board telling to i386/acpi_setup() if it's PCI or PCI-E host so we don't have to guess it in acpi code.
Quoted 2 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 13/24 hw: acpi: Do not create hotplug method when handler is not defined
In reply to Samuel OrtizCPU and memory ACPI hotplug are not necessarily handled through SCI events. For example, with Hardware-reduced ACPI, the GED device will manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML generation optional. The code will only be added when the method name is not NULL.
--- hw/acpi/cpu.c | 8 +++++--- hw/acpi/memory_hotplug.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-)
hw/acpi/cpu.c +5 -3
@@ -569,9 +569,11 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,aml_append (sb_scope, cpus_dev);aml_append (table, sb_scope); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); -aml_append (table, method); +if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); +aml_append (table, method); + }g_free (cphp_res_path); }
hw/acpi/memory_hotplug.c +7 -4
@@ -715,10 +715,13 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, }aml_append (table, dev_container); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method, -aml_call0 (MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD )); -aml_append (table, method); +if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method, +aml_call0 (MEMORY_DEVICES_CONTAINER "." +MEMORY_SLOT_SCAN_METHOD )); +aml_append (table, method); + }g_free (mhp_res_path); }
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 13/24] hw: acpi: Do not create hotplug method when handler is not defined
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:36 +0100 Samuel Ortiz <[email protected]> wrote:
CPU and memory ACPI hotplug are not necessarily handled through SCI events. For example, with Hardware-reduced ACPI, the GED device will manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML generation optional. The code will only be added when the method name is not NULL.
patch doesn't belong to this series, it should be go along with GED device patch.
Suggest to drop it for now.
Quoted 40 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- hw/acpi/cpu.c | 8 +++++--- hw/acpi/memory_hotplug.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-)hw/acpi/cpu.c +5
-3@@ -569,9 +569,11 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,aml_append (sb_scope, cpus_dev);aml_append (table, sb_scope); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); -aml_append (table, method); +if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); +aml_append (table, method); + }g_free (cphp_res_path); }hw/acpi/memory_hotplug.c +0
-4@@ -715,10 +715,13 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, }aml_append (table, dev_container); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method, -aml_call0 (MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD )); -aml_append (table, method);
hw/acpi/memory_hotplug.c void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, · line 727
Quoted 10 lines
hw/acpi/memory_hotplug.c +7
-0+if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method, +aml_call0 (MEMORY_DEVICES_CONTAINER "." +MEMORY_SLOT_SCAN_METHOD )); +aml_append (table, method); + }g_free (mhp_res_path); }
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 13/24] hw: acpi: Do not create hotplug method when handler is not defined
In reply to Samuel OrtizQuoted 6 lines · On Mon, 5 Nov 2018 02:40:36 +0100 Samuel Ortiz <[email protected]> wrote:
CPU and memory ACPI hotplug are not necessarily handled through SCI events. For example, with Hardware-reduced ACPI, the GED device will manage ACPI hotplug entirely.
As a consequence, we make the CPU and memory specific events AML generation optional. The code will only be added when the method name is not NULL.
patch doesn't belong to this series, it should be go along with GED device patch.
Suggest to drop it for now.
Quoted 50 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- hw/acpi/cpu.c | 8 +++++--- hw/acpi/memory_hotplug.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-)hw/acpi/cpu.c +5
-3@@ -569,9 +569,11 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,aml_append (sb_scope, cpus_dev);aml_append (table, sb_scope); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); -aml_append (table, method); +if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method,aml_call0 ("\\_SB.CPUS." CPU_SCAN_METHOD )); +aml_append (table, method); + }g_free (cphp_res_path); }hw/acpi/memory_hotplug.c +7
-4@@ -715,10 +715,13 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, }aml_append (table, dev_container); - method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); -aml_append (method, -aml_call0 (MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD )); -aml_append (table, method); +if (event_handler_method) { + method =aml_method (event_handler_method,0 ,AML_NOTSERIALIZED ); +aml_append (method, +aml_call0 (MEMORY_DEVICES_CONTAINER "." +MEMORY_SLOT_SCAN_METHOD )); +aml_append (table, method); + }g_free (mhp_res_path); }
PATCH v5 14/24 hw: i386: Make the hotpluggable memory size property more generic
In reply to Samuel OrtizThis property is currently defined under i386/pc while it only describes a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving it to memory-device.h instead.
--- include/hw/i386/pc.h | 1 - include/hw/mem/memory-device.h | 2 ++ hw/i386/acpi-build.c | 2 +- hw/i386/pc.c | 3 ++- 4 files changed, 5 insertions(+), 3 deletions(-)
include/hw/i386/pc.h +0 -1
@@ -62,7 +62,6 @@ struct PCMachineState { };#define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device" -#define PC_MACHINE_DEVMEM_REGION_SIZE "device-memory-region-size"#define PC_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g"#define PC_MACHINE_VMPORT "vmport"#define PC_MACHINE_SMM "smm"
include/hw/mem/memory-device.h +2 -0
@@ -97,6 +97,8 @@ typedef struct MemoryDeviceClass { MemoryDeviceInfo *info); } MemoryDeviceClass; +#define MEMORY_DEVICE_REGION_SIZE "memory-device-region-size" +MemoryDeviceInfoList *qmp_memory_device_list (void );uint64_t get_plugged_memory_size (void ); void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
hw/i386/acpi-build.c +1 -1
@@ -1628,7 +1628,7 @@ build_srat(GArray *table_data, BIOSLinker *linker,MachineClass *mc =MACHINE_GET_CLASS (machine);const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids (machine);ram_addr_t hotplugabble_address_space_size = -object_property_get_int (OBJECT (machine),PC_MACHINE_DEVMEM_REGION_SIZE , +object_property_get_int (OBJECT (machine),MEMORY_DEVICE_REGION_SIZE ,NULL ); srat_start = table_data->len;
hw/i386/pc.c +2 -1
@@ -67,6 +67,7 @@#include "hw/boards.h" #include "acpi-build.h" #include "hw/mem/pc-dimm.h" +#include "hw/mem/memory-device.h" #include "qapi/error.h" #include "qapi/qapi-visit-common.h" #include "qapi/visitor.h"
@@ -2443,7 +2444,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) nc->nmi_monitor_handler = x86_nmi; mc->default_cpu_type =TARGET_DEFAULT_CPU_TYPE ; -object_class_property_add (oc,PC_MACHINE_DEVMEM_REGION_SIZE ,"int" , +object_class_property_add (oc,MEMORY_DEVICE_REGION_SIZE ,"int" , pc_machine_get_device_memory_region_size,NULL ,NULL ,NULL , &error_abort);
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 14/24] hw: i386: Make the hotpluggable memory size property more generic
Quoted 7 lines · On Mon, 5 Nov 2018 02:40:37 +0100 Samuel Ortiz <[email protected]> wrote:
This property is currently defined under i386/pc while it only describes a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving it to
memory-device.hinstead.Signed-off-by Samuel Ortiz <[email protected]>
not sure it belong to this series, but regardless where it end-ups
Quoted 58 lines
--- include/hw/i386/pc.h | 1 - include/hw/mem/memory-device.h | 2 ++ hw/i386/acpi-build.c | 2 +- hw/i386/pc.c | 3 ++- 4 files changed, 5 insertions(+), 3 deletions(-)include/hw/i386/pc.h +0
-1@@ -62,7 +62,6 @@ struct PCMachineState { };#define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device" -#define PC_MACHINE_DEVMEM_REGION_SIZE "device-memory-region-size"#define PC_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g"#define PC_MACHINE_VMPORT "vmport"#define PC_MACHINE_SMM "smm"include/hw/mem/memory-device.h +2
-0@@ -97,6 +97,8 @@ typedef struct MemoryDeviceClass { MemoryDeviceInfo *info); } MemoryDeviceClass; +#define MEMORY_DEVICE_REGION_SIZE "memory-device-region-size" +MemoryDeviceInfoList *qmp_memory_device_list (void );uint64_t get_plugged_memory_size (void ); void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,hw/i386/acpi-build.c +1
-1@@ -1628,7 +1628,7 @@ build_srat(GArray *table_data, BIOSLinker *linker,MachineClass *mc =MACHINE_GET_CLASS (machine);const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids (machine);ram_addr_t hotplugabble_address_space_size = -object_property_get_int (OBJECT (machine),PC_MACHINE_DEVMEM_REGION_SIZE , +object_property_get_int (OBJECT (machine),MEMORY_DEVICE_REGION_SIZE ,NULL ); srat_start = table_data->len;hw/i386/pc.c +1
-0@@ -67,6 +67,7 @@#include "hw/boards.h" #include "acpi-build.h" #include "hw/mem/pc-dimm.h" +#include "hw/mem/memory-device.h" #include "qapi/error.h" #include "qapi/qapi-visit-common.h" #include "qapi/visitor.h"
hw/i386/pc.c static void pc_machine_class_init(ObjectClass *oc, void *data) · line 2450
Quoted 8 lines
hw/i386/pc.c +1
-1@@ -2443,7 +2444,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) nc->nmi_monitor_handler = x86_nmi; mc->default_cpu_type =TARGET_DEFAULT_CPU_TYPE ; -object_class_property_add (oc,PC_MACHINE_DEVMEM_REGION_SIZE ,"int" , +object_class_property_add (oc,MEMORY_DEVICE_REGION_SIZE ,"int" , pc_machine_get_device_memory_region_size,NULL ,NULL ,NULL , &error_abort);
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 15/24 hw: i386: Export the i386 ACPI SRAT build method
In reply to Samuel OrtizThis is the standard way of building SRAT on x86 platfoms. But future machine types could decide to define their own custom SRAT build method through the ACPI builder methods.
Moreover, we will also need to reach build_srat() from outside of acpi-build in order to use it as the ACPI builder SRAT build method.
--- hw/i386/acpi-build.h | 5 +++++ hw/i386/acpi-build.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-)
hw/i386/acpi-build.h +5 -0
@@ -4,6 +4,11 @@#include "hw/acpi/acpi.h" +/* ACPI SRAT (Static Resource Affinity Table) build method for x86 */ +void +build_srat (GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *acpi_conf); +void acpi_setup (MachineState *machine,AcpiConfiguration *acpi_conf);#endif
hw/i386/acpi-build.c +1 -1
@@ -1615,7 +1615,7 @@ build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog)#define HOLE_640K_START (640 * KiB)#define HOLE_640K_END (1 * MiB) -static void +void build_srat (GArray *table_data,BIOSLinker *linker,MachineState *machine,AcpiConfiguration *acpi_conf) {
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 15/24] hw: i386: Export the i386 ACPI SRAT build method
Quoted 5 lines · On Mon, 5 Nov 2018 02:40:38 +0100 Samuel Ortiz <[email protected]> wrote:
This is the standard way of building SRAT on x86 platfoms. But future machine types could decide to define their own custom SRAT build method through the ACPI builder methods.
Moreover, we will also need to reachbuild_srat()from outside of acpi-build in order to use it as the ACPI builder SRAT build method.
SRAT is usually highly machine specific (memory holes, layout, guest OS specific quirks) so it's hard to generalize it.
I'd drop SRAT related patches from this series and introduce i386/virt specific SRAT when you post patches for it.
What we could generalize here is building blocks used to create entries into acpi/aml-build.c
build_srat_memory -> build_srat_memory_entry() build_apic_entry()
build_x2apic_entry()
and please switch these blocks to build_append_int_noprefix() API before moving them to acpi/aml-build.c
Quoted 27 lines
Signed-off-by Samuel Ortiz <[email protected]>--- hw/i386/acpi-build.h | 5 +++++ hw/i386/acpi-build.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-)hw/i386/acpi-build.h +5
-0@@ -4,6 +4,11 @@#include "hw/acpi/acpi.h" +/* ACPI SRAT (Static Resource Affinity Table) build method for x86 */ +void +build_srat (GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *acpi_conf); +void acpi_setup (MachineState *machine,AcpiConfiguration *acpi_conf);#endif hw/i386/acpi-build.c +0
-0
hw/i386/acpi-build.c build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog) · line 1621
Quoted 8 lines
hw/i386/acpi-build.c +1
-1@@ -1615,7 +1615,7 @@ build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog)#define HOLE_640K_START (640 * KiB)#define HOLE_640K_END (1 * MiB) -static void +void build_srat (GArray *table_data,BIOSLinker *linker,MachineState *machine,AcpiConfiguration *acpi_conf) {
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 15/24] hw: i386: Export the i386 ACPI SRAT build method
Quoted 10 lines · Igor Mammedov
Quoted 5 lines · On Mon, 5 Nov 2018 02:40:38 +0100 Samuel Ortiz <[email protected]> wrote:
This is the standard way of building SRAT on x86 platfoms. But future machine types could decide to define their own custom SRAT build method through the ACPI builder methods.
Moreover, we will also need to reachbuild_srat()from outside of acpi-build in order to use it as the ACPI builder SRAT build method.SRAT is usually highly machine specific (memory holes, layout, guest OS specific quirks) so it's hard to generalize it.
Hence the need for an SRAT builder interface.
Quoted 2 lines
I'd drop SRAT related patches from this series and introduce i386/virt specific SRAT when you post patches for it.
virt uses the existing i386 build_srat() routine, there's nothing special about it. So this would be purely duplicated code.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 15/24] hw: i386: Export the i386 ACPI SRAT build method
Quoted 4 lines · On Thu, 22 Nov 2018 00:27:33 +0100 Samuel Ortiz <[email protected]> wrote:
Quoted 3 lines · Igor Mammedov
On Mon, 5 Nov 2018 02:40:38 +0100
Samuel Ortiz <[email protected]> wrote:
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
This is the standard way of building SRAT on x86 platfoms. But future machine types could decide to define their own custom SRAT build method through the ACPI builder methods.
Moreover, we will also need to reachbuild_srat()from outside of acpi-build in order to use it as the ACPI builder SRAT build method.SRAT is usually highly machine specific (memory holes, layout, guest OS specific quirks) so it's hard to generalize it.
Hence the need for an SRAT builder interface.
so far builder interface (trying to generalize acpi_build()) looks not necessary.
I'd suggest to drop and call build_start() directly.
Quoted 4 lines
Quoted 2 lines
I'd drop SRAT related patches from this series and introduce i386/virt specific SRAT when you post patches for it.
virt uses the existing i386
build_srat()routine, there's nothing special about it. So this would be purely duplicated code.
Looking at build_srat(), it has a bunch of code to handle legacy PC layout. You probably don't need any of it for new is86/virt machine and can make simpler version of it.
In addition (probably repeating question I've asked elsewhere),
Do you have to use split initial memory model for new machine?
Is it possible to use only pc-dimms both for initial and hotplugged memory at some address (4Gb?) without cutting out PCI hole or any toher holes in RAM layout?
Quoted 3 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 16/24 hw: acpi: Fix memory hotplug AML generation error
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
When using the generated memory hotplug AML, the iasl compiler would give the following error:
dsdt.dsl 266: Return (MOST (_UID, Arg0, Arg1, Arg2)) Error 6080 - Called method returns no value ^
--- hw/acpi/memory_hotplug.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
hw/acpi/memory_hotplug.c +5 -5
@@ -686,15 +686,15 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, method =aml_method ("_OST" ,3 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_OST_METHOD ; -aml_append (method,aml_return (aml_call4 ( - s,aml_name ("_UID" ),aml_arg (0 ),aml_arg (1 ),aml_arg (2 ) - ))); +aml_append (method, +aml_call4 (s,aml_name ("_UID" ),aml_arg (0 ), +aml_arg (1 ),aml_arg (2 )));aml_append (dev, method); method =aml_method ("_EJ0" ,1 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_EJECT_METHOD ; -aml_append (method,aml_return (aml_call2 ( - s,aml_name ("_UID" ),aml_arg (0 )))); +aml_append (method, +aml_call2 (s,aml_name ("_UID" ),aml_arg (0 )));aml_append (dev, method);aml_append (dev_container, dev);
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 16/24] hw: acpi: Fix memory hotplug AML generation error
Quoted 9 lines · On Mon, 5 Nov 2018 02:40:39 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
When using the generated memory hotplug AML, the iasl compiler would give the following error:
dsdt.dsl 266: Return (MOST (
_UID, Arg0, Arg1, Arg2)) Error 6080 - Called method returns no value ^Signed-off-by Yang Zhong <[email protected]>
I suggest to put this patch at the beginning of the series before reference tables in test are updated.
Quoted 19 lines
--- hw/acpi/memory_hotplug.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)hw/acpi/memory_hotplug.c +3
-3@@ -686,15 +686,15 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, method =aml_method ("_OST" ,3 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_OST_METHOD ; -aml_append (method,aml_return (aml_call4 ( - s,aml_name ("_UID" ),aml_arg (0 ),aml_arg (1 ),aml_arg (2 ) - ))); +aml_append (method, +aml_call4 (s,aml_name ("_UID" ),aml_arg (0 ), +aml_arg (1 ),aml_arg (2 )));aml_append (dev, method);
hw/acpi/memory_hotplug.c void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, · line 700
Quoted 10 lines
hw/acpi/memory_hotplug.c +2
-2method =aml_method ("_EJ0" ,1 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_EJECT_METHOD ; -aml_append (method,aml_return (aml_call2 ( - s,aml_name ("_UID" ),aml_arg (0 )))); +aml_append (method, +aml_call2 (s,aml_name ("_UID" ),aml_arg (0 )));aml_append (dev, method);aml_append (dev_container, dev);
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 16/24] hw: acpi: Fix memory hotplug AML generation error
Quoted 8 lines · Igor Mammedov
Quoted 5 lines · On Mon, 5 Nov 2018 02:40:39 +0100 Samuel Ortiz <[email protected]> wrote:
From: Yang Zhong <[email protected]>
When using the generated memory hotplug AML, the iasl compiler would give the following error:
Quoted 8 lines
Quoted 4 lines
dsdt.dsl 266: Return (MOST (
_UID, Arg0, Arg1, Arg2)) Error 6080 - Called method returns no value ^Signed-off-by Yang Zhong <[email protected]>Reviewed-by Igor Mammedov <[email protected]>I suggest to put this patch at the beginning of the series before reference tables in test are updated.
Samuel how about a separate small series with just bugfixes for starters?
Quoted 28 lines
Quoted 28 lines
--- hw/acpi/memory_hotplug.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)hw/acpi/memory_hotplug.c +5
-5@@ -686,15 +686,15 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, method =aml_method ("_OST" ,3 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_OST_METHOD ; -aml_append (method,aml_return (aml_call4 ( - s,aml_name ("_UID" ),aml_arg (0 ),aml_arg (1 ),aml_arg (2 ) - ))); +aml_append (method, +aml_call4 (s,aml_name ("_UID" ),aml_arg (0 ), +aml_arg (1 ),aml_arg (2 )));aml_append (dev, method); method =aml_method ("_EJ0" ,1 ,AML_NOTSERIALIZED ); s =MEMORY_SLOT_EJECT_METHOD ; -aml_append (method,aml_return (aml_call2 ( - s,aml_name ("_UID" ),aml_arg (0 )))); +aml_append (method, +aml_call2 (s,aml_name ("_UID" ),aml_arg (0 )));aml_append (dev, method);
Quoted 1 line
hw/acpi/memory_hotplug.c void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem, · line 700
Quoted 1 line
hw/acpi/memory_hotplug.c +0
-0aml_append (dev_container, dev);
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 17/24 hw: acpi: Export the PCI hotplug API
In reply to Samuel OrtizFrom: Sebastien Boeuf <[email protected]>
The ACPI hotplug support for PCI devices APIs are not x86 or even machine type specific. In order for future machine types to be able to re-use that code, we export it through the architecture agnostic hw/acpi folder.
--- include/hw/acpi/aml-build.h | 3 + hw/acpi/aml-build.c | 194 ++++++++++++++++++++++++++++++++++++ hw/i386/acpi-build.c | 192 +---------------------------------- 3 files changed, 199 insertions(+), 190 deletions(-)
include/hw/acpi/aml-build.h +3 -0
@@ -418,6 +418,9 @@ Aml *build_osc_method(uint32_t value);void build_mcfg (GArray *table_data,BIOSLinker *linker,AcpiMcfgInfo *info);Aml *build_gsi_link_dev (const char *name,uint8_t uid,uint8_t gsi);Aml *build_prt (bool is_pci0_prt); +void build_acpi_pcihp (Aml *scope); +void build_append_pci_bus_devices (Aml *parent_scope,PCIBus *bus, +bool pcihp_bridge_en);void acpi_dsdt_add_pci_bus (Aml *dsdt,AcpiPciBus *pci_host);Aml *build_pci_host_bridge (Aml *table,AcpiPciBus *pci_host);void crs_range_set_init (CrsRangeSet *range_set);
hw/acpi/aml-build.c +194 -0
206 lines not on this page · raw message
hw/i386/acpi-build.c +2 -190
206 lines not on this page · raw message
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 18/24 hw: i386: Export the MADT build method
In reply to Samuel OrtizIt is going to be used by the PC machine type as the MADT table builder method and thus needs to be exported outside of acpi-build.c
Also, now that the generic build_madt() API is exported, we have to rename the ARM static one in order to avoid build time conflicts.
--- include/hw/i386/acpi.h | 28 ++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 ++-- hw/i386/acpi-build.c | 4 ++-- 3 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 include/hw/i386/acpi.h
include/hw/i386/acpi.h new file +28 -0
@@ -0,0 +1,28 @@ +/* +* +* Copyright (c) 2018 Intel Corportation +* +* 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/>. +*/ + +#ifndef HW_I386_ACPI_H +#define HW_I386_ACPI_H + +#include "hw/acpi/acpi.h" +#include "hw/acpi/bios-linker-loader.h" + +/* ACPI MADT (Multiple APIC Description Table) build method */ +void build_madt (GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); + +#endif
hw/arm/virt-acpi-build.c +2 -2
@@ -564,7 +564,7 @@ build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)/* MADT */ static void -build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {VirtMachineClass *vmc =VIRT_MACHINE_GET_CLASS (vms);int madt_start = table_data->len;
@@ -745,7 +745,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)build_fadt_rev5 (tables_blob, tables->linker, vms, dsdt);acpi_add_table (table_offsets, tables_blob); -build_madt (tables_blob, tables->linker, vms); +virt_build_madt (tables_blob, tables->linker, vms);acpi_add_table (table_offsets, tables_blob);build_gtdt (tables_blob, tables->linker, vms);
hw/i386/acpi-build.c +2 -2
@@ -35,7 +35,6 @@#include "hw/acpi/acpi.h" #include "hw/acpi/cpu.h" #include "hw/nvram/fw_cfg.h" -#include "hw/acpi/bios-linker-loader.h" #include "hw/loader.h" #include "hw/isa/isa.h" #include "hw/block/fdc.h"
@@ -60,6 +59,7 @@#include "qom/qom-qobject.h" #include "hw/i386/amd_iommu.h" #include "hw/i386/intel_iommu.h" +#include "hw/i386/acpi.h" #include "hw/acpi/ipmi.h"
@@ -279,7 +279,7 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid, } } -static void +void build_madt (GArray *table_data,BIOSLinker *linker,MachineState *ms,AcpiConfiguration *acpi_conf) {
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 18/24] hw: i386: Export the MADT build method
Quoted 21 lines · On Mon, 5 Nov 2018 02:40:41 +0100 Samuel Ortiz <[email protected]> wrote:
It is going to be used by the PC machine type as the MADT table builder method and thus needs to be exported outside of
acpi-build.cAlso, now that the generic
build_madt()API is exported, we have to rename the ARM static one in order to avoid build time conflicts.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/i386/acpi.h | 28 ++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 ++-- hw/i386/acpi-build.c | 4 ++-- 3 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 include/hw/i386/acpi.hinclude/hw/i386/acpi.h new file +0
-0
[...]
Quoted 10 lines
include/hw/i386/acpi.h new file +5
-0+/* ACPI MADT (Multiple APIC Description Table) build method */ +void build_madt (GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); + +#endif hw/arm/virt-acpi-build.c +0
-0
hw/arm/virt-acpi-build.c build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) · line 568
Quoted 6 lines
hw/arm/virt-acpi-build.c +1
-1@@ -564,7 +564,7 @@ build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)/* MADT */ static void -build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {
You are moving build_madt() into x86 specific header i386/acpi.h so question is why do you touch ARM variant at all?
[...]
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 18/24] hw: i386: Export the MADT build method
In reply to Samuel OrtizQuoted 21 lines · On Mon, 5 Nov 2018 02:40:41 +0100 Samuel Ortiz <[email protected]> wrote:
It is going to be used by the PC machine type as the MADT table builder method and thus needs to be exported outside of
acpi-build.cAlso, now that the generic
build_madt()API is exported, we have to rename the ARM static one in order to avoid build time conflicts.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/i386/acpi.h | 28 ++++++++++++++++++++++++++++ hw/arm/virt-acpi-build.c | 4 ++-- hw/i386/acpi-build.c | 4 ++-- 3 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 include/hw/i386/acpi.hinclude/hw/i386/acpi.h new file +0
-0
[...]
Quoted 10 lines
include/hw/i386/acpi.h new file +5
-0+/* ACPI MADT (Multiple APIC Description Table) build method */ +void build_madt (GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); + +#endif hw/arm/virt-acpi-build.c +0
-0
hw/arm/virt-acpi-build.c build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) · line 568
Quoted 6 lines
hw/arm/virt-acpi-build.c +1
-1@@ -564,7 +564,7 @@ build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)/* MADT */ static void -build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) +virt_build_madt (GArray *table_data,BIOSLinker *linker,VirtMachineState *vms) {
You are moving build_madt() into x86 specific header i386/acpi.h so question is why do you touch ARM variant at all?
[...]
PATCH v5 19/24 hw: acpi: Retrieve the PCI bus from AcpiPciHpState
In reply to Samuel OrtizFrom: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method find_i440fx() to retrieve the PCI bus, this commit aims to rely on the fact that the PCI bus is known by the structure AcpiPciHpState.
When the structure is initialized through acpi_pcihp_init() call, it saves the PCI bus, which means there is no need to invoke a special function later on.
Based on the fact that find_i440fx() was only used there, this patch also removes the function find_i440fx() itself from the entire codebase.
--- include/hw/i386/pc.h | 1 - hw/acpi/pcihp.c | 10 ++++------ hw/pci-host/piix.c | 8 -------- stubs/pci-host-piix.c | 6 ------ stubs/Makefile.objs | 1 - 5 files changed, 4 insertions(+), 22 deletions(-) delete mode 100644 stubs/pci-host-piix.c
include/hw/i386/pc.h +0 -1
@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory); -PCIBus *find_i440fx (void );/* piix4.c */ extern PCIDevice *piix4_dev;int piix4_init (PCIBus *bus,ISABus **isa_bus,int devfn);
hw/acpi/pcihp.c +4 -6
@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque)return bsel_alloc; } -static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s) {static bool bsel_is_set; -PCIBus *bus;unsigned bsel_alloc =ACPI_PCIHP_BSEL_DEFAULT ;if (bsel_is_set) {
@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true; - bus =find_i440fx ();/* TODO: Q35 support */ -if (bus) { +if (s->root) {/* Scan all PCI buses. Set property to enable acpi based hotplug. */ -pci_for_each_bus_depth_first (bus, acpi_set_bsel,NULL , &bsel_alloc); +pci_for_each_bus_depth_first (s->root, acpi_set_bsel,NULL , &bsel_alloc); } }
@@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)void acpi_pcihp_reset (AcpiPciHpState *s) { -acpi_set_pci_info (); +acpi_set_pci_info (s);acpi_pcihp_update (s); }
hw/pci-host/piix.c +0 -8
@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,return b; } -PCIBus *find_i440fx (void ) -{ -PCIHostState *s =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/i440fx" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); -return s ? s->bus :NULL ; -} -/* PIIX3 PCI to ISA bridge */ static void piix3_set_irq_pic (PIIX3State *piix3,int pic_irq) {
stubs/pci-host-piix.c deleted +0 -6
@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ -return NULL ; -}
stubs/Makefile.objs +0 -1
@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.o stub-obj-y += vmgenid.o stub-obj-y += xen-common.o stub-obj-y += xen-hvm.o -stub-obj-y += pci-host-piix.o stub-obj-y += ram-block.o stub-obj-y += ramfb.o
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Quoted 10 lines · On Mon, 5 Nov 2018 02:40:42 +0100 Samuel Ortiz <[email protected]> wrote:
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to retrieve the PCI bus, this commit aims to rely on the fact that the PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call, it saves the PCI bus, which means there is no need to invoke a special function later on.
Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>
Thanks for cleaning it up
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along with find_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.
with commit message fixed
Quoted 95 lines
--- include/hw/i386/pc.h | 1 - hw/acpi/pcihp.c | 10 ++++------ hw/pci-host/piix.c | 8 -------- stubs/pci-host-piix.c | 6 ------ stubs/Makefile.objs | 1 - 5 files changed, 4 insertions(+), 22 deletions(-) delete mode 100644 stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-1@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory); -PCIBus *find_i440fx (void );/* piix4.c */ extern PCIDevice *piix4_dev;int piix4_init (PCIBus *bus,ISABus **isa_bus,int devfn);hw/acpi/pcihp.c +4
-6@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque)return bsel_alloc; } -static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s) {static bool bsel_is_set; -PCIBus *bus;unsigned bsel_alloc =ACPI_PCIHP_BSEL_DEFAULT ;if (bsel_is_set) {@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true; - bus =find_i440fx ();/* TODO: Q35 support */ -if (bus) { +if (s->root) {/* Scan all PCI buses. Set property to enable acpi based hotplug. */ -pci_for_each_bus_depth_first (bus, acpi_set_bsel,NULL , &bsel_alloc); +pci_for_each_bus_depth_first (s->root, acpi_set_bsel,NULL , &bsel_alloc); } }@@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)void acpi_pcihp_reset (AcpiPciHpState *s) { -acpi_set_pci_info (); +acpi_set_pci_info (s);acpi_pcihp_update (s); }hw/pci-host/piix.c +0
-8@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,return b; } -PCIBus *find_i440fx (void ) -{ -PCIHostState *s =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/i440fx" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); -return s ? s->bus :NULL ; -} -/* PIIX3 PCI to ISA bridge */ static void piix3_set_irq_pic (PIIX3State *piix3,int pic_irq) {stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ -return NULL ; -}stubs/Makefile.objs +0
-0
stubs/Makefile.objs stub-obj-y += pc_madt_cpu_entry.o · line 45
Quoted 6 lines
stubs/Makefile.objs +0
-1@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.o stub-obj-y += vmgenid.o stub-obj-y += xen-common.o stub-obj-y += xen-hvm.o -stub-obj-y += pci-host-piix.o stub-obj-y += ram-block.o stub-obj-y += ramfb.o
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Hi Igor,
Quoted 24 lines · Igor Mammedov
Quoted 11 lines · On Mon, 5 Nov 2018 02:40:42 +0100 Samuel Ortiz <[email protected]> wrote:
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to retrieve the PCI bus, this commit aims to rely on the fact that the PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call, it saves the PCI bus, which means there is no need to invoke a special function later on.Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>Thanks for cleaning it up
Quoted 7 lines
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along withfind_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.
Oh yes sure we can update the commit message :). But just wanted to mention that 'pc' machine type uses ACPI PCIHP and does support SHPC, so it's not mutually exclusive.
Quoted 108 lines
with commit message fixed
Reviewed-by Igor Mammedov <[email protected]>Quoted 102 lines
---
include/hw/i386/pc.h | 1 -
hw/acpi/pcihp.c | 10 ++++------
hw/pci-host/piix.c | 8 --------
stubs/pci-host-piix.c | 6 ------
stubs/Makefile.objs | 1 -5 files changed, 4 insertions(+), 22 deletions(-)delete mode 100644
stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-0@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory);
-PCIBus*find_i440fx(void);
/*piix4.c*/
extern PCIDevice*piix4_dev;
intpiix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);hw/acpi/pcihp.c +0
-0@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque) return bsel_alloc; }hw/acpi/pcihp.c +1
-1-static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s){
static boolbsel_is_set;
- PCIBus *bus;
unsignedbsel_alloc=ACPI_PCIHP_BSEL_DEFAULT;
if (bsel_is_set) {hw/acpi/pcihp.c +0
-0@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true;
- bus =find_i440fx(); /* TODO: Q35 support */
- if (bus) {
+ if (s->root) {
/* Scan all PCI buses. Set property to enable acpi based hotplug. */
- pci_for_each_bus_depth_first(bus,acpi_set_bsel, NULL,&bsel_alloc);
+ pci_for_each_bus_depth_first(s->root,acpi_set_bsel, NULL,&bsel_alloc);
}
}hw/acpi/pcihp.c +0
-0@@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
voidacpi_pcihp_reset(AcpiPciHpState *s)
{
- acpi_set_pci_info();
+ acpi_set_pci_info(s);
acpi_pcihp_update(s);
}hw/pci-host/piix.c +0
-0@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, return b; }hw/pci-host/piix.c +0
-4-PCIBus *find_i440fx (void ) -{ - PCIHostState *s = OBJECT_CHECK(PCIHostState, - object_resolve_path("/machine/i440fx", NULL),
- TYPE_PCI_HOST_BRIDGE); - return s ?s->bus: NULL;hw/pci-host/piix.c +0
-2-} -/* PIIX3 PCI to ISA bridge */
static voidpiix3_set_irq_pic(PIIX3State *piix3, int pic_irq){stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ - return NULL; -}stubs/Makefile.objs +0
-1--- a/stubs/Makefile.objs
Quoted 8 lines
Quoted 8 lines
+++ b/stubs/Makefile.objs
stubs/Makefile.objs +0
-0@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.ostub-obj-y += vmgenid.o
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
-stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.o
Thanks,
Sebastien
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-devel] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
In reply to Igor MammedovHi Igor,
Quoted 24 lines · Igor Mammedov
Quoted 11 lines · On Mon, 5 Nov 2018 02:40:42 +0100 Samuel Ortiz <[email protected]> wrote:
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to retrieve the PCI bus, this commit aims to rely on the fact that the PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call, it saves the PCI bus, which means there is no need to invoke a special function later on.Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>Thanks for cleaning it up
Quoted 7 lines
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along withfind_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.
Oh yes sure we can update the commit message :). But just wanted to mention that 'pc' machine type uses ACPI PCIHP and does support SHPC, so it's not mutually exclusive.
Quoted 108 lines
with commit message fixed
Reviewed-by Igor Mammedov <[email protected]>Quoted 102 lines
---
include/hw/i386/pc.h | 1 -
hw/acpi/pcihp.c | 10 ++++------
hw/pci-host/piix.c | 8 --------
stubs/pci-host-piix.c | 6 ------
stubs/Makefile.objs | 1 -5 files changed, 4 insertions(+), 22 deletions(-)delete mode 100644
stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-0@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory);
-PCIBus*find_i440fx(void);
/*piix4.c*/
extern PCIDevice*piix4_dev;
intpiix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);hw/acpi/pcihp.c +0
-0@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque) return bsel_alloc; }hw/acpi/pcihp.c +1
-1-static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s){
static boolbsel_is_set;
- PCIBus *bus;
unsignedbsel_alloc=ACPI_PCIHP_BSEL_DEFAULT;
if (bsel_is_set) {hw/acpi/pcihp.c +0
-0@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true;
- bus =find_i440fx(); /* TODO: Q35 support */
- if (bus) {
+ if (s->root) {
/* Scan all PCI buses. Set property to enable acpi based hotplug. */
- pci_for_each_bus_depth_first(bus,acpi_set_bsel, NULL,&bsel_alloc);
+ pci_for_each_bus_depth_first(s->root,acpi_set_bsel, NULL,&bsel_alloc);
}
}hw/acpi/pcihp.c +0
-0@@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
voidacpi_pcihp_reset(AcpiPciHpState *s)
{
- acpi_set_pci_info();
+ acpi_set_pci_info(s);
acpi_pcihp_update(s);
}hw/pci-host/piix.c +0
-0@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, return b; }hw/pci-host/piix.c +0
-4-PCIBus *find_i440fx (void ) -{ - PCIHostState *s = OBJECT_CHECK(PCIHostState, - object_resolve_path("/machine/i440fx", NULL),
- TYPE_PCI_HOST_BRIDGE); - return s ?s->bus: NULL;hw/pci-host/piix.c +0
-2-} -/* PIIX3 PCI to ISA bridge */
static voidpiix3_set_irq_pic(PIIX3State *piix3, int pic_irq){stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ - return NULL; -}stubs/Makefile.objs +0
-1--- a/stubs/Makefile.objs
Quoted 8 lines
Quoted 8 lines
+++ b/stubs/Makefile.objs
stubs/Makefile.objs +0
-0@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.ostub-obj-y += vmgenid.o
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
-stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.o
Thanks,
Sebastien
Re: [Qemu-arm] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Quoted 35 lines · Sebastien
Hi Igor,
Quoted 24 lines · Igor Mammedov
Quoted 11 lines · On Mon, 5 Nov 2018 02:40:42 +0100 Samuel Ortiz <[email protected]> wrote:
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to retrieve the PCI bus, this commit aims to rely on the fact that the PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call, it saves the PCI bus, which means there is no need to invoke a special function later on.Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>Thanks for cleaning it up
Quoted 7 lines
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along withfind_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.
Quoted 3 lines
Oh yes sure we can update the commit message :). But just wanted to mention that 'pc' machine type uses ACPI PCIHP and does support SHPC, so it's not mutually exclusive.
it supports both but is it relevant to this patch?
Point was that one shouldn't remove something silently without any justification/explanation. So that readers that come later wouldn't wonder about the reasons why the code was removed.
Quoted 110 lines
Quoted 110 lines
with commit message fixed
Reviewed-by Igor Mammedov <[email protected]>Quoted 105 lines
---
include/hw/i386/pc.h | 1 -
hw/acpi/pcihp.c | 10 ++++------
hw/pci-host/piix.c | 8 --------
stubs/pci-host-piix.c | 6 ------
stubs/Makefile.objs | 1 -5 files changed, 4 insertions(+), 22 deletions(-)delete mode 100644
stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-0@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory);
-PCIBus*find_i440fx(void);
/*piix4.c*/
extern PCIDevice*piix4_dev;
intpiix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);hw/acpi/pcihp.c +0
-0@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque) return bsel_alloc; }hw/acpi/pcihp.c +1
-1-static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s){
static boolbsel_is_set;
- PCIBus *bus;
unsignedbsel_alloc=ACPI_PCIHP_BSEL_DEFAULT;
if (bsel_is_set) {hw/acpi/pcihp.c +0
-0@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true;
- bus =find_i440fx(); /* TODO: Q35 support */
- if (bus) {
+ if (s->root) {
/* Scan all PCI buses. Set property to enable acpi based hotplug. */
- pci_for_each_bus_depth_first(bus,acpi_set_bsel, NULL,&bsel_alloc);
+ pci_for_each_bus_depth_first(s->root,acpi_set_bsel, NULL,&bsel_alloc);
}
}hw/acpi/pcihp.c +0
-0@@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
voidacpi_pcihp_reset(AcpiPciHpState *s)
{
- acpi_set_pci_info();
+ acpi_set_pci_info(s);
acpi_pcihp_update(s);
}hw/pci-host/piix.c +0
-0@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, return b; }hw/pci-host/piix.c +0
-4-PCIBus *find_i440fx (void ) -{ - PCIHostState *s = OBJECT_CHECK(PCIHostState, - object_resolve_path("/machine/i440fx", NULL),
- TYPE_PCI_HOST_BRIDGE); - return s ?s->bus: NULL;hw/pci-host/piix.c +0
-2-} -/* PIIX3 PCI to ISA bridge */
static voidpiix3_set_irq_pic(PIIX3State *piix3, int pic_irq){stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ - return NULL; -}stubs/Makefile.objs +0
-0@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.ostub-obj-y += vmgenid.o
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
-stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.oThanks,
Sebastien
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Quoted 43 lines · Igor Mammedov
Quoted 40 lines · Sebastien
Hi Igor,
Quoted 36 lines · Igor Mammedov
On Mon, 5 Nov 2018 02:40:42 +0100
Samuel Ortiz <[email protected]> wrote:Quoted 15 lines
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to
retrieve the PCI bus, this commit aims to rely on the fact that the
PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call,
it saves the PCI bus, which means there is no need to invoke a special function later on.Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>Thanks for cleaning it up
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along withfind_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.
Quoted 9 lines
Quoted 3 lines
Oh yes sure we can update the commit message :). But just wanted to mention that 'pc' machine type uses ACPI PCIHP and does support SHPC, so it's not mutually exclusive.
it supports both but is it relevant to this patch?
Point was that one shouldn't remove something silently without any justification/explanation. So that readers that come later wouldn't wonder about the reasons why the code was removed.
I understand the point but I think the comment was wrong in the first place since q35 never tried to support ACPI PCIHP, as they support PCIe native hotplug as you mentioned.
Quoted 125 lines
Quoted 124 lines
Quoted 114 lines
with commit message fixed
Reviewed-by Igor Mammedov <[email protected]>Quoted 107 lines
---
include/hw/i386/pc.h | 1 -
hw/acpi/pcihp.c | 10 ++++------
hw/pci-host/piix.c | 8 --------
stubs/pci-host-piix.c | 6 ------
stubs/Makefile.objs | 1 -5 files changed, 4 insertions(+), 22 deletions(-)delete mode 100644
stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-0@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory);
-PCIBus*find_i440fx(void);
/*piix4.c*/
extern PCIDevice*piix4_dev;
intpiix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);hw/acpi/pcihp.c +0
-0@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque) return bsel_alloc; }hw/acpi/pcihp.c +1
-1-static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s){
static boolbsel_is_set;
- PCIBus *bus;
unsignedbsel_alloc=ACPI_PCIHP_BSEL_DEFAULT;
if (bsel_is_set) {hw/acpi/pcihp.c +0
-0@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true;
- bus =find_i440fx(); /* TODO: Q35 support */
- if (bus) {
+ if (s->root) {
/* Scan all PCI buses. Set property to enable acpi based
hotplug. */
- pci_for_each_bus_depth_first(bus,acpi_set_bsel, NULL,&bsel_alloc);
+ pci_for_each_bus_depth_first(s->root,acpi_set_bsel, NULL,&bsel_alloc);
}
}hw/acpi/pcihp.c +0
-0@@ -213,7 +211,7 @@ static voidacpi_pcihp_update(AcpiPciHpState
*s)
voidacpi_pcihp_reset(AcpiPciHpState *s)
{
- acpi_set_pci_info();
+ acpi_set_pci_info(s);
acpi_pcihp_update(s);
}hw/pci-host/piix.c +0
-0@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, return b; }hw/pci-host/piix.c +0
-4-PCIBus *find_i440fx (void ) -{ - PCIHostState *s = OBJECT_CHECK(PCIHostState, - object_resolve_path("/machine/i
440fx", NULL),
- TYPE_PCI_HOST_BRIDGE); - return s ?s->bus: NULL;hw/pci-host/piix.c +0
-2-} -/* PIIX3 PCI to ISA bridge */
static voidpiix3_set_irq_pic(PIIX3State *piix3, int pic_irq){stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ - return NULL; -}stubs/Makefile.objs +0
-1--- a/stubs/Makefile.objsQuoted 8 lines
Quoted 8 lines
+++ b/stubs/Makefile.objs
stubs/Makefile.objs +0
-0@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.ostub-obj-y += vmgenid.o
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
-stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.oThanks,
Sebastien
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState
Quoted 49 lines · Sebastien
Quoted 48 lines · Igor Mammedov
Quoted 40 lines · Sebastien
Hi Igor,
Quoted 29 lines · Igor Mammedov
On Mon, 5 Nov 2018 02:40:42 +0100
Samuel Ortiz <[email protected]> wrote:Quoted 15 lines
From: Sebastien Boeuf <[email protected]>
Instead of using the machine type specific method
find_i440fx()to
retrieve the PCI bus, this commit aims to rely on the fact that the
PCI bus is known by the structure AcpiPciHpState.When the structure is initialized through
acpi_pcihp_init()call,
it saves the PCI bus, which means there is no need to invoke a special function later on.Quoted 8 lines
Based on the fact that
find_i440fx()was only used there, this patch also removes the functionfind_i440fx()itself from the entire codebase.Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Sebastien Boeuf <[email protected]>Signed-off-by Jing Liu <[email protected]>Thanks for cleaning it up
Quoted 7 lines
minor nit:
Taking in account that you're removing '/* TODO: Q35 support */' comment along withfind_i440fx(), it might be worth to mention in this commit message. Something along lines that ACPI PCIHP exist to support guests without SHPC support on PCI based PC machine. Considering that Q35 provides native PCI-E hotplug, there is no need to add ACPI hotplug there.Quoted 3 lines
Oh yes sure we can update the commit message :). But just wanted to mention that 'pc' machine type uses ACPI PCIHP and does support SHPC, so it's not mutually exclusive.
it supports both but is it relevant to this patch?
Quoted 8 lines
Quoted 4 lines
Point was that one shouldn't remove something silently without any justification/explanation. So that readers that come later wouldn't wonder about the reasons why the code was removed.
I understand the point but I think the comment was wrong in the first place since q35 never tried to support ACPI PCIHP, as they support PCIe native hotplug as you mentioned.
ok.
when you have something ready, feel free to ping me
(I don't mind to review on github if that helps to speed up process)
Quoted 118 lines
Quoted 118 lines
Quoted 116 lines
Quoted 116 lines
with commit message fixed
Reviewed-by Igor Mammedov <[email protected]>Quoted 109 lines
---
include/hw/i386/pc.h | 1 -
hw/acpi/pcihp.c | 10 ++++------
hw/pci-host/piix.c | 8 --------
stubs/pci-host-piix.c | 6 ------
stubs/Makefile.objs | 1 -5 files changed, 4 insertions(+), 22 deletions(-)delete mode 100644
stubs/pci-host-piix.cinclude/hw/i386/pc.h +0
-0@@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, MemoryRegion *pci_memory, MemoryRegion *ram_memory);
-PCIBus*find_i440fx(void);
/*piix4.c*/
extern PCIDevice*piix4_dev;
intpiix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);hw/acpi/pcihp.c +0
-0@@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque) return bsel_alloc; }hw/acpi/pcihp.c +1
-1-static void acpi_set_pci_info (void ) +static void acpi_set_pci_info (AcpiPciHpState *s){
static boolbsel_is_set;
- PCIBus *bus;
unsignedbsel_alloc=ACPI_PCIHP_BSEL_DEFAULT;
if (bsel_is_set) {hw/acpi/pcihp.c +0
-0@@ -104,10 +103,9 @@ static void acpi_set_pci_info(void) } bsel_is_set = true;
- bus =find_i440fx(); /* TODO: Q35 support */
- if (bus) {
+ if (s->root) {
/* Scan all PCI buses. Set property to enable acpi based
hotplug. */
- pci_for_each_bus_depth_first(bus,acpi_set_bsel, NULL,&bsel_alloc);
+ pci_for_each_bus_depth_first(s->root,acpi_set_bsel, NULL,&bsel_alloc);
}
}hw/acpi/pcihp.c +0
-0@@ -213,7 +211,7 @@ static voidacpi_pcihp_update(AcpiPciHpState
*s)
voidacpi_pcihp_reset(AcpiPciHpState *s)
{
- acpi_set_pci_info();
+ acpi_set_pci_info(s);
acpi_pcihp_update(s);
}hw/pci-host/piix.c +0
-0@@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type,const char *pci_type, return b; }hw/pci-host/piix.c +0
-4-PCIBus *find_i440fx (void ) -{ - PCIHostState *s = OBJECT_CHECK(PCIHostState, - object_resolve_path("/machine/i
440fx", NULL),
- TYPE_PCI_HOST_BRIDGE); - return s ?s->bus: NULL;hw/pci-host/piix.c +0
-2-} -/* PIIX3 PCI to ISA bridge */
static voidpiix3_set_irq_pic(PIIX3State *piix3, int pic_irq){stubs/pci-host-piix.c deleted +0
-6@@ -1,6 +0,0 @@ -#include "qemu/osdep.h" -#include "hw/i386/pc.h" -PCIBus *find_i440fx (void ) -{ - return NULL; -}stubs/Makefile.objs +0
-0@@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.o
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
stub-obj-y += vmgenid.o
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
-stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += ramfb.oThanks,
Sebastie
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 20/24 hw: acpi: Define ACPI tables builder interface
In reply to Samuel OrtizIn order to decouple ACPI APIs from specific machine types, we are creating an ACPI builder interface that each ACPI platform can choose to implement.
This way, a new machine type can re-use the high level ACPI APIs and define some custom table build methods, without having to duplicate most of the existing implementation only to add small variations to it.
--- include/hw/acpi/builder.h | 100 ++++++++++++++++++++++++++++++++++++++ hw/acpi/builder.c | 97 ++++++++++++++++++++++++++++++++++++ hw/acpi/Makefile.objs | 1 + 3 files changed, 198 insertions(+) create mode 100644 include/hw/acpi/builder.h create mode 100644 hw/acpi/builder.c
include/hw/acpi/builder.h new file +100 -0
@@ -0,0 +1,100 @@ +/* +* +* Copyright (c) 2018 Intel Corporation +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2 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/>. +*/ + +#ifndef ACPI_BUILDER_H +#define ACPI_BUILDER_H + +#include "qemu/osdep.h" +#include "hw/acpi/bios-linker-loader.h" +#include "qom/object.h" + +#define TYPE_ACPI_BUILDER "acpi-builder" + +#define ACPI_BUILDER_METHODS (klass) \ + OBJECT_CLASS_CHECK(AcpiBuilderMethods, (klass), TYPE_ACPI_BUILDER) +#define ACPI_BUILDER_GET_METHODS (obj) \ + OBJECT_GET_CLASS(AcpiBuilderMethods, (obj), TYPE_ACPI_BUILDER) +#define ACPI_BUILDER (obj) \ + INTERFACE_CHECK(AcpiBuilder, (obj), TYPE_ACPI_BUILDER) + +typedef struct AcpiConfiguration AcpiConfiguration ; +typedef struct AcpiBuildState AcpiBuildState ; +typedef struct AcpiMcfgInfo AcpiMcfgInfo ; + +typedef struct AcpiBuilder { +/* <private> */ +Object Parent; +}AcpiBuilder ; + +/** +* AcpiBuildMethods: +* +* Interface to be implemented by a machine type that needs to provide +* custom ACPI tables build method. +* +* @parent: Opaque parent interface. +* @rsdp: ACPI RSDP (Root System Description Pointer) table build callback. +* @madt: ACPI MADT (Multiple APIC Description Table) table build callback. +* @mcfg: ACPI MCFG table build callback. +* @srat: ACPI SRAT (System/Static Resource Affinity Table) +* table build callback. +* @slit: ACPI SLIT (System Locality System Information Table) +* table build callback. +* @configuration: ACPI configuration getter. +* This is used to query the machine instance for its +* AcpiConfiguration pointer. +*/ +typedef struct AcpiBuilderMethods { +/* <private> */ +InterfaceClass parent; + +/* <public> */ +void (*rsdp)(GArray *table_data,BIOSLinker *linker, +unsigned rsdt_tbl_offset); +void (*madt)(GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); +void (*mcfg)(GArray *table_data,BIOSLinker *linker, +AcpiMcfgInfo *info); +void (*srat)(GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *conf); +void (*slit)(GArray *table_data,BIOSLinker *linker); + +AcpiConfiguration *(*configuration)(AcpiBuilder *builder); +}AcpiBuilderMethods ; + +void acpi_builder_rsdp (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +unsigned rsdt_tbl_offset); + +void acpi_builder_madt (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); + +void acpi_builder_mcfg (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +AcpiMcfgInfo *info); + +void acpi_builder_srat (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *conf); + +void acpi_builder_slit (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker); + +AcpiConfiguration *acpi_builder_configuration (AcpiBuilder *builder); + +#endif
hw/acpi/builder.c new file +97 -0
97 lines not on this page · raw message
hw/acpi/Makefile.objs +1 -0
@@ -11,6 +11,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o common-obj-y += acpi_interface.o common-obj-y += bios-linker-loader.o common-obj-y += aml-build.o +common-obj-y += builder.o common-obj-$(CONFIG_IPMI) += ipmi.o common-obj-$(call lnot,$(CONFIG_IPMI)) += ipmi-stub.o
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:43 +0100 Samuel Ortiz <[email protected]> wrote:
In order to decouple ACPI APIs from specific machine types, we are creating an ACPI builder interface that each ACPI platform can choose to implement.
This way, a new machine type can re-use the high level ACPI APIs and define some custom table build methods, without having to duplicate most of the existing implementation only to add small variations to it.
I'm not sure about motivation behind so high APIs,
what obvious here is an extra level of indirection for not clear gain.
Yep using table callbacks, one can attempt to generalize acpi_setup() and help boards to decide which tables do not build (MCFG comes to the mind). But I'm not convinced that acpi_setup() could be cleanly generalized as a whole (probably some parts but not everything) so it's minor benefit for extra headache of figuring out what callback will be actually called when reading code.
However if board needs a slightly different table, it will have to duplicate an exiting one and then modify to suit its needs.
to me it pretty much looks the same as calling build_foo() we use now but with an extra indirection level and then duplicating the later for usage in another board in slightly different manner.
I agree with Paolo's suggestion to use interfaces for generalization, however I'd suggest a fine grained approach for providing board/target specific items/actions for generic tables.
For example take a look at AcpiDeviceIfClass interface that is implemented by GPE devices and its madt_cpu() method. That should simplify generalizing cpu hotplug for arm/virt and also help to generalize build_madt(). It's not cleanest impl. by far but headed in the right generic direction. I have it on my TODO list to do list to generalize acpi parts of build_fadt()/cpu hotplug some day as part of the project that adds cpu hotplug to arm/virt board.
GPE/GED device might be not ideal place to implement that interface (worked for pc/q35) and may be we should move it to machine level as board has access to much more data for building ACPI tables. For i386/virt, I'd extend/modify AcpiDeviceIfClass when/where it's necessary instead of adding high level table hooks.
That way generic build_foo() API's would share much more code.
Quoted 225 lines
Reviewed-by Philippe Mathieu-Daudé <[email protected]>Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/acpi/builder.h | 100 ++++++++++++++++++++++++++++++++++++++ hw/acpi/builder.c | 97 ++++++++++++++++++++++++++++++++++++ hw/acpi/Makefile.objs | 1 + 3 files changed, 198 insertions(+) create mode 100644 include/hw/acpi/builder.h create mode 100644 hw/acpi/builder.cinclude/hw/acpi/builder.h new file +100
-0@@ -0,0 +1,100 @@ +/* +* +* Copyright (c) 2018 Intel Corporation +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2 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/>. +*/ + +#ifndef ACPI_BUILDER_H +#define ACPI_BUILDER_H + +#include "qemu/osdep.h" +#include "hw/acpi/bios-linker-loader.h" +#include "qom/object.h" + +#define TYPE_ACPI_BUILDER "acpi-builder" + +#define ACPI_BUILDER_METHODS (klass) \ + OBJECT_CLASS_CHECK(AcpiBuilderMethods, (klass), TYPE_ACPI_BUILDER) +#define ACPI_BUILDER_GET_METHODS (obj) \ + OBJECT_GET_CLASS(AcpiBuilderMethods, (obj), TYPE_ACPI_BUILDER) +#define ACPI_BUILDER (obj) \ + INTERFACE_CHECK(AcpiBuilder, (obj), TYPE_ACPI_BUILDER) + +typedef struct AcpiConfiguration AcpiConfiguration ; +typedef struct AcpiBuildState AcpiBuildState ; +typedef struct AcpiMcfgInfo AcpiMcfgInfo ; + +typedef struct AcpiBuilder { +/* <private> */ +Object Parent; +}AcpiBuilder ; + +/** +* AcpiBuildMethods: +* +* Interface to be implemented by a machine type that needs to provide +* custom ACPI tables build method. +* +* @parent: Opaque parent interface. +* @rsdp: ACPI RSDP (Root System Description Pointer) table build callback. +* @madt: ACPI MADT (Multiple APIC Description Table) table build callback. +* @mcfg: ACPI MCFG table build callback. +* @srat: ACPI SRAT (System/Static Resource Affinity Table) +* table build callback. +* @slit: ACPI SLIT (System Locality System Information Table) +* table build callback. +* @configuration: ACPI configuration getter. +* This is used to query the machine instance for its +* AcpiConfiguration pointer. +*/ +typedef struct AcpiBuilderMethods { +/* <private> */ +InterfaceClass parent; + +/* <public> */ +void (*rsdp)(GArray *table_data,BIOSLinker *linker, +unsigned rsdt_tbl_offset); +void (*madt)(GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); +void (*mcfg)(GArray *table_data,BIOSLinker *linker, +AcpiMcfgInfo *info); +void (*srat)(GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *conf); +void (*slit)(GArray *table_data,BIOSLinker *linker); + +AcpiConfiguration *(*configuration)(AcpiBuilder *builder); +}AcpiBuilderMethods ; + +void acpi_builder_rsdp (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +unsigned rsdt_tbl_offset); + +void acpi_builder_madt (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf); + +void acpi_builder_mcfg (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +AcpiMcfgInfo *info); + +void acpi_builder_srat (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *conf); + +void acpi_builder_slit (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker); + +AcpiConfiguration *acpi_builder_configuration (AcpiBuilder *builder); + +#endif hw/acpi/builder.c new file +97
-0@@ -0,0 +1,97 @@ +/* +* +* Copyright (c) 2018 Intel Corporation +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2 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 "qemu/osdep.h" +#include "qemu/module.h" +#include "qom/object.h" +#include "hw/acpi/builder.h" + +void acpi_builder_rsdp (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +unsigned rsdt_tbl_offset) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); + +if (abm && abm->rsdp) { + abm->rsdp (table_data, linker, rsdt_tbl_offset); + } +} + +void acpi_builder_madt (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *ms,AcpiConfiguration *conf) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); + +if (abm && abm->madt) { + abm->madt (table_data, linker, ms, conf); + } +} + +void acpi_builder_mcfg (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +AcpiMcfgInfo *info) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); + +if (abm && abm->mcfg) { + abm->mcfg (table_data, linker, info); + } +} + +void acpi_builder_srat (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker, +MachineState *machine,AcpiConfiguration *conf) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); + +if (abm && abm->srat) { + abm->srat (table_data, linker, machine, conf); + } +} + +void acpi_builder_slit (AcpiBuilder *builder, +GArray *table_data,BIOSLinker *linker) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); + +if (abm && abm->slit) { + abm->slit (table_data, linker); + } +} + +AcpiConfiguration *acpi_builder_configuration (AcpiBuilder *builder) +{ +AcpiBuilderMethods *abm =ACPI_BUILDER_GET_METHODS (builder); +if (abm && abm->configuration) { +return abm->configuration (builder); + } +return NULL ; +} + +static const TypeInfo acpi_builder_info = { + .name =TYPE_ACPI_BUILDER , + .parent =TYPE_INTERFACE , + .class_size =sizeof (AcpiBuilderMethods), +}; + +static void acpi_builder_register_type (void ) +{ +type_register_static (&acpi_builder_info); +} + +type_init (acpi_builder_register_type)hw/acpi/Makefile.objs +0
-0
hw/acpi/Makefile.objs common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o · line 17
Quoted 7 lines
hw/acpi/Makefile.objs +1
-0@@ -11,6 +11,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o common-obj-y += acpi_interface.o common-obj-y += bios-linker-loader.o common-obj-y += aml-build.o +common-obj-y += builder.o common-obj-$(CONFIG_IPMI) += ipmi.o common-obj-$(call lnot,$(CONFIG_IPMI)) += ipmi-stub.o
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface
Quoted 9 lines · Igor Mammedov
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:43 +0100 Samuel Ortiz <[email protected]> wrote:
In order to decouple ACPI APIs from specific machine types, we are creating an ACPI builder interface that each ACPI platform can choose to implement.
This way, a new machine type can re-use the high level ACPI APIs and define some custom table build methods, without having to duplicate most of the existing implementation only to add small variations to it.
Quoted 8 lines
I'm not sure about motivation behind so high APIs,
what obvious here is an extra level of indirection for not clear gain.Yep using table callbacks, one can attempt to generalize
acpi_setup()and help boards to decide which tables do not build (MCFG comes to the mind). But I'm not convinced thatacpi_setup()could be cleanly generalized as a whole (probably some parts but not everything)
It's more about generalizing acpi_build(), and then having one acpi_setup for non hardware-reduced ACPI and a acpi_reduced_setup() for hardware-reduced.
Right now there's no generalization at all but with this patch we could already use the same acpi_reduced_setup() implementation for both arm and i386/virt.
Quoted 2 lines
so it's minor benefit for extra headache of
figuring out what callback will be actually called when reading code.
This is the same complexity that already exists for essentially all current interfaces.
Quoted 7 lines
However if board needs a slightly different table, it will have to duplicate an exiting one and then modify to suit its needs.
to me it pretty much looks the same as calling
build_foo()we use now but with an extra indirection level and then duplicating the later for usage in another board in slightly different manner.
I believe what you're trying to say is that this abstraction may be useful but you're arguing the granularity is not properly defined? Am I getting this right?
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [Qemu-devel] [PATCH v5 20/24] hw: acpi: Define ACPI tables builder interface
Quoted 22 lines · On Thu, 22 Nov 2018 00:57:21 +0100 Samuel Ortiz <[email protected]> wrote:
Quoted 9 lines · Igor Mammedov
Quoted 6 lines · On Mon, 5 Nov 2018 02:40:43 +0100 Samuel Ortiz <[email protected]> wrote:
In order to decouple ACPI APIs from specific machine types, we are creating an ACPI builder interface that each ACPI platform can choose to implement.
This way, a new machine type can re-use the high level ACPI APIs and define some custom table build methods, without having to duplicate most of the existing implementation only to add small variations to it.Quoted 8 lines
I'm not sure about motivation behind so high APIs,
what obvious here is an extra level of indirection for not clear gain.Yep using table callbacks, one can attempt to generalize
acpi_setup()and help boards to decide which tables do not build (MCFG comes to the mind). But I'm not convinced thatacpi_setup()could be cleanly generalized as a whole (probably some parts but not everything)It's more about generalizing
acpi_build(), and then having oneacpi_setupfor non hardware-reduced ACPI and aacpi_reduced_setup()for hardware-reduced.
Quoted 8 lines
Right now there's no generalization at all but with this patch we could already use the same
acpi_reduced_setup()implementation for both arm and i386/virt.Quoted 2 lines
so it's minor benefit for extra headache of
figuring out what callback will be actually called when reading code.This is the same complexity that already exists for essentially all current interfaces.
in case of callback vs plain function call, I'd choose the later if it does the job and resort to the former when I have to.
Quoted 10 lines
Quoted 7 lines
However if board needs a slightly different table, it will have to duplicate an exiting one and then modify to suit its needs.
to me it pretty much looks the same as calling
build_foo()we use now but with an extra indirection level and then duplicating the later for usage in another board in slightly different manner.I believe what you're trying to say is that this abstraction may be useful but you're arguing the granularity is not properly defined? Am I getting this right?
yep, something along those lines. So far it's not useful much if at all. So I'll not introduce it for now and try to get by with plain functions calls. Later we might add fine-grained callbacks on case by case basis (like 'adevc->madt_cpu') where it's possible to generalize.
Quoted 2 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 21/24 hw: i386: Implement the ACPI builder interface for PC
In reply to Samuel OrtizAll PC machine type derivatives will use the same ACPI table build methods. But with that change in place, any new x86 machine type will be able to re-use the acpi-build API and customize part of it by defining its own ACPI table build methods.
--- hw/i386/acpi-build.c | 14 +++++++++----- hw/i386/pc.c | 19 +++++++++++++++++++ 2 files changed, 28 insertions(+), 5 deletions(-)
hw/i386/acpi-build.c +9 -5
@@ -34,6 +34,7 @@#include "hw/acpi/acpi-defs.h" #include "hw/acpi/acpi.h" #include "hw/acpi/cpu.h" +#include "hw/acpi/builder.h" #include "hw/nvram/fw_cfg.h" #include "hw/loader.h" #include "hw/isa/isa.h"
@@ -1683,6 +1684,7 @@ void acpi_build(AcpiBuildTables *tables,GArray *tables_blob = tables->table_data;AcpiSlicOem slic_oem = { .id =NULL , .table_id =NULL };Object *vmgenid_dev; +AcpiBuilder *ab =ACPI_BUILDER (machine);acpi_get_pm_info (&pm);acpi_get_misc_info (&misc);
@@ -1732,7 +1734,8 @@ void acpi_build(AcpiBuildTables *tables, aml_len += tables_blob->len - fadt;acpi_add_table (table_offsets, tables_blob); -build_madt (tables_blob, tables->linker, machine, acpi_conf); +acpi_builder_madt (ab, tables_blob, tables->linker, + machine, acpi_conf); vmgenid_dev =find_vmgenid_dev ();if (vmgenid_dev) {
@@ -1756,15 +1759,16 @@ void acpi_build(AcpiBuildTables *tables, }if (acpi_conf->numa_nodes) {acpi_add_table (table_offsets, tables_blob); -build_srat (tables_blob, tables->linker, machine, acpi_conf); +acpi_builder_srat (ab, tables_blob, tables->linker, + machine, acpi_conf);if (have_numa_distance) {acpi_add_table (table_offsets, tables_blob); -build_slit (tables_blob, tables->linker); +acpi_builder_slit (ab, tables_blob, tables->linker); } }if (acpi_get_mcfg (&mcfg)) {acpi_add_table (table_offsets, tables_blob); -build_mcfg (tables_blob, tables->linker, &mcfg); +acpi_builder_mcfg (ab, tables_blob, tables->linker, &mcfg); }if (x86_iommu_get_default ()) {IommuType IOMMUType =x86_iommu_get_type ();
@@ -1795,7 +1799,7 @@ void acpi_build(AcpiBuildTables *tables, slic_oem.id, slic_oem.table_id);/* RSDP is in FSEG memory, so allocate it separately */ -build_rsdp_rsdt (tables->rsdp, tables->linker, rsdt); +acpi_builder_rsdp (ab, tables->rsdp, tables->linker, rsdt);/* We'll expose it all to Guest so we want to reduce * chance of size changes.
hw/i386/pc.c +19 -0
@@ -64,6 +64,7 @@#include "qemu/option.h" #include "hw/acpi/acpi.h" #include "hw/acpi/cpu_hotplug.h" +#include "hw/acpi/builder.h" #include "hw/boards.h" #include "acpi-build.h" #include "hw/mem/pc-dimm.h"
@@ -75,6 +76,7 @@#include "hw/nmi.h" #include "hw/i386/intel_iommu.h" #include "hw/net/ne2000-isa.h" +#include "hw/i386/acpi.h" /* debug PC/ISA interrupts */ //#define DEBUG_IRQ
@@ -2404,12 +2406,20 @@ static void x86_nmi(NMIState *n, int cpu_index, Error **errp) } } +static AcpiConfiguration *pc_acpi_configuration (AcpiBuilder *builder) +{ +PCMachineState *pcms =PC_MACHINE (builder); + +return &pcms->acpi_configuration; +} +static void pc_machine_class_init (ObjectClass *oc,void *data) {MachineClass *mc =MACHINE_CLASS (oc);PCMachineClass *pcmc =PC_MACHINE_CLASS (oc);HotplugHandlerClass *hc =HOTPLUG_HANDLER_CLASS (oc);NMIClass *nc =NMI_CLASS (oc); +AcpiBuilderMethods *abm =ACPI_BUILDER_METHODS (oc); pcmc->pci_enabled = true; pcmc->has_acpi_build = true;
@@ -2444,6 +2454,14 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) nc->nmi_monitor_handler = x86_nmi; mc->default_cpu_type =TARGET_DEFAULT_CPU_TYPE ; +/* ACPI building methods */ + abm->madt = build_madt; + abm->rsdp = build_rsdp_rsdt; + abm->mcfg = build_mcfg; + abm->srat = build_srat; + abm->slit = build_slit; + abm->configuration = pc_acpi_configuration; +object_class_property_add (oc,MEMORY_DEVICE_REGION_SIZE ,"int" , pc_machine_get_device_memory_region_size,NULL ,NULL ,NULL , &error_abort);
@@ -2495,6 +2513,7 @@ static const TypeInfo pc_machine_info = { .interfaces = (InterfaceInfo[]) { {TYPE_HOTPLUG_HANDLER }, {TYPE_NMI }, + {TYPE_ACPI_BUILDER }, { } }, };
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 22/24 hw: pci-host: piix: Return PCI host pointer instead of PCI bus
In reply to Samuel OrtizFor building the MCFG table, we need to track a given machine type PCI host pointer, and we can't get it from the bus pointer alone. As piix returns a PCI bus pointer, we simply modify its builder to return a PCI host pointer instead.
--- include/hw/i386/pc.h | 21 +++++++++++---------- hw/i386/pc_piix.c | 18 +++++++++++------- hw/pci-host/piix.c | 24 ++++++++++++------------ 3 files changed, 34 insertions(+), 29 deletions(-)
include/hw/i386/pc.h +11 -10
@@ -244,16 +244,17 @@ typedef struct PCII440FXState PCII440FXState;*/ #define RCR_IOPORT 0xcf9 -PCIBus *i440fx_init (const char *host_type,const char *pci_type, -PCII440FXState **pi440fx_state,int *piix_devfn, -ISABus **isa_bus,qemu_irq *pic, -MemoryRegion *address_space_mem, -MemoryRegion *address_space_io, -ram_addr_t ram_size, -ram_addr_t below_4g_mem_size, -ram_addr_t above_4g_mem_size, -MemoryRegion *pci_memory, -MemoryRegion *ram_memory); +struct PCIHostState *i440fx_init (const char *host_type,const char *pci_type, +PCII440FXState **pi440fx_state, +int *piix_devfn, +ISABus **isa_bus,qemu_irq *pic, +MemoryRegion *address_space_mem, +MemoryRegion *address_space_io, +ram_addr_t ram_size, +ram_addr_t below_4g_mem_size, +ram_addr_t above_4g_mem_size, +MemoryRegion *pci_memory, +MemoryRegion *ram_memory);/* piix4.c */ extern PCIDevice *piix4_dev;
hw/i386/pc_piix.c +11 -7
@@ -32,6 +32,7 @@#include "hw/display/ramfb.h" #include "hw/smbios/smbios.h" #include "hw/pci/pci.h" +#include "hw/pci/pci_host.h" #include "hw/pci/pci_ids.h" #include "hw/usb.h" #include "net/net.h"
@@ -75,6 +76,7 @@ static void pc_init1(MachineState *machine,MemoryRegion *system_memory =get_system_memory ();MemoryRegion *system_io =get_system_io ();int i; +struct PCIHostState *pci_host;PCIBus *pci_bus;ISABus *isa_bus;PCII440FXState *i440fx_state;
@@ -196,15 +198,17 @@ static void pc_init1(MachineState *machine, }if (pcmc->pci_enabled) { - pci_bus =i440fx_init (host_type, - pci_type, - &i440fx_state, &piix3_devfn, &isa_bus, pcms->gsi, - system_memory, system_io, machine->ram_size, - acpi_conf->below_4g_mem_size, - acpi_conf->above_4g_mem_size, - pci_memory, ram_memory); + pci_host =i440fx_init (host_type, + pci_type, + &i440fx_state, &piix3_devfn, &isa_bus, pcms->gsi, + system_memory, system_io, machine->ram_size, + acpi_conf->below_4g_mem_size, + acpi_conf->above_4g_mem_size, + pci_memory, ram_memory); + pci_bus = pci_host->bus; pcms->bus = pci_bus; }else { + pci_host =NULL ; pci_bus =NULL ; i440fx_state =NULL ; isa_bus = isa_bus_new(NULL, get_system_memory(), system_io,
hw/pci-host/piix.c +12 -12
@@ -342,17 +342,17 @@ static void i440fx_realize(PCIDevice *dev, Error **errp) } } -PCIBus *i440fx_init (const char *host_type,const char *pci_type, -PCII440FXState **pi440fx_state, -int *piix3_devfn, -ISABus **isa_bus,qemu_irq *pic, -MemoryRegion *address_space_mem, -MemoryRegion *address_space_io, -ram_addr_t ram_size, -ram_addr_t below_4g_mem_size, -ram_addr_t above_4g_mem_size, -MemoryRegion *pci_address_space, -MemoryRegion *ram_memory) +struct PCIHostState *i440fx_init (const char *host_type,const char *pci_type, +PCII440FXState **pi440fx_state, +int *piix3_devfn, +ISABus **isa_bus,qemu_irq *pic, +MemoryRegion *address_space_mem, +MemoryRegion *address_space_io, +ram_addr_t ram_size, +ram_addr_t below_4g_mem_size, +ram_addr_t above_4g_mem_size, +MemoryRegion *pci_address_space, +MemoryRegion *ram_memory) {DeviceState *dev;PCIBus *b;
@@ -442,7 +442,7 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,i440fx_update_memory_mappings (f); -return b; +return s; }/* PIIX3 PCI to ISA bridge */
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Qemu-arm] [PATCH v5 22/24] hw: pci-host: piix: Return PCI host pointer instead of PCI bus
On Mon, 5 Nov 2018 02:40:45 +0100
Samuel Ortiz <[email protected]> wrote:
All remaining patches a bit out of proper order,
they should be around patch 12/24 where you started to touch MCFG code.
Quoted 4 lines
For building the MCFG table, we need to track a given machine type PCI host pointer, and we can't get it from the bus pointer alone. As piix returns a PCI bus pointer, we simply modify its builder to return a PCI host pointer instead.
PC machine doesn't build MCFG so we don't really need it to provide this pointer, having this patch doesn't hurt but I'm not sure we need it.
CCing ARM folks since we are talking about generalizing MCFG table generation.
we have following invariants wrt using MCFG:
pc [pci_host != NULL] -> bail out early + do not build MCFG
pc [pci_host == NULL] -> would explode if not only for [has_acpi_build = false] guard
should be: do not even call acpi_get_mcfg().
q35 [pci_host == NULL] -> not valid combo and must assert
q35 [pci_host != NULL && mcfg_base != PCIE_BASE_ADDR_UNMAPPED]
generate MCFG using mcfg_base/size q35 [pci_host != NULL && mcfg_base == PCIE_BASE_ADDR_UNMAPPED]
generate place-holder 'QEMU' table for legacy machine versions without resizable MemoryRegion support.
Mapped/not mapped could be dynamic accross reboots, so we need access to PCIE(pci_host) to fetch current values.
arm/virt gpex [memmap[ecam_id].base/size] do build MCFG
hacked up variant that doesn't use pci_host mcfg_base/size fields not sure if it's possible to disable ecam as on q35 (does it need any fixing?) we should fix arm/virt to use pci-host mcfg_base/size so we could reuse properties PCIE_HOST_MCFG_BASE/PCIE_HOST_MCFG_SIZE on ARM and generic build_mcfg()
So we have quite a mess here, the current acpi_get_mcfg() does 2 things
1. indirectly checks that pci_host is PCI-E (presence of PCIE_HOST_MCFG_BASE property)
2. fetches mcfg_base/size if it's PCI-E host
and i386/build_mcfg() is called only when #1 is true
As far as see we use pci_host only to fetch mcfg_base/size and not for anything else.
Maybe as refactoring plan we should"
* pass to acpi_setup(PCIHostState* pcie_host) as an argument pcie host pointer, which for PC will be NULL and for the rest set it to q35/gxpe/... PCI-E host.
* call build_mcfg() if pcie_host != NULL
(no more indirect guessing using PCIE_HOST_MCFG_BASE property presence)
* move MCFG/QEMU table signature decision out of build_mcfg() and pass it as argument 'build_mcfg(...,char *mcfg_signature)'. It moves out masking table quirk into caller, where q35 can decide to change signature if ECAM is not mapped. The rest (arm|i386/virt) will always pass 'MCFG'. Or even better if ecam is mapped, create MCFG (with masking trick if q35 machine is old and do not support resizable MemoryRegions).
Quoted 118 lines
Signed-off-by Samuel Ortiz <[email protected]>--- include/hw/i386/pc.h | 21 +++++++++++---------- hw/i386/pc_piix.c | 18 +++++++++++------- hw/pci-host/piix.c | 24 ++++++++++++------------ 3 files changed, 34 insertions(+), 29 deletions(-)include/hw/i386/pc.h +11
-10@@ -244,16 +244,17 @@ typedef struct PCII440FXState PCII440FXState;*/ #define RCR_IOPORT 0xcf9 -PCIBus *i440fx_init (const char *host_type,const char *pci_type, -PCII440FXState **pi440fx_state,int *piix_devfn, -ISABus **isa_bus,qemu_irq *pic, -MemoryRegion *address_space_mem, -MemoryRegion *address_space_io, -ram_addr_t ram_size, -ram_addr_t below_4g_mem_size, -ram_addr_t above_4g_mem_size, -MemoryRegion *pci_memory, -MemoryRegion *ram_memory); +struct PCIHostState *i440fx_init (const char *host_type,const char *pci_type, +PCII440FXState **pi440fx_state, +int *piix_devfn, +ISABus **isa_bus,qemu_irq *pic, +MemoryRegion *address_space_mem, +MemoryRegion *address_space_io, +ram_addr_t ram_size, +ram_addr_t below_4g_mem_size, +ram_addr_t above_4g_mem_size, +MemoryRegion *pci_memory, +MemoryRegion *ram_memory);/* piix4.c */ extern PCIDevice *piix4_dev;hw/i386/pc_piix.c +11
-7@@ -32,6 +32,7 @@#include "hw/display/ramfb.h" #include "hw/smbios/smbios.h" #include "hw/pci/pci.h" +#include "hw/pci/pci_host.h" #include "hw/pci/pci_ids.h" #include "hw/usb.h" #include "net/net.h" @@ -75,6 +76,7 @@ static void pc_init1(MachineState *machine,MemoryRegion *system_memory =get_system_memory ();MemoryRegion *system_io =get_system_io ();int i; +struct PCIHostState *pci_host;PCIBus *pci_bus;ISABus *isa_bus;PCII440FXState *i440fx_state;@@ -196,15 +198,17 @@ static void pc_init1(MachineState *machine, }if (pcmc->pci_enabled) { - pci_bus =i440fx_init (host_type, - pci_type, - &i440fx_state, &piix3_devfn, &isa_bus, pcms->gsi, - system_memory, system_io, machine->ram_size, - acpi_conf->below_4g_mem_size, - acpi_conf->above_4g_mem_size, - pci_memory, ram_memory); + pci_host =i440fx_init (host_type, + pci_type, + &i440fx_state, &piix3_devfn, &isa_bus, pcms->gsi, + system_memory, system_io, machine->ram_size, + acpi_conf->below_4g_mem_size, + acpi_conf->above_4g_mem_size, + pci_memory, ram_memory); + pci_bus = pci_host->bus; pcms->bus = pci_bus; }else { + pci_host =NULL ; pci_bus =NULL ; i440fx_state =NULL ; isa_bus = isa_bus_new(NULL, get_system_memory(), system_io,hw/pci-host/piix.c +11
-11@@ -342,17 +342,17 @@ static void i440fx_realize(PCIDevice *dev, Error **errp) } } -PCIBus *i440fx_init (const char *host_type,const char *pci_type, -PCII440FXState **pi440fx_state, -int *piix3_devfn, -ISABus **isa_bus,qemu_irq *pic, -MemoryRegion *address_space_mem, -MemoryRegion *address_space_io, -ram_addr_t ram_size, -ram_addr_t below_4g_mem_size, -ram_addr_t above_4g_mem_size, -MemoryRegion *pci_address_space, -MemoryRegion *ram_memory) +struct PCIHostState *i440fx_init (const char *host_type,const char *pci_type, +PCII440FXState **pi440fx_state, +int *piix3_devfn, +ISABus **isa_bus,qemu_irq *pic, +MemoryRegion *address_space_mem, +MemoryRegion *address_space_io, +ram_addr_t ram_size, +ram_addr_t below_4g_mem_size, +ram_addr_t above_4g_mem_size, +MemoryRegion *pci_address_space, +MemoryRegion *ram_memory) {DeviceState *dev;PCIBus *b;
hw/pci-host/piix.c PCIBus *i440fx_init(const char *host_type, const char *pci_type, · line 448
Quoted 8 lines
hw/pci-host/piix.c +1
-1@@ -442,7 +442,7 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,i440fx_update_memory_mappings (f); -return b; +return s; }/* PIIX3 PCI to ISA bridge */
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 23/24 hw: i386: Set ACPI configuration PCI host pointer
In reply to Samuel OrtizFor both PC and Q35 machine types, we can set it at the PCI host bridge creation time.
--- hw/i386/pc_piix.c | 1 + hw/i386/pc_q35.c | 1 + 2 files changed, 2 insertions(+)
hw/i386/pc_piix.c +1 -0
@@ -216,6 +216,7 @@ static void pc_init1(MachineState *machine, no_hpet =1 ; }isa_bus_irqs (isa_bus, pcms->gsi); + acpi_conf->pci_host = pci_host;if (kvm_pic_in_kernel ()) { i8259 =kvm_i8259_init (isa_bus);
hw/i386/pc_q35.c +1 -0
@@ -188,6 +188,7 @@ static void pc_q35_init(MachineState *machine)qdev_init_nofail (DEVICE (q35_host)); phb =PCI_HOST_BRIDGE (q35_host); host_bus = phb->bus; + acpi_conf->pci_host = phb;/* create ISA bus */ lpc = pci_create_simple_multifunction(host_bus, PCI_DEVFN(ICH9_LPC_DEV, ICH9_LPC_FUNC), true,
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
PATCH v5 24/24 hw: i386: Refactor PCI host getter
In reply to Samuel OrtizFrom: Yang Zhong <[email protected]>
Now that the ACPI builder methods are added, we can reach the ACPI configuration pointer from the MachineState pointer. From there we can get to the PCI host pointer and return it.
This makes the PCI host getter an ACPI, architecture agnostic function.
--- hw/acpi/aml-build.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-)
hw/acpi/aml-build.c +7 -13
@@ -22,6 +22,8 @@#include "qemu/osdep.h" #include <glib/gprintf.h> #include "hw/acpi/aml-build.h" +#include "hw/acpi/builder.h" +#include "hw/mem/memory-device.h" #include "qemu/bswap.h" #include "qemu/bitops.h" #include "sysemu/numa.h"
@@ -1617,23 +1619,15 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)g_array_free (tables->vmgenid, mfre); } -/* -* Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE. -*/ Object *acpi_get_pci_host (void ) { -PCIHostState *host; +MachineState *ms =MACHINE (qdev_get_machine ()); +AcpiBuilder *ab =ACPI_BUILDER (ms); +AcpiConfiguration *acpi_conf; - host =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/i440fx" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); -if (!host) { - host =OBJECT_CHECK (PCIHostState, -object_resolve_path ("/machine/q35" ,NULL ), -TYPE_PCI_HOST_BRIDGE ); - } + acpi_conf =acpi_builder_configuration (ab); -return OBJECT (host); +return OBJECT (acpi_conf->pci_host); }
Signature · 7 lines
2.19.1 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 14 lines · On Mon, 5 Nov 2018 02:40:23 +0100 Samuel Ortiz <[email protected]> wrote:
This patch set provides an ACPI code reorganization in preparation for adding a shared hardware-reduced ACPI API to QEMU.
The changes are coming from the NEMU [1] project where we're defining a new x86 machine type: i386/virt. This is an EFI only, ACPI hardware-reduced platform that is built on top of a generic hardware-reduced ACPI API [2]. This API was initially based off the generic parts of the
arm/virt-acpi-build.cimplementation, and the goal is for both i386/virt and arm/virt to duplicate as little code as possible by using this new, shared API.As a preliminary for adding this hardware-reduced ACPI API to QEMU, we did some ACPI code reorganization with the following goals:
Quoted 6 lines
* Share as much as possible of the current ACPI build APIs between legacy and hardware-reduced ACPI.
* Share the ACPI build code across machine types and architectures and remove the typical PC machine type dependency.The patches are also available in their own git branch [3].
I think, I'm done with reviewing this patchset, to sum up thanks for trying generalize acpi parts. It is implemented not exactly generic way and patches aren't split perfectly but we can work on it.
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.
3. when you think about refactoring acpi into a generic API think about it as routines that go into a separate library (pure acpi spec code) and qemu/acpi glue routines and divide them correspondingly.
Quoted 90 lines
[1] https://github.com/intel/nemu
[2] https://github.com/intel/nemu/blob/topic/virt-x86/hw/acpi/reduced.c
[3] https://github.com/intel/nemu/tree/topic/upstream/acpiv1 -> v2:
* Drop the hardware-reduced implementation for now. Our next patch
* set
will add hardware-reduced and convert arm/virt to it.
* Implement the ACPI build methods as a QOM Interface Class and
* convert
the PC machine type to it.
*acpi_conf_pc_init()uses a PCMachineState pointer and not a MachineState one as its argument.v2 -> v3:
* Cc all relevant maintainers, no functional changes.v3 -> v4:
* Renamed all AcpiConfiguration pointers from conf toacpi_conf.
* Removed theACPI_BUILD_ALIGN_SIZEexport.
* Temporarily updated the arm virtbuild_rsdp()prototype for bisectability purposes.
* Removed unneeded pci headers fromacpi-build.c.
* Refactor the acpi PCI host getter so that it truly is architecture agnostic, by carrying the PCI host pointer through the AcpiConfiguration structure.
* Splitted the PCI host AML builder API export patch from the PCI host and holes getter one.
* Reduced thebuild_srat()export scope to hw/i386 instead of the broader hw/acpi. SRAT builders are truly architecture specific and can hardly be generalized.
* Completed the ACPI builder documentation.v4 -> v5:
* Reorganize the ACPI RSDP export and XSDT implementation into 3 patches.
* Fix the hw/i386/acpi header inclusions.Samuel Ortiz (16):
hw: i386: Decouple the ACPI build from the PC machine type
hw: acpi: Export ACPI build alignment API
hw: acpi: The RSDP build API can return void
hw: acpi: Export the RSDP build API
hw: acpi: Implement XSDT support for RSDP
hw: acpi: Factorize the RSDP build API implementation
hw: i386: Move PCI host definitions topci_host.h
hw: acpi: Export the PCI host and holes getters
hw: acpi: Do not create hotplug method when handler is not defined
hw: i386: Make the hotpluggable memory size property more generic
hw: i386: Export the i386 ACPI SRAT build method
hw: i386: Export the MADT build method
hw: acpi: Define ACPI tables builder interface
hw: i386: Implement the ACPI builder interface for PC
hw: pci-host: piix: Return PCI host pointer instead of PCI bus
hw: i386: Set ACPI configuration PCI host pointerSebastien Boeuf (2):
hw: acpi: Export the PCI hotplug API
hw: acpi: Retrieve the PCI bus from AcpiPciHpStateYang Zhong (6):
hw: acpi: Generalize AML build routines
hw: acpi: Factorize_OSCAML across architectures
hw: acpi: Export and generalize the PCI host AML API
hw: acpi: Export the MCFG getter
hw: acpi: Fix memory hotplug AML generation error
hw: i386: Refactor PCI host getterhw/i386/acpi-build.h | 9 +- include/hw/acpi/acpi-defs.h | 14 + include/hw/acpi/acpi.h | 44 ++ include/hw/acpi/aml-build.h | 47 ++ include/hw/acpi/builder.h | 100 +++ include/hw/i386/acpi.h | 28 + include/hw/i386/pc.h | 49 +- include/hw/mem/memory-device.h | 2 + include/hw/pci/pci_host.h | 6 + hw/acpi/aml-build.c | 981 +++++++++++++++++++++++++++++ hw/acpi/builder.c | 97 +++ hw/acpi/cpu.c | 8 +- hw/acpi/cpu_hotplug.c | 9 +- hw/acpi/memory_hotplug.c | 21 +- hw/acpi/pcihp.c | 10 +- hw/arm/virt-acpi-build.c | 93 +-- hw/i386/acpi-build.c | 1072 +++----------------------------- hw/i386/pc.c | 198 +++--- hw/i386/pc_piix.c | 36 +- hw/i386/pc_q35.c | 22 +- hw/i386/xen/xen-hvm.c | 19 +- hw/pci-host/piix.c | 32 +-
Quoted 9 lines
stubs/pci-host-piix.c | 6 - hw/acpi/Makefile.objs | 1 + stubs/Makefile.objs | 1 - 25 files changed, 1644 insertions(+), 1261 deletions(-) create mode 100644 include/hw/acpi/builder.h create mode 100644 include/hw/i386/acpi.h create mode 100644 hw/acpi/builder.c delete mode 100644 stubs/pci-host-piix.c
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
Paolo
Quoted 4 lines
3. when you think about refactoring acpi into a generic API think about it as routines that go into a separate library (pure acpi spec code) and qemu/acpi glue routines and divide them correspondingly.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.
Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
Quoted 8 lines
Paolo
Quoted 4 lines
3. when you think about refactoring acpi into a generic API think about it as routines that go into a separate library (pure acpi spec code) and qemu/acpi glue routines and divide them correspondingly.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
v4->v5 is a bit messed up because Samuel probably added a diff order setup
(https://patchew.org/QEMU/[email protected]/diff/[email protected]/)
but it's very useful in general.
Paolo
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 14 lines · Paolo Bonzini
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
Quoted 6 lines
v4->v5is a bit messed up because Samuel probably added a diff order setup
(https://patchew.org/QEMU/[email protected]/diff/[email protected]/)
but it's very useful in general.Paolo
Oh I didn't realize difforder breaks patchew. Or is the problem only if one switches from no order to difforder?
Signature · 6 lines
MST _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 20 lines · Michael S. Tsirkin
Quoted 19 lines · Paolo Bonzini
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
v4->v5is a bit messed up because Samuel probably added a diff order setup
(https://patchew.org/QEMU/[email protected]/diff/[email protected]/)
but it's very useful in general.
Quoted 4 lines
Quoted 1 line
Paolo
Oh I didn't realize difforder breaks patchew. Or is the problem only if one switches from no order to difforder?
No, it's just that switching it on makes the inter-version diff much larger, because all hunks are reordered. difforder is not a problem.
Paolo
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 7 lines · On Mon, 19 Nov 2018 18:14:26 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
Quoted 6 lines
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
Thanks, I'll give it a try.
Suggestion to split series mostly comes from contributor's point of view, it much easier to amend small series than a larger one.
Quoted 5 lines
v4->v5is a bit messed up because Samuel probably added a diff order setup
(https://patchew.org/QEMU/[email protected]/diff/[email protected]/)
but it's very useful in general.
Paolo
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 7 lines · On Mon, 19 Nov 2018 18:14:26 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
Quoted 6 lines
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
Thanks, I'll give it a try.
Suggestion to split series mostly comes from contributor's point of view, it much easier to amend small series than a larger one.
Quoted 5 lines
v4->v5is a bit messed up because Samuel probably added a diff order setup
(https://patchew.org/QEMU/[email protected]/diff/[email protected]/)
but it's very useful in general.
Paolo
Quoted 16 lines · Igor Mammedov
Quoted 7 lines · On Mon, 19 Nov 2018 18:14:26 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 5 lines · Igor Mammedov
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
Quoted 6 lines
This is true, on the other hand the series makes sense together and, even if the patches are more or less independent, they also all follow the same "plan". For reviewing v6, are you aware of Patchew's series diff functionality? It can tell you which patches had comments in v5, reorder patches if applicable, and display deleted and new patches at the right point in the series.
Quoted 4 lines
Thanks, I'll give it a try.
Suggestion to split series mostly comes from contributor's point of view, it much easier to amend small series than a larger one.
That's true, on the other hand rules exist to have exceptions. :) IIRC your AML builder patch was also a huge series, this is not very different.
Paolo
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)
Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
I assume the #1 goal is to add reduced HW support. So another option to speed up merging is to just go ahead and duplicate a bunch of code e.g. in pc_virt.c acpi/reduced.c or in any other file.
This way it might be easier to see what's common code and what isn't. And I think offline Igor said he might prefer that way. Right Igor?
Quoted 8 lines
Quoted 8 lines
Paolo
Quoted 4 lines
3. when you think about refactoring acpi into a generic API think about it as routines that go into a separate library (pure acpi spec code) and qemu/acpi glue routines and divide them correspondingly.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Michael,
Quoted 24 lines · Michael S. Tsirkin
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)
Quoted 4 lines
Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
I assume the #1 goal is to add reduced HW support.
From our perspective, yes. From the project's point of view, it's about making the current ACPI code more generic and not bound to any specific machine type.
Quoted 4 lines
So another
option to speed up merging is to just go ahead and duplicate a bunch of code e.g. inpc_virt.cacpi/reduced.cor in any other file.
It's precisely what we wanted to avoid in the very first place and we assumed this would be largely frowned upon by the community. It's also a burden for everyone to maintain that amount of duplicated code. Also I suppose this would also mean we'd have to eventually de-duplicate and factorize things in.
Honestly I'd rather not rush things out and work on code sharing first. I'll answer Igor's numerous comments today and will start addressing some of his concerns right aways as well.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 39 lines · Samuel Ortiz
Hi Michael,
Quoted 24 lines · Michael S. Tsirkin
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)Quoted 5 lines
Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
I assume the #1 goal is to add reduced HW support.
From our perspective, yes. From the project's point of view, it's aboutmaking the current ACPI code more generic and not bound to any specific machine type.
Quoted 4 lines
So another
option to speed up merging is to just go ahead and duplicate a bunch of code e.g. inpc_virt.cacpi/reduced.cor in any other file.
Quoted 5 lines
It's precisely what we wanted to avoid in the very first place and we assumed this would be largely frowned upon by the community. It's also a burden for everyone to maintain that amount of duplicated code. Also I suppose this would also mean we'd have to eventually de-duplicate and factorize things in.
For sure, that's the plan.
Quoted 6 lines
Honestly I'd rather not rush things out and work on code sharing first. I'll answer Igor's numerous comments today and will start addressing some of his concerns right aways as well.
Cheers,
Samuel.
OK, no problem then - just trying to make sure you aren't blocked.
Signature · 6 lines
MST _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 27 lines · On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
Quoted 6 lines
I assume the #1 goal is to add reduced HW support. So another option to speed up merging is to just go ahead and duplicate a bunch of code e.g. in
pc_virt.cacpi/reduced.cor in any other file.
This way it might be easier to see what's common code and what isn't. And I think offline Igor said he might prefer that way. Right Igor?
You mean probably 'x86 reduced hw' support. That's was what I've already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory beside acpi-build.c. It might apply to some other tables (i.e. complex cases).
On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet.
Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code.
A word to the contributors,
Don't do refactoring in silence, keep discussing approaches here, suggest alternatives. That way it's easier to reach a compromise and merge it with less iterations. And if you do split it in smaller parts, the process should go even faster.
I'll sent a small RSDP refactoring series for reference.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Paolo
Quoted 4 lines
3. when you think about refactoring acpi into a generic API think about it as routines that go into a separate library (pure acpi spec code) and qemu/acpi glue routines and divide them correspondingly.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Igor,
Quoted 50 lines · Igor Mammedov
Quoted 27 lines · On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
Quoted 6 lines
I assume the #1 goal is to add reduced HW support. So another option to speed up merging is to just go ahead and duplicate a bunch of code e.g. in
pc_virt.cacpi/reduced.cor in any other file.
This way it might be easier to see what's common code and what isn't. And I think offline Igor said he might prefer that way. Right Igor?You mean probably 'x86 reduced hw' support. That's was what I've already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory beside
acpi-build.c. It might apply to some other tables (i.e. complex cases).On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet.
Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code.
Quoted 7 lines
A word to the contributors,
Don't do refactoring in silence, keep discussing approaches here, suggest alternatives. That way it's easier to reach a compromise and merge it with less iterations. And if you do split it in smaller parts, the process should go even faster.I'll sent a small RSDP refactoring series for reference.
I was already working on the RSDP changes. Let me know if I should drop that work too.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 59 lines · On Wed, 21 Nov 2018 15:38:16 +0100 Samuel Ortiz <[email protected]> wrote:
Igor,
Quoted 56 lines · Igor Mammedov
Quoted 27 lines · On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 23 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)Quoted 2 lines
If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
Quoted 6 lines
I assume the #1 goal is to add reduced HW support. So another option to speed up merging is to just go ahead and duplicate a bunch of code e.g. in
pc_virt.cacpi/reduced.cor in any other file.
This way it might be easier to see what's common code and what isn't. And I think offline Igor said he might prefer that way. Right Igor?You mean probably 'x86 reduced hw' support. That's was what I've already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory beside
acpi-build.c. It might apply to some other tables (i.e. complex cases).On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet.
Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code.
A word to the contributors,
Don't do refactoring in silence, keep discussing approaches here, suggest alternatives. That way it's easier to reach a compromise and merge it with less iterations. And if you do split it in smaller parts, the process should go even faster.
Quoted 3 lines
Quoted 1 line
I'll sent a small RSDP refactoring series for reference.
I was already working on the RSDP changes. Let me know if I should drop that work too.
Go ahead,
you can reuse RSDP fixes I've just posted (you are CCed) if you haven't written them yet on your own.
Quoted 2 lines
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
Quoted 30 lines · Igor Mammedov
Quoted 27 lines · On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" <[email protected]> wrote:
Quoted 25 lines · Igor Mammedov
Quoted 10 lines · On Fri, 16 Nov 2018 17:37:54 +0100 Paolo Bonzini <[email protected]> wrote:
Quoted 8 lines · Igor Mammedov
General suggestions for this series:
1. Preferably don't do multiple changes within a patch neither post huge patches (unless it's pure code movement). (it's easy to squash patches later it necessary)
2. Start small, pick a table generalize it and send as one small patchset. Tables are often independent and it's much easier on both author/reviewer to agree upon changes and rewrite it if necessary.Quoted 3 lines
How would that be done? This series is on the bigger side, agreed, but most of it is really just code movement. It's a starting point, having a generic ACPI library is way beyond what this is trying to do.
I've tried to give suggestions how to restructure series on per patch basis. In my opinion it quite possible to split series in several smaller ones and it should really help with making series cleaner and easier/faster to review/amend/merge vs what we have in v5.
(it's more frustrating to rework large series vs smaller one)If something isn't clear, it's easy to reach out to me here or directly (email/irc/github) for clarification/feed back.
Quoted 7 lines
Quoted 6 lines
I assume the #1 goal is to add reduced HW support. So another option to speed up merging is to just go ahead and duplicate a bunch of code e.g. in
pc_virt.cacpi/reduced.cor in any other file.
This way it might be easier to see what's common code and what isn't. And I think offline Igor said he might prefer that way. Right Igor?You mean probably 'x86 reduced hw' support.
That's what this is going to eventually look like, unfortunately. And there's no technical reasons why we could not have a arch agnostic hw-reduced support, so this should only be an intermediate step.
Quoted 9 lines
That's was what I've
already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory besideacpi-build.c. It might apply to some other tables (i.e. complex cases).On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet.
I think I got the idea, and I will try to rework this serie according to these directions.
Quoted 3 lines
Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code.
I'd argue that the same could be said of a potential "x86 hw-reduced" solution. The same random contributor may not be around to push it to the next step and make it more generic. I'd also argue we're not planning to be random contributors, dropping code to the mailing list and leaving.
Quoted 3 lines
A word to the contributors,
Don't do refactoring in silence, keep discussing approaches here, suggest alternatives.
Practically speaking, a large chunk of the NEMU work rely on having a generic hardware-reduced ACPI implementation. We could not have blocked the project waiting for an upstream acceptable solution for it and we had to pick one route.
Retroactively I think we should have gone the self-contained, fully duplicated route and move on with the rest of the NEMU work. Upstream discussions could have then happened in parallel without much disruption for the project.
Cheers,
Samuel.
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel