aboutsummaryrefslogtreecommitdiff
path: root/hw/acpi
AgeCommit message (Collapse)AuthorFilesLines
2023-03-07pcihp: add ACPI PCI hotplug specific is_hotpluggable_bus() callbackIgor Mammedov4-24/+36
Provide pcihp specific callback to check if bus is hotpluggable and consolidate its scattered hotplug criteria there. While at it clean up no longer needed qbus_set_hotplug_handler(BUS(bus), NULL) workarounds since callback makes qbus_is_hotpluggable() return correct answer even if hotplug_handler is set on bus. PS: see ("pci: fix 'hotplugglable' property behavior") for details why callback was introduced. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-35-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pcihp: move fields enabling hotplug into AcpiPciHpStateIgor Mammedov4-29/+30
... instead of duplicating them in piix4 and lpc and then trying to pass them to pcihp routines as arguments. it simplifies call sites and places pcihp specific in its own structure. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-34-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07acpi: pci: move out ACPI PCI hotplug generator from generic slot generator ↵Igor Mammedov1-1/+11
build_append_pci_bus_devices() Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-33-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pci: move acpi-index uniqueness check to generic PCI device codeIgor Mammedov1-56/+0
acpi-index is now working with non-hotpluggable buses (pci/q35 machine hostbridge), it can be used even if ACPI PCI hotplug is disabled and as result acpi-index uniqueness check will be omitted (since the check is done by ACPI PCI hotplug handler, which isn't wired when ACPI PCI hotplug is disabled). Move check and related code to generic PCIDevice so it would be independent of ACPI PCI hotplug. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-30-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07pcihp: piix4: do not redirect hotplug controller to piix4 when ACPI hotplug ↵Igor Mammedov1-1/+1
is disabled commit [1] added ability to disable ACPI PCI hotplug on hostbridge but forgot to take into account that it should disable all ACPI hotplug machinery in case both hostbridge and bridge hotplug are disabled. Commit [2] tried to fix that, however it forgot to remove hotplug_handler override which hands hotplug control over to piix4 hotplug controller (uninitialized after [2]). As result at the time bridge is plugged in, its default (SHPC) hotplug handler is replaced by piix4 one in acpi_pcihp_device_plug_cb() ... if (!s->legacy_piix && ... qbus_set_hotplug_handler(BUS(sec), OBJECT(hotplug_dev)); which is acting on uninitialized s->legacy_piix value (0 by default) that was supposed to be initialized by acpi_pcihp_init(), that is no longer called due to following condition being false: piix4_acpi_system_hot_add_init() if (s->use_acpi_hotplug_bridge || s->use_acpi_root_pci_hotplug) { and the bridge ends up with piix4 as hotplug handler instead of shpc one. Followup hotplug on that bridge as result yields piix4 specific error: Error: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set 1) 3d7e78aa777 (Introduce a new flag for i440fx to disable PCI hotplug on the root bus) 2) df4008c9c59 (piix4: don't reserve hw resources when hotplug is off globally) Fixes: df4008c9c59 (piix4: don't reserve hw resources when hotplug is off globally) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-12-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-07x86: pcihp: fix missing bridge AML when intermediate root-port has ↵Igor Mammedov1-1/+1
'hotplug=off' set (I practice [1] hasn't broke anything since on hardware side we unset hotplug_handler on such intermediate port => hotplug behind it has never worked) When deciding if bridge should be described, the original condition was cold_plugged_bridge && pcihp_bridge_en which was replaced [1] by bridge has ACPI_PCIHP_PROP_BSEL the later however is not the same thing as the original and flips to false if intermediate bridge has hotplug turned off (root-port with 'hotplug=off' option). Since we already in build_pci_bridge_aml(), the question if it's bridge is answered. Use DeviceState::hotplugged to make decision if bridge should describe its slots. What's left out is pcihp_bridge_en, which tells us if ACPI bridge hotplug is enabled. With hotplug and non hotplug part now being mostly separated, omitting this check will only lead to colplugged bridges describe occupied slots in case when ACPI bridge hotplug is disabled. Which makes behavior consistent with occupied slots on hostbridge. Ex (pc/DSDT.hpbrroot diff): ... Device (S20) { Name (_ADR, 0x00040000) // _ADR: Address + Device (S08) + { + Name (_ADR, 0x00010000) // _ADR: Address + } + + Device (S10) + { + Name (_ADR, 0x00020000) // _ADR: Address + } } ... PS: testing shows that above doesn't affect adversely guest OS behavior: i.e. if ACPI bridge hotplug is enabled it's expected behaviour, and with ACPI bridge hotplug is disabled (a.k. native hotplug), it doesn't break slot enumeration nor native hotplug. (tested with RHEL9.0 and WS2022). 1) Fixes: 6c36ec46b0d ("pcihp: make bridge describe itself using AcpiDevAmlIfClass:build_dev_aml") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230302161543.286002-10-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-02-27hw: Move ich9.h to southbridge/Bernhard Beschow2-2/+2
ICH9 is a south bridge which doesn't necessarily depend on x86, so move it into the southbridge folder, analoguous to PIIX. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230213173033.98762-13-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-02-27hw/isa/lpc_ich9: Connect PM stuff to LPC internallyBernhard Beschow1-6/+2
Make TYPE_ICH9_LPC_DEVICE more self-contained by moving the call to ich9_lpc_pm_init() from board code to its realize function. In order to propagate x86_machine_is_smm_enabled(), introduce an "smm-enabled" property like we have in piix4. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230213173033.98762-8-shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-02-23hw/acpi: Move QMP command to hw/core/Markus Armbruster1-18/+0
The QERR_ macros are leftovers from the days of "rich" error objects. We've been trying to reduce their remaining use. qmp_query_vm_generation_id() in stubs/vmgenid.c is the last user of QERR_UNSUPPORTED outside qga/. Unlike the stubs we just dropped, it is actually reachable, namely when CONFIG_ACPI_VMGENID is off. It always fails like (qemu) info vm-generation-id Error: this feature or command is not currently supported Turns out the real qmp_query_vm_generation_id() doesn't actually depend on CONFIG_ACPI_VMGENID, and fails safely when it's off. Move it to hw/core/machine-qmp-cmds.c, and drop the stub. The error message becomes Error: VM Generation ID device not found Feels like an improvement to me. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230207075115.1525-8-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com>
2023-02-23hw/acpi: Dumb down acpi_table_add() stubMarkus Armbruster1-3/+1
The QERR_ macros are leftovers from the days of "rich" error objects. We've been trying to reduce their remaining use. acpi_table_add() is only ever called on behalf of CLI option -acpitable. Since qemu-options.hx sets @arch_mask to QEMU_ARCH_I386, it is reachable only for these targets. Since they provide a real acpi_table_add(), the stub is unreachable. There's no point in unreachable code keeping QERR_UNSUPPORTED alive. Dumb it down to g_assert_not_reached(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230207075115.1525-7-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com>
2023-02-08Drop duplicate #includeMarkus Armbruster1-1/+0
Tracked down with the help of scripts/clean-includes. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20230202133830.2152150-21-armbru@redhat.com>
2023-02-04acpi: Move the QMP command from monitor/ to hw/acpi/Markus Armbruster2-0/+31
This moves the command from MAINTAINERS section "QMP" to section "ACPI/SMBIOS)". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230124121946.1139465-25-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-28pcihp: make bridge describe itself using AcpiDevAmlIfClass:build_dev_amlIgor Mammedov4-1/+54
simplify build_append_pci_bus_devices() a bit by handling bridge specific logic in bridge dedicated AcpiDevAmlIfClass::build_dev_aml callback. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230112140312.3096331-30-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-28pci: acpihp: assign BSEL only to coldplugged bridgesIgor Mammedov1-13/+22
ACPI PCI hotplug would broken after bridge hotplug and then migration if hotplugged bridge were specified on target at command line. Currently it's not possible since, 'hotplugged' property was made read-only for some time now. The issue would happen due to BSEL being assigned to all bridges during 1st 'reset': source seq: 1. start 'pc' machine => sets BSEL to 0 on pci.0 (host-bridge) 2. hotplug bridge, no bsel is assigned (so far is ok) target seq: 1. start 'pc' machine with -S -device pci-bridge,id=hp_br,hotplugged=on BSEL gets assigned to as follows hp_br: 0 pci.0: 1 as result hotplug requests with migrated AML generated on source would be misdirected to 'hp_br' instead of intended pci.0 While it's not issue at the moment, it's based on implicit assumptions * 'hotplugged' property is read-only * 1st reset happens before QEMU drops into monitor mode which lets add hotplugged on source bridges as hotplugged ones (anything added at that stage counts as hotplugged (yet another assumption)) All of it looks too fragile to me, so lets restrict BSEL only to cold-plugged bridges explicitly. Migration wise it shouldn't break anything since assignment order stays the same: * user can't specify 'hotplugged=on' on CLI * user can't specify 'hotplugged=off' at monitor stage or later on older QEMU versions where 'hotplugged' is RW, hotplug is broken after migration anyways and we cannot do anything to fix that. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230112140312.3096331-12-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-28pcihp: piix4: do not call acpi_pcihp_reset() when ACPI PCI hotplug is disabledIgor Mammedov1-1/+3
piix4_pm_reset() is calling acpi_pcihp_reset() when ACPI PCI hotplug is disabled, which leads to assigning BSEL properties to bridges on path acpi_set_bsel() ... if (qbus_is_hotpluggable(BUS(bus))) { // above happens to be true by default (though it's SHPC hotplug handler) // set BSEL } At the moment the issue is masked by the fact that we use not only BSEL, to decide if we should generated hoplug AML but also pcihp_bridge_en knob. However the later patches will drop dependency on pcihp_bridge_en, and use only BSEL exclusively to decide if hotplug AML for slots should be built, which exposes issue. We should not ever call acpi_pcihp_reset() if ACPI PCI hotplug is disabled, make it so. PS: * Q35 does the right thing (i.e. it calls acpi_pcihp_reset only when pcihp is enabled) * the issue also makes acpi_pcihp_update() logic run on SHPC enabled bridges, which seems to be harmless Fixes: 3d7e78aa777 ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230112140312.3096331-11-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-27hw/acpi/acpi_dev_interface: Remove unused parameter from ↵Bernhard Beschow2-5/+3
AcpiDeviceIfClass::madt_cpu The only function ever assigned to AcpiDeviceIfClass::madt_cpu is pc_madt_cpu_entry() which doesn't use the AcpiDeviceIf parameter. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230121151941.24120-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-27hw/acpi/piix4: No need to #include "hw/southbridge/piix.h"Bernhard Beschow1-1/+0
hw/acpi/piix4 has its own header with its structure definition etc. Ammends commit 2bfd0845f0 'hw/acpi/piix4: move PIIX4PMState into separate piix4.h header'. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230121151941.24120-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-27hw/isa/isa-bus: Turn isa_build_aml() into qbus_build_aml()Bernhard Beschow1-0/+10
Frees isa-bus.c from implicit ACPI dependency. While at it, resolve open coding of qbus_build_aml() in piix3 and ich9. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230121151941.24120-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08acpi: cpuhp: fix guest-visible maximum access size to the legacy reg blockLaszlo Ersek1-0/+3
The modern ACPI CPU hotplug interface was introduced in the following series (aa1dd39ca307..679dd1a957df), released in v2.7.0: 1 abd49bc2ed2f docs: update ACPI CPU hotplug spec with new protocol 2 16bcab97eb9f pc: piix4/ich9: add 'cpu-hotplug-legacy' property 3 5e1b5d93887b acpi: cpuhp: add CPU devices AML with _STA method 4 ac35f13ba8f8 pc: acpi: introduce AcpiDeviceIfClass.madt_cpu hook 5 d2238cb6781d acpi: cpuhp: implement hot-add parts of CPU hotplug interface 6 8872c25a26cc acpi: cpuhp: implement hot-remove parts of CPU hotplug interface 7 76623d00ae57 acpi: cpuhp: add cpu._OST handling 8 679dd1a957df pc: use new CPU hotplug interface since 2.7 machine type Before patch#1, "docs/specs/acpi_cpu_hotplug.txt" only specified 1-byte accesses for the hotplug register block. Patch#1 preserved the same restriction for the legacy register block, but: - it specified DWORD accesses for some of the modern registers, - in particular, the switch from the legacy block to the modern block would require a DWORD write to the *legacy* block. The latter functionality was then implemented in cpu_status_write() [hw/acpi/cpu_hotplug.c], in patch#8. Unfortunately, all DWORD accesses depended on a dormant bug: the one introduced in earlier commit a014ed07bd5a ("memory: accept mismatching sizes in memory_region_access_valid", 2013-05-29); first released in v1.6.0. Due to commit a014ed07bd5a, the DWORD accesses to the *legacy* CPU hotplug register block would work in spite of the above series *not* relaxing "valid.max_access_size = 1" in "hw/acpi/cpu_hotplug.c": > static const MemoryRegionOps AcpiCpuHotplug_ops = { > .read = cpu_status_read, > .write = cpu_status_write, > .endianness = DEVICE_LITTLE_ENDIAN, > .valid = { > .min_access_size = 1, > .max_access_size = 1, > }, > }; Later, in commits e6d0c3ce6895 ("acpi: cpuhp: introduce 'Command data 2' field", 2020-01-22) and ae340aa3d256 ("acpi: cpuhp: spec: add typical usecases", 2020-01-22), first released in v5.0.0, the modern CPU hotplug interface (including the documentation) was extended with another DWORD *read* access, namely to the "Command data 2" register, which would be important for the guest to confirm whether it managed to switch the register block from legacy to modern. This functionality too silently depended on the bug from commit a014ed07bd5a. In commit 5d971f9e6725 ('memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"', 2020-06-26), first released in v5.1.0, the bug from commit a014ed07bd5a was fixed (the commit was reverted). That swiftly exposed the bug in "AcpiCpuHotplug_ops", still present from the v2.7.0 series quoted at the top -- namely the fact that "valid.max_access_size = 1" didn't match what the guest was supposed to do, according to the spec ("docs/specs/acpi_cpu_hotplug.txt"). The symptom is that the "modern interface negotiation protocol" described in commit ae340aa3d256: > + Use following steps to detect and enable modern CPU hotplug interface: > + 1. Store 0x0 to the 'CPU selector' register, > + attempting to switch to modern mode > + 2. Store 0x0 to the 'CPU selector' register, > + to ensure valid selector value > + 3. Store 0x0 to the 'Command field' register, > + 4. Read the 'Command data 2' register. > + If read value is 0x0, the modern interface is enabled. > + Otherwise legacy or no CPU hotplug interface available falls apart for the guest: steps 1 and 2 are lost, because they are DWORD writes; so no switching happens. Step 3 (a single-byte write) is not lost, but it has no effect; see the condition in cpu_status_write() in patch#8. And step 4 *misleads* the guest into thinking that the switch worked: the DWORD read is lost again -- it returns zero to the guest without ever reaching the device model, so the guest never learns the switch didn't work. This means that guest behavior centered on the "Command data 2" register worked *only* in the v5.0.0 release; it got effectively regressed in v5.1.0. To make things *even more* complicated, the breakage was (and remains, as of today) visible with TCG acceleration only. Commit 5d971f9e6725 makes no difference with KVM acceleration -- the DWORD accesses still work, despite "valid.max_access_size = 1". As commit 5d971f9e6725 suggests, fix the problem by raising "valid.max_access_size" to 4 -- the spec now clearly instructs the guest to perform DWORD accesses to the legacy register block too, for enabling (and verifying!) the modern block. In order to keep compatibility for the device model implementation though, set "impl.max_access_size = 1", so that wide accesses be split before they reach the legacy read/write handlers, like they always have been on KVM, and like they were on TCG before 5d971f9e6725 (v5.1.0). Tested with: - OVMF IA32 + qemu-system-i386, CPU hotplug/hot-unplug with SMM, intermixed with ACPI S3 suspend/resume, using KVM accel (regression-test); - OVMF IA32X64 + qemu-system-x86_64, CPU hotplug/hot-unplug with SMM, intermixed with ACPI S3 suspend/resume, using KVM accel (regression-test); - OVMF IA32 + qemu-system-i386, SMM enabled, using TCG accel; verified the register block switch and the present/possible CPU counting through the modern hotplug interface, during OVMF boot (bugfix test); - I do not have any testcase (guest payload) for regression-testing CPU hotplug through the *legacy* CPU hotplug register block. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Ani Sinha <ani@anisinha.ca> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: qemu-stable@nongnu.org Ref: "IO port write width clamping differs between TCG and KVM" Link: http://mid.mail-archive.com/aaedee84-d3ed-a4f9-21e7-d221a28d1683@redhat.com Link: https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00199.html Reported-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20230105161804.82486-1-lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08hw/acpi/aml-build: Only generate cluster node in PPTT when specifiedYicong Yang1-1/+1
Currently we'll always generate a cluster node no matter user has specified '-smp clusters=X' or not. Cluster is an optional level and will participant the building of Linux scheduling domains and only appears on a few platforms. It's unncessary to always build it when it cannot reflect the real topology on platforms having no cluster implementation and to avoid affecting the linux scheduling domains in the VM. So only generate the cluster topology in ACPI PPTT when the user has specified it explicitly in -smp. Tested qemu-system-aarch64 with `-smp 8` and linux 6.1-rc1, without this patch: estuary:/sys/devices/system/cpu/cpu0/topology$ cat cluster_* ff # cluster_cpus 0-7 # cluster_cpus_list 56 # cluster_id with this patch: estuary:/sys/devices/system/cpu/cpu0/topology$ cat cluster_* ff # cluster_cpus 0-7 # cluster_cpus_list 36 # cluster_id, with no cluster node kernel will make it to physical package id Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Tested-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Message-Id: <20221229065513.55652-3-yangyicong@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08include/hw/pci: Split pci_device.h off pci.hMarkus Armbruster1-1/+1
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h. Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives. This also enables the next commit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08hw/acpi/Kconfig: Add missing dependencies to ACPI_PIIX4Bernhard Beschow1-1/+3
piix4_pm_realize() uses apm_init() and pm_smbus_init(), so both APM and ACPI_SMBUS are provided by the device model managed by ACPI_PIIX4. The ACPIREGS are also provided by ACPI_PIIX4, so needs to select ACPI. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20221216130355.41667-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-08hw/acpi/Kconfig: Do not needlessly build TYPE_PIIX4_PM in non-PC/Malta machinesBernhard Beschow1-1/+0
TYPE_PIIX4_PM is only used in machines where PIIX chipsets are used which is currently PC and Malta. There is no point building it for the other ACPI_X86 machines. Note that this also removes unneeded ACPI_PIIX4 from PEGASOS2. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20221216130355.41667-4-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
2023-01-08hw/acpi/Kconfig: Add missing dependencies to ACPI_ICH9Bernhard Beschow1-0/+2
ich9_lpc_realize() uses apm_init() and ich9_smbus_realize() uses pm_smbus_init(), so both APM and ACPI_SMBUS are provided by the device models managed by ACPI_ICH9. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221216130355.41667-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-08hw/acpi/Kconfig: Rename ACPI_X86_ICH to ACPI_ICH9Bernhard Beschow2-2/+2
Although the ICH9 ACPI controller may currently be tied to x86 it doesn't have to. Furthermore, the source files this configuration switch manages contain a '9', so this name fits more. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221216130355.41667-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/acpi: Rename tco.c -> ich9_tco.cPhilippe Mathieu-Daudé3-3/+3
tco.c contains the ICH9 implementation of its "total cost of ownership". Rename it accordingly to emphasis this is a part of the ICH9 model. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221212105115.2113-1-philmd@linaro.org> Acked-by: Igor Mammedov <imammedo@redhat.com>
2022-12-21pci: drop redundant PCIDeviceClass::is_bridge fieldIgor Mammedov1-2/+1
and use cast to TYPE_PCI_BRIDGE instead. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221129101341.185621-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2022-12-21ich9: honour 'enable_tco' propertyDaniel P. Berrangé1-2/+4
An 'ICH9-LPC.enable_tco' property has been exposed for a very long time, but attempts to set it have never been honoured. Originally, any user provided 'enable_tco' value was force replaced by a value passed from the machine type setup code that was determine by machine type compat properties. commit d6b304ba924b95d12edfddaac99777b577301309 Author: Eduardo Habkost <ehabkost@redhat.com> Date: Sat Jan 23 14:02:10 2016 -0200 machine: Remove no_tco field The field is always set to zero, so it is not necessary anymore. After legacy Q35 machine types were deleted in: commit 86165b499edf8b03bb2d0e926d116c2f12a95bfe Author: Eduardo Habkost <ehabkost@redhat.com> Date: Sat Jan 23 14:02:09 2016 -0200 q35: Remove old machine versions the machine type code ended up just unconditionally passing 'true', all the time, so this was further simplified in commit d6b304ba924b95d12edfddaac99777b577301309 Author: Eduardo Habkost <ehabkost@redhat.com> Date: Sat Jan 23 14:02:10 2016 -0200 machine: Remove no_tco field The field is always set to zero, so it is not necessary anymore. commit 18d6abae3ea092950629e5d26aff1dcfc9a2d78e Author: Eduardo Habkost <ehabkost@redhat.com> Date: Sat Jan 23 14:02:11 2016 -0200 ich9: Remove enable_tco arguments from init functions The enable_tco arguments are always true, so they are not needed anymore. Leaving the ich9_pm_init to just force set 'enable_tco' to true. This still overrides any user specified property. The initialization of property defaults should be done when properties are first registered, rather than during object construction. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221216125749.596075-6-berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/acpi: add trace events for TCO watchdog register accessDaniel P. Berrangé2-13/+30
These tracepoints aid in understanding and debugging the guest drivers for the TCO watchdog. Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221216125749.596075-2-berrange@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-14qapi qdev qom: Elide redundant has_FOO in generated CMarkus Armbruster1-1/+1
The has_FOO for pointer-valued FOO are redundant, except for arrays. They are also a nuisance to work with. Recent commit "qapi: Start to elide redundant has_FOO in generated C" provided the means to elide them step by step. This is the step for qapi/qdev.json and qapi/qom.json. Said commit explains the transformation in more detail. The invariant violations mentioned there do not occur here. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Eduardo Habkost <eduardo@habkost.net> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221104160712.3005652-21-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2022-12-13qapi acpi: Elide redundant has_FOO in generated CMarkus Armbruster3-9/+7
The has_FOO for pointer-valued FOO are redundant, except for arrays. They are also a nuisance to work with. Recent commit "qapi: Start to elide redundant has_FOO in generated C" provided the means to elide them step by step. This is the step for qapi/acpi.py. Said commit explains the transformation in more detail. The invariant violations mentioned there do not occur here. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Ani Sinha <ani@anisinha.ca> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221104160712.3005652-7-armbru@redhat.com>
2022-11-07hw/acpi/erst.c: Fix memory handling issuesChristian A. Ehrhardt1-3/+3
- Fix memset argument order: The second argument is the value, the length goes last. - Fix an integer overflow reported by Alexander Bulekov. Both issues allow the guest to overrun the host buffer allocated for the ERST memory device. Cc: Eric DeVolder <eric.devolder@oracle.com Cc: Alexander Bulekov <alxndr@bu.edu> Cc: qemu-stable@nongnu.org Fixes: f7e26ffa590 ("ACPI ERST: support for ACPI ERST feature") Tested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Message-Id: <20221024154233.1043347-1-lk@c--e.de> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1268 Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Eric DeVolder <eric.devolder@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-11-07acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptorsIgor Mammedov1-0/+10
NB: We do not expect any functional change in any ACPI tables with this change. It's only a refactoring. NB2: Some targets (or1k) do not support acpi and CONFIG_ACPI is off for them. However, modules are reused between all architectures so CONFIG_ACPI is on. For those architectures, dummy stub function definitions help to resolve symbols. This change uses more of these and so it adds a couple of dummy stub definitions so that symbols for those can be resolved. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221017102146.2254096-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> CC: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20221107152744.868434-1-ani@anisinha.ca>
2022-11-07acpi: fadt: support revision 6.0 of the ACPI specificationMiguel Luis1-3/+10
Update the Fixed ACPI Description Table (FADT) to revision 6.0 of the ACPI specification adding the field "Hypervisor Vendor Identity". This field's description states the following: "64-bit identifier of hypervisor vendor. All bytes in this field are considered part of the vendor identity. These identifiers are defined independently by the vendors themselves, usually following the name of the hypervisor product. Version information should NOT be included in this field - this shall simply denote the vendor's name or identifier. Version information can be communicated through a supplemental vendor-specific hypervisor API. Firmware implementers would place zero bytes into this field, denoting that no hypervisor is present in the actual firmware." Signed-off-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20221011181730.10885-3-miguel.luis@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-11-02acpi/nvdimm: Implement ACPI NVDIMM Label MethodsRobert Hoo1-0/+95
Recent ACPI spec [1] has defined NVDIMM Label Methods _LS{I,R,W}, which deprecates corresponding _DSM Functions defined by PMEM _DSM Interface spec [2]. Since the semantics of the new Label Methods are almost same as old _DSM methods, the implementations here simply wrapper old ones. ASL form diff can be found in next patch of updating golden master binaries. [1] ACPI Spec v6.4, 6.5.10 NVDIMM Label Methods https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf [2] Intel PMEM _DSM Interface Spec v2.0, 3.10 Deprecated Functions https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Message-Id: <20220922122155.1326543-5-robert.hu@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-11-02acpi/nvdimm: define macro for NVDIMM Device _DSMRobert Hoo1-2/+2
Since it will be heavily used in next patch, define macro NVDIMM_DEVICE_DSM_UUID for "4309AC30-0D11-11E4-9191-0800200C9A66", which is NVDIMM device specific method uuid defined in NVDIMM _DSM interface spec, Section 3. [1] No functional changes in this patch. [1] https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220922122155.1326543-4-robert.hu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-11-02acpi/ssdt: Fix aml_or() and aml_and() in if clauseRobert Hoo1-4/+3
In If condition, using bitwise and/or, rather than logical and/or. The result change in AML code: If (((Local6 == Zero) | (Arg0 != Local0))) ==> If (((Local6 == Zero) || (Arg0 != Local0))) If (((ObjectType (Arg3) == 0x04) & (SizeOf (Arg3) == One))) ==> If (((ObjectType (Arg3) == 0x04) && (SizeOf (Arg3) == One))) Fixes: 90623ebf603 ("nvdimm acpi: check UUID") Fixes: 4568c948066 ("nvdimm acpi: save arg3 of _DSM method") Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220922122155.1326543-3-robert.hu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-09-22hw/acpi: Add ospm_status hook implementation for acpi-gedKeqian Zhu1-0/+8
Setup an ARM virtual machine of machine virt and execute qmp "query-acpi-ospm-status" causes segmentation fault with following dumpstack: #1 0x0000aaaaab64235c in qmp_query_acpi_ospm_status (errp=errp@entry=0xfffffffff030) at ../monitor/qmp-cmds.c:312 #2 0x0000aaaaabfc4e20 in qmp_marshal_query_acpi_ospm_status (args=<optimized out>, ret=0xffffea4ffe90, errp=0xffffea4ffe88) at qapi/qapi-commands-acpi.c:63 #3 0x0000aaaaabff8ba0 in do_qmp_dispatch_bh (opaque=0xffffea4ffe98) at ../qapi/qmp-dispatch.c:128 #4 0x0000aaaaac02e594 in aio_bh_call (bh=0xffffe0004d80) at ../util/async.c:150 #5 aio_bh_poll (ctx=ctx@entry=0xaaaaad0f6040) at ../util/async.c:178 #6 0x0000aaaaac00bd40 in aio_dispatch (ctx=ctx@entry=0xaaaaad0f6040) at ../util/aio-posix.c:421 #7 0x0000aaaaac02e010 in aio_ctx_dispatch (source=0xaaaaad0f6040, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:320 #8 0x0000fffff76f6884 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #9 0x0000aaaaac0452d4 in glib_pollfds_poll () at ../util/main-loop.c:297 #10 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:320 #11 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 #12 0x0000aaaaab5c9e50 in qemu_main_loop () at ../softmmu/runstate.c:734 #13 0x0000aaaaab185370 in qemu_main (argc=argc@entry=47, argv=argv@entry=0xfffffffff518, envp=envp@entry=0x0) at ../softmmu/main.c:38 #14 0x0000aaaaab16f99c in main (argc=47, argv=0xfffffffff518) at ../softmmu/main.c:47 Fixes: ebb62075021a ("hw/acpi: Add ACPI Generic Event Device Support") Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20220816094957.31700-1-zhukeqian1@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-07-26acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()Robert Hoo2-19/+29
Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> Message-Id: <20220704085852.330005-1-robert.hu@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-06-28trivial typos: namesapceDr. David Alan Gilbert1-1/+1
'namespace' is misspelled in a bunch of places. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Message-Id: <20220614104045.85728-3-dgilbert@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-06-23hw/acpi: Make the PCI hot-plug aware of SR-IOVŁukasz Gieryk1-1/+5
PCI device capable of SR-IOV support is a new, still-experimental feature with only a single working example of the Nvme device. This patch in an attempt to fix a double-free problem when a SR-IOV-capable Nvme device is hot-unplugged in the following scenario: Qemu CLI: --------- -device pcie-root-port,slot=0,id=rp0 -device nvme-subsys,id=subsys0 -device nvme,id=nvme0,bus=rp0,serial=deadbeef,subsys=subsys0,sriov_max_vfs=1,sriov_vq_flexible=2,sriov_vi_flexible=1 Guest OS: --------- sudo nvme virt-mgmt /dev/nvme0 -c 0 -r 1 -a 1 -n 0 sudo nvme virt-mgmt /dev/nvme0 -c 0 -r 0 -a 1 -n 0 echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset sleep 1 echo 1 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1 nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2 nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 9 -n 0 sleep 2 echo 01:00.1 > /sys/bus/pci/drivers/nvme/bind Qemu monitor: ------------- device_del nvme0 Explanation of the problem and the proposed solution: 1) The current SR-IOV implementation assumes it’s the PhysicalFunction that creates and deletes VirtualFunctions. 2) It’s a design decision (the Nvme device at least) for the VFs to be of the same class as PF. Effectively, they share the dc->hotpluggable value. 3) When a VF is created, it’s added as a child node to PF’s PCI bus slot. 4) Monitor/device_del triggers the ACPI mechanism. The implementation is not aware of SR/IOV and ejects PF’s PCI slot, directly unrealizing all hot-pluggable (!acpi_pcihp_pc_no_hotplug) children nodes. 5) VFs are unrealized directly, and it doesn’t work well with (1). SR/IOV structures are not updated, so when it’s PF’s turn to be unrealized, it works on stale pointers to already-deleted VFs. The proposed fix is to make the PCI ACPI code aware of SR/IOV. Signed-off-by: Łukasz Gieryk <lukasz.gieryk@linux.intel.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-06-16acpi/erst: fix fallthrough code upon validation failureAni Sinha1-0/+3
At any step when any validation fail in check_erst_backend_storage(), there is no need to continue further through other validation checks. Further, by continuing even when record_size is 0, we run the risk of triggering a divide by zero error if we continued with other validation checks. Hence, we should simply return from this function upon validation failure. CC: Peter Maydell <peter.maydell@linaro.org> CC: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20220513141005.1929422-1-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric DeVolder <eric.devolder@oracle.com>
2022-06-11hw/acpi/piix4: remove unused piix4_pm_initfn() functionMark Cave-Ayland1-19/+0
This function is now unused and so can be completely removed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-13-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: use qdev gpio to wire up smi_irqMark Cave-Ayland1-2/+2
Initialize the SMI IRQ in piix4_pm_init(). The smi_irq can now be wired up directly using a qdev gpio instead of having to set the IRQ externally in piix4_pm_initfn(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-10-mark.cave-ayland@ilande.co.uk> [PMD: Partially squash 20220528091934.15520-8-mark.cave-ayland@ilande.co.uk] Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: use qdev gpio to wire up sci_irqMark Cave-Ayland1-3/+9
Introduce piix4_pm_init() instance init function and use it to initialise the separate qdev gpio for the SCI IRQ. The sci_irq can now be wired up directly using a qdev gpio instead of having to set the IRQ externally in piix4_pm_initfn(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-9-mark.cave-ayland@ilande.co.uk> [PMD: Partially squash 20220528091934.15520-8-mark.cave-ayland@ilande.co.uk] Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: rename piix4_pm_init() to piix4_pm_initfn()Mark Cave-Ayland1-3/+3
When QOMifying a device it is typical to use _init() as the suffix for an instance_init function, however this name is already in use by the legacy piix4_pm_init() wrapper function. Eventually the wrapper function will be removed, but for now rename it to piix4_pm_initfn() to avoid a naming collision. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-7-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: alter piix4_pm_init() to return PIIX4PMStateMark Cave-Ayland1-7/+4
This exposes the PIIX4_PM device to the caller to allow any qdev gpios to be mapped outside of piix4_pm_init(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-6-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: move PIIX4PMState into separate piix4.h headerMark Cave-Ayland1-41/+2
This allows the QOM types in hw/acpi/piix4.c to be used elsewhere by simply including hw/acpi/piix4.h. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220528091934.15520-5-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: convert smm_enabled bool to qdev propertyMark Cave-Ayland1-1/+2
This allows the smm_enabled value to be set using a standard qdev property instead of being referenced directly in piix4_pm_init(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20220528091934.15520-4-mark.cave-ayland@ilande.co.uk> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-06-11hw/acpi/piix4: change smm_enabled from int to boolMark Cave-Ayland1-2/+2
This is in preparation for conversion to a qdev property. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20220528091934.15520-3-mark.cave-ayland@ilande.co.uk> [PMD: Change simm_enabled from int to bool, suggested by Ani Sinha] Reviewed-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
generated by cgit v1.1 at 2024-12-28 07:16:32 +0000