qemu/hw/acpi/piix4.c

669 lines
22 KiB
C
Raw Normal View History

/*
* ACPI implementation
*
* Copyright (c) 2006 Fabrice Bellard
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License version 2.1 as published by the Free Software Foundation.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, see <http://www.gnu.org/licenses/>
*
* Contributions after 2012-01-13 are licensed under the terms of the
* GNU GPL, version 2 or (at your option) any later version.
*/
#include "qemu/osdep.h"
#include "hw/i386/pc.h"
#include "hw/southbridge/piix.h"
#include "hw/irq.h"
#include "hw/isa/apm.h"
#include "hw/i2c/pm_smbus.h"
#include "hw/pci/pci.h"
#include "hw/qdev-properties.h"
#include "hw/acpi/acpi.h"
#include "hw/acpi/pcihp.h"
#include "hw/acpi/piix4.h"
#include "sysemu/runstate.h"
#include "sysemu/sysemu.h"
#include "sysemu/xen.h"
2016-03-14 11:01:28 +03:00
#include "qapi/error.h"
#include "qemu/range.h"
#include "hw/acpi/pcihp.h"
#include "hw/acpi/cpu_hotplug.h"
#include "hw/acpi/cpu.h"
#include "hw/hotplug.h"
#include "hw/mem/pc-dimm.h"
#include "hw/mem/nvdimm.h"
#include "hw/acpi/memory_hotplug.h"
#include "hw/acpi/acpi_dev_interface.h"
#include "migration/vmstate.h"
#include "hw/core/cpu.h"
#include "trace.h"
#include "qom/object.h"
#define GPE_BASE 0xafe0
#define GPE_LEN 4
#define ACPI_PCIHP_ADDR_PIIX4 0xae00
struct pci_status {
acpi_piix4: Fix PCI hotplug race As Michael Tsirkin demonstrated, current PCI hotplug is vulnerable to a few races. The first is a race with other hotplug operations because we clear the up & down registers at each event. If a new event comes before the last is processed, up/down is cleared and the event is lost. To fix this for the down register, we create a life cycle for the event request that starts with the hot unplug request in piix4_device_hotplug() and ends when the device is ejected. This allows us to mask and clear individual bits, preserving them against races. For the up register, we have no clear end point for when the event is finished. We could modify the BIOS to acknowledge the bit and clear it, but this creates BIOS compatibiliy issues without offering a complete solution. Instead we note that gratuitous ACPI device checks are not harmful, which allows us to issue a device check for every slot. We know which slots are present and we know which slots are hotpluggable, so we can easily reduce this to a more manageable set for the guest. The other race Michael noted was that an unplug request followed by reset may also lose the eject notification, which may also result in the eject request being lost which a subsequent add or remove. Once we're in reset, the device is unused and we can flush the queue of device removals ourselves. Previously if a device_del was issued to a guest without ACPI PCI hotplug support, it was necessary to shutdown the guest to recover the device. With this, a guest reboot is sufficient. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2012-04-05 21:07:15 +04:00
uint32_t up; /* deprecated, maintained for migration compatibility */
uint32_t down;
};
static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
PCIBus *bus, PIIX4PMState *s);
#define ACPI_ENABLE 0xf1
#define ACPI_DISABLE 0xf0
static void pm_tmr_timer(ACPIREGS *ar)
{
PIIX4PMState *s = container_of(ar, PIIX4PMState, ar);
acpi_update_sci(&s->ar, s->irq);
}
static void apm_ctrl_changed(uint32_t val, void *arg)
{
PIIX4PMState *s = arg;
PCIDevice *d = PCI_DEVICE(s);
/* ACPI specs 3.0, 4.7.2.5 */
acpi_pm1_cnt_update(&s->ar, val == ACPI_ENABLE, val == ACPI_DISABLE);
if (val == ACPI_ENABLE || val == ACPI_DISABLE) {
return;
}
if (d->config[0x5b] & (1 << 1)) {
if (s->smi_irq) {
qemu_irq_raise(s->smi_irq);
}
}
}
static void pm_io_space_update(PIIX4PMState *s)
{
PCIDevice *d = PCI_DEVICE(s);
s->io_base = le32_to_cpu(*(uint32_t *)(d->config + 0x40));
s->io_base &= 0xffc0;
memory_region_transaction_begin();
memory_region_set_enabled(&s->io, d->config[0x80] & 1);
memory_region_set_address(&s->io, s->io_base);
memory_region_transaction_commit();
}
static void smbus_io_space_update(PIIX4PMState *s)
{
PCIDevice *d = PCI_DEVICE(s);
s->smb_io_base = le32_to_cpu(*(uint32_t *)(d->config + 0x90));
s->smb_io_base &= 0xffc0;
memory_region_transaction_begin();
memory_region_set_enabled(&s->smb.io, d->config[0xd2] & 1);
memory_region_set_address(&s->smb.io, s->smb_io_base);
memory_region_transaction_commit();
}
static void pm_write_config(PCIDevice *d,
uint32_t address, uint32_t val, int len)
{
pci_default_write_config(d, address, val, len);
if (range_covers_byte(address, len, 0x80) ||
ranges_overlap(address, len, 0x40, 4)) {
pm_io_space_update((PIIX4PMState *)d);
}
if (range_covers_byte(address, len, 0xd2) ||
ranges_overlap(address, len, 0x90, 4)) {
smbus_io_space_update((PIIX4PMState *)d);
}
}
static int vmstate_acpi_post_load(void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
pm_io_space_update(s);
smbus_io_space_update(s);
return 0;
}
#define VMSTATE_GPE_ARRAY(_field, _state) \
{ \
.name = (stringify(_field)), \
.version_id = 0, \
.info = &vmstate_info_uint16, \
.size = sizeof(uint16_t), \
.flags = VMS_SINGLE | VMS_POINTER, \
.offset = vmstate_offset_pointer(_state, _field, uint8_t), \
}
static const VMStateDescription vmstate_gpe = {
.name = "gpe",
.version_id = 1,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_GPE_ARRAY(sts, ACPIGPE),
VMSTATE_GPE_ARRAY(en, ACPIGPE),
VMSTATE_END_OF_LIST()
}
};
static const VMStateDescription vmstate_pci_status = {
.name = "pci_status",
.version_id = 1,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT32(up, struct AcpiPciHpPciStatus),
VMSTATE_UINT32(down, struct AcpiPciHpPciStatus),
VMSTATE_END_OF_LIST()
}
};
static bool vmstate_test_use_acpi_hotplug_bridge(void *opaque, int version_id)
{
PIIX4PMState *s = opaque;
return s->use_acpi_hotplug_bridge;
}
static bool vmstate_test_no_use_acpi_hotplug_bridge(void *opaque,
int version_id)
{
PIIX4PMState *s = opaque;
return !s->use_acpi_hotplug_bridge;
}
static bool vmstate_test_use_memhp(void *opaque)
{
PIIX4PMState *s = opaque;
return s->acpi_memory_hotplug.is_enabled;
}
static const VMStateDescription vmstate_memhp_state = {
.name = "piix4_pm/memhp",
.version_id = 1,
.minimum_version_id = 1,
.needed = vmstate_test_use_memhp,
.fields = (VMStateField[]) {
VMSTATE_MEMORY_HOTPLUG(acpi_memory_hotplug, PIIX4PMState),
VMSTATE_END_OF_LIST()
}
};
static bool vmstate_test_use_cpuhp(void *opaque)
{
PIIX4PMState *s = opaque;
return !s->cpu_hotplug_legacy;
}
static int vmstate_cpuhp_pre_load(void *opaque)
{
Object *obj = OBJECT(opaque);
qom: Put name parameter before value / visitor parameter The object_property_set_FOO() setters take property name and value in an unusual order: void object_property_set_FOO(Object *obj, FOO_TYPE value, const char *name, Error **errp) Having to pass value before name feels grating. Swap them. Same for object_property_set(), object_property_get(), and object_property_parse(). Convert callers with this Coccinelle script: @@ identifier fun = { object_property_get, object_property_parse, object_property_set_str, object_property_set_link, object_property_set_bool, object_property_set_int, object_property_set_uint, object_property_set, object_property_set_qobject }; expression obj, v, name, errp; @@ - fun(obj, v, name, errp) + fun(obj, name, v, errp) Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error message "no position information". Convert that one manually. Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Convert manually. Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused by RXCPU being used both as typedef and function-like macro there. Convert manually. The other files using RXCPU that way don't need conversion. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-27-armbru@redhat.com> [Straightforwad conflict with commit 2336172d9b "audio: set default value for pcspk.iobase property" resolved]
2020-07-07 19:05:54 +03:00
object_property_set_bool(obj, "cpu-hotplug-legacy", false, &error_abort);
return 0;
}
static const VMStateDescription vmstate_cpuhp_state = {
.name = "piix4_pm/cpuhp",
.version_id = 1,
.minimum_version_id = 1,
.needed = vmstate_test_use_cpuhp,
.pre_load = vmstate_cpuhp_pre_load,
.fields = (VMStateField[]) {
VMSTATE_CPU_HOTPLUG(cpuhp_state, PIIX4PMState),
VMSTATE_END_OF_LIST()
}
};
static bool piix4_vmstate_need_smbus(void *opaque, int version_id)
{
return pm_smbus_vmstate_needed();
}
/*
* This is a fudge to turn off the acpi_index field,
* whose test was always broken on piix4 with 6.2 and older machine types.
*/
static bool vmstate_test_migrate_acpi_index(void *opaque, int version_id)
{
PIIX4PMState *s = PIIX4_PM(opaque);
return s->use_acpi_hotplug_bridge && !s->not_migrate_acpi_index;
}
/* qemu-kvm 1.2 uses version 3 but advertised as 2
* To support incoming qemu-kvm 1.2 migration, change version_id
* and minimum_version_id to 2 below (which breaks migration from
* qemu 1.2).
*
*/
static const VMStateDescription vmstate_acpi = {
.name = "piix4_pm",
.version_id = 3,
.minimum_version_id = 3,
.post_load = vmstate_acpi_post_load,
.fields = (VMStateField[]) {
VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
VMSTATE_STRUCT_TEST(smb, PIIX4PMState, piix4_vmstate_need_smbus, 3,
pmsmb_vmstate, PMSMBus),
VMSTATE_TIMER_PTR(ar.tmr.timer, PIIX4PMState),
VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
VMSTATE_STRUCT_TEST(
acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
PIIX4PMState,
vmstate_test_no_use_acpi_hotplug_bridge,
2, vmstate_pci_status,
struct AcpiPciHpPciStatus),
VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState,
pci: introduce acpi-index property for PCI device In x86/ACPI world, linux distros are using predictable network interface naming since systemd v197. Which on QEMU based VMs results into path based naming scheme, that names network interfaces based on PCI topology. With itm on has to plug NIC in exactly the same bus/slot, which was used when disk image was first provisioned/configured or one risks to loose network configuration due to NIC being renamed to actually used topology. That also restricts freedom to reshape PCI configuration of VM without need to reconfigure used guest image. systemd also offers "onboard" naming scheme which is preferred over PCI slot/topology one, provided that firmware implements: " PCI Firmware Specification 3.1 4.6.7. DSM for Naming a PCI or PCI Express Device Under Operating Systems " that allows to assign user defined index to PCI device, which systemd will use to name NIC. For example, using -device e1000,acpi-index=100 guest will rename NIC to 'eno100', where 'eno' is default prefix for "onboard" naming scheme. This doesn't require any advance configuration on guest side to com in effect at 'onboard' scheme takes priority over path based naming. Hope is that 'acpi-index' it will be easier to consume by management layer, compared to forcing specific PCI topology and/or having several disk image templates for different topologies and will help to simplify process of spawning VM from the same template without need to reconfigure guest NIC. This patch adds, 'acpi-index'* property and wires up a 32bit register on top of pci hotplug register block to pass index value to AML code at runtime. Following patch will add corresponding _DSM code and wire it up to PCI devices described in ACPI. *) name comes from linux kernel terminology Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210315180102.3008391-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-03-15 21:00:58 +03:00
vmstate_test_use_acpi_hotplug_bridge,
vmstate_test_migrate_acpi_index),
VMSTATE_END_OF_LIST()
},
.subsections = (const VMStateDescription*[]) {
&vmstate_memhp_state,
&vmstate_cpuhp_state,
NULL
}
};
static void piix4_pm_reset(DeviceState *dev)
{
PIIX4PMState *s = PIIX4_PM(dev);
PCIDevice *d = PCI_DEVICE(s);
uint8_t *pci_conf = d->config;
pci_conf[0x58] = 0;
pci_conf[0x59] = 0;
pci_conf[0x5a] = 0;
pci_conf[0x5b] = 0;
pci_conf[0x40] = 0x01; /* PM io base read only bit */
pci_conf[0x80] = 0;
if (!s->smm_enabled) {
/* Mark SMM as already inited (until KVM supports SMM). */
pci_conf[0x5B] = 0x02;
}
acpi_pm1_evt_reset(&s->ar);
acpi_pm1_cnt_reset(&s->ar);
acpi_pm_tmr_reset(&s->ar);
acpi_gpe_reset(&s->ar);
acpi_update_sci(&s->ar, s->irq);
pm_io_space_update(s);
Introduce a new flag for i440fx to disable PCI hotplug on the root bus We introduce a new global flag 'acpi-root-pci-hotplug' for i440fx with which we can turn on or off PCI device hotplug on the root bus. This flag can be used to prevent all PCI devices from getting hotplugged or unplugged from the root PCI bus. This feature is targetted mostly towards Windows VMs. It is useful in cases where some hypervisor admins want to deploy guest VMs in a way so that the users of the guest OSes are not able to hot-eject certain PCI devices from the Windows system tray. Laine has explained the use case here in detail: https://www.redhat.com/archives/libvir-list/2020-February/msg00110.html Julia has resolved this issue for PCIE buses with the following commit: 530a0963184e57e71a5b538 ("pcie_root_port: Add hotplug disabling option") This commit attempts to introduce similar behavior for PCI root buses used in i440fx machine types (although in this case, we do not have a per-slot capability to turn hotplug on or off). Usage: -global PIIX4_PM.acpi-root-pci-hotplug=off By default, this option is enabled which means that hotplug is turned on for the PCI root bus. The previously existing flag 'acpi-pci-hotplug-with-bridge-support' for PCI-PCI bridges remain as is and can be used along with this new flag to control PCI hotplug on PCI bridges. This change has been tested using a Windows 2012R2 server guest image and also with a Windows 2019 server guest image on a Ubuntu 18.04 host using the latest master qemu from upstream. Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20200821165403.26589-1-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2020-08-21 19:54:03 +03:00
acpi_pcihp_reset(&s->acpi_pci_hotplug, !s->use_acpi_root_pci_hotplug);
}
static void piix4_pm_powerdown_req(Notifier *n, void *opaque)
{
PIIX4PMState *s = container_of(n, PIIX4PMState, powerdown_notifier);
assert(s != NULL);
acpi_pm1_evt_power_down(&s->ar);
}
static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(hotplug_dev);
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
acpi_pcihp_device_pre_plug_cb(hotplug_dev, dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
if (!s->acpi_memory_hotplug.is_enabled) {
error_setg(errp,
"memory hotplug is not enabled: %s.memory-hotplug-support "
"is not set", object_get_typename(OBJECT(s)));
}
} else if (
!object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
error_setg(errp, "acpi: device pre plug request for not supported"
" device type: %s", object_get_typename(OBJECT(dev)));
}
}
static void piix4_device_plug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(hotplug_dev);
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
nvdimm_acpi_plug_cb(hotplug_dev, dev);
} else {
acpi_memory_plug_cb(hotplug_dev, &s->acpi_memory_hotplug,
dev, errp);
}
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
acpi_pcihp_device_plug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
if (s->cpu_hotplug_legacy) {
legacy_acpi_cpu_plug_cb(hotplug_dev, &s->gpe_cpu, dev, errp);
} else {
acpi_cpu_plug_cb(hotplug_dev, &s->cpuhp_state, dev, errp);
}
} else {
g_assert_not_reached();
}
}
static void piix4_device_unplug_request_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(hotplug_dev);
if (s->acpi_memory_hotplug.is_enabled &&
object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
acpi_memory_unplug_request_cb(hotplug_dev, &s->acpi_memory_hotplug,
dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
acpi_pcihp_device_unplug_request_cb(hotplug_dev, &s->acpi_pci_hotplug,
dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!s->cpu_hotplug_legacy) {
acpi_cpu_unplug_request_cb(hotplug_dev, &s->cpuhp_state, dev, errp);
} else {
error_setg(errp, "acpi: device unplug request for not supported device"
" type: %s", object_get_typename(OBJECT(dev)));
}
}
static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(hotplug_dev);
if (s->acpi_memory_hotplug.is_enabled &&
object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
acpi_memory_unplug_cb(&s->acpi_memory_hotplug, dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
acpi_pcihp_device_unplug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev,
errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!s->cpu_hotplug_legacy) {
acpi_cpu_unplug_cb(&s->cpuhp_state, dev, errp);
} else {
error_setg(errp, "acpi: device unplug for not supported device"
" type: %s", object_get_typename(OBJECT(dev)));
}
}
static void piix4_pm_machine_ready(Notifier *n, void *opaque)
report serial devices created with -device in the PIIX4 config space Serial and parallel devices created with -device are not reported in the PIIX4 configuration space, and are hence not picked up by the DSDT. This upsets Windows, which hides them altogether from the guest. To avoid this, check at the end of machine initialization whether the corresponding I/O ports have been registered. The new function in ioport.c does this; this also requires a tweak to isa_unassign_ioport. I left the comment in piix4_pm_initfn since the registers I moved do seem to match the 82371AB datasheet. There are some quirks though. We are setting this bit: "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable the decode." but not LPT_MON_EN (bit 18 at 50h): LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel port address range (LPT_DEC_SEL) to generate a device 8 (parallel port) decode event. 0=Disable. We're also setting the LPT_DEC_SEL field (that's the 0x60 written to 63h) to 11, which means reserved, rather than to 01 (378h-37Fh). Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14 and bit 16 at address 50h) for the serial ports. However, we're setting COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register for the parallel port. All these fields are left as they are, since they are probably only meant to be used in the DSDT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-15 19:10:15 +04:00
{
PIIX4PMState *s = container_of(n, PIIX4PMState, machine_ready);
PCIDevice *d = PCI_DEVICE(s);
MemoryRegion *io_as = pci_address_space_io(d);
report serial devices created with -device in the PIIX4 config space Serial and parallel devices created with -device are not reported in the PIIX4 configuration space, and are hence not picked up by the DSDT. This upsets Windows, which hides them altogether from the guest. To avoid this, check at the end of machine initialization whether the corresponding I/O ports have been registered. The new function in ioport.c does this; this also requires a tweak to isa_unassign_ioport. I left the comment in piix4_pm_initfn since the registers I moved do seem to match the 82371AB datasheet. There are some quirks though. We are setting this bit: "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable the decode." but not LPT_MON_EN (bit 18 at 50h): LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel port address range (LPT_DEC_SEL) to generate a device 8 (parallel port) decode event. 0=Disable. We're also setting the LPT_DEC_SEL field (that's the 0x60 written to 63h) to 11, which means reserved, rather than to 01 (378h-37Fh). Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14 and bit 16 at address 50h) for the serial ports. However, we're setting COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register for the parallel port. All these fields are left as they are, since they are probably only meant to be used in the DSDT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-15 19:10:15 +04:00
uint8_t *pci_conf;
pci_conf = d->config;
pci_conf[0x5f] = 0x10 |
(memory_region_present(io_as, 0x378) ? 0x80 : 0);
report serial devices created with -device in the PIIX4 config space Serial and parallel devices created with -device are not reported in the PIIX4 configuration space, and are hence not picked up by the DSDT. This upsets Windows, which hides them altogether from the guest. To avoid this, check at the end of machine initialization whether the corresponding I/O ports have been registered. The new function in ioport.c does this; this also requires a tweak to isa_unassign_ioport. I left the comment in piix4_pm_initfn since the registers I moved do seem to match the 82371AB datasheet. There are some quirks though. We are setting this bit: "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable the decode." but not LPT_MON_EN (bit 18 at 50h): LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel port address range (LPT_DEC_SEL) to generate a device 8 (parallel port) decode event. 0=Disable. We're also setting the LPT_DEC_SEL field (that's the 0x60 written to 63h) to 11, which means reserved, rather than to 01 (378h-37Fh). Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14 and bit 16 at address 50h) for the serial ports. However, we're setting COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register for the parallel port. All these fields are left as they are, since they are probably only meant to be used in the DSDT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-15 19:10:15 +04:00
pci_conf[0x63] = 0x60;
pci_conf[0x67] = (memory_region_present(io_as, 0x3f8) ? 0x08 : 0) |
(memory_region_present(io_as, 0x2f8) ? 0x90 : 0);
report serial devices created with -device in the PIIX4 config space Serial and parallel devices created with -device are not reported in the PIIX4 configuration space, and are hence not picked up by the DSDT. This upsets Windows, which hides them altogether from the guest. To avoid this, check at the end of machine initialization whether the corresponding I/O ports have been registered. The new function in ioport.c does this; this also requires a tweak to isa_unassign_ioport. I left the comment in piix4_pm_initfn since the registers I moved do seem to match the 82371AB datasheet. There are some quirks though. We are setting this bit: "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable the decode." but not LPT_MON_EN (bit 18 at 50h): LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel port address range (LPT_DEC_SEL) to generate a device 8 (parallel port) decode event. 0=Disable. We're also setting the LPT_DEC_SEL field (that's the 0x60 written to 63h) to 11, which means reserved, rather than to 01 (378h-37Fh). Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14 and bit 16 at address 50h) for the serial ports. However, we're setting COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register for the parallel port. All these fields are left as they are, since they are probably only meant to be used in the DSDT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-15 19:10:15 +04:00
}
static void piix4_pm_add_properties(PIIX4PMState *s)
{
static const uint8_t acpi_enable_cmd = ACPI_ENABLE;
static const uint8_t acpi_disable_cmd = ACPI_DISABLE;
static const uint32_t gpe0_blk = GPE_BASE;
static const uint32_t gpe0_blk_len = GPE_LEN;
static const uint16_t sci_int = 9;
object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_ENABLE_CMD,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&acpi_enable_cmd, OBJ_PROP_FLAG_READ);
object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_DISABLE_CMD,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&acpi_disable_cmd, OBJ_PROP_FLAG_READ);
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_GPE0_BLK,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&gpe0_blk, OBJ_PROP_FLAG_READ);
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_GPE0_BLK_LEN,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&gpe0_blk_len, OBJ_PROP_FLAG_READ);
object_property_add_uint16_ptr(OBJECT(s), ACPI_PM_PROP_SCI_INT,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&sci_int, OBJ_PROP_FLAG_READ);
object_property_add_uint32_ptr(OBJECT(s), ACPI_PM_PROP_PM_IO_BASE,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
&s->io_base, OBJ_PROP_FLAG_READ);
}
static void piix4_pm_realize(PCIDevice *dev, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(dev);
uint8_t *pci_conf;
pci_conf = dev->config;
pci_conf[0x06] = 0x80;
pci_conf[0x07] = 0x02;
pci_conf[0x09] = 0x00;
pci_conf[0x3d] = 0x01; // interrupt pin 1
/* APM */
apm_init(dev, &s->apm, apm_ctrl_changed, s);
if (!s->smm_enabled) {
/* Mark SMM as already inited to prevent SMM from running. KVM does not
* support SMM mode. */
pci_conf[0x5B] = 0x02;
}
/* XXX: which specification is used ? The i82731AB has different
mappings */
pci_conf[0x90] = s->smb_io_base | 1;
pci_conf[0x91] = s->smb_io_base >> 8;
pci_conf[0xd2] = 0x09;
pm_smbus_init(DEVICE(dev), &s->smb, true);
memory_region_set_enabled(&s->smb.io, pci_conf[0xd2] & 1);
memory_region_add_subregion(pci_address_space_io(dev),
s->smb_io_base, &s->smb.io);
memory_region_init(&s->io, OBJECT(s), "piix4-pm", 64);
memory_region_set_enabled(&s->io, false);
memory_region_add_subregion(pci_address_space_io(dev),
0, &s->io);
acpi_pm_tmr_init(&s->ar, pm_tmr_timer, &s->io);
acpi_pm1_evt_init(&s->ar, pm_tmr_timer, &s->io);
acpi_pm1_cnt_init(&s->ar, &s->io, s->disable_s3, s->disable_s4, s->s4_val,
!s->smm_compat && !s->smm_enabled);
acpi_gpe_init(&s->ar, GPE_LEN);
s->powerdown_notifier.notify = piix4_pm_powerdown_req;
qemu_register_powerdown_notifier(&s->powerdown_notifier);
report serial devices created with -device in the PIIX4 config space Serial and parallel devices created with -device are not reported in the PIIX4 configuration space, and are hence not picked up by the DSDT. This upsets Windows, which hides them altogether from the guest. To avoid this, check at the end of machine initialization whether the corresponding I/O ports have been registered. The new function in ioport.c does this; this also requires a tweak to isa_unassign_ioport. I left the comment in piix4_pm_initfn since the registers I moved do seem to match the 82371AB datasheet. There are some quirks though. We are setting this bit: "Device 8 EIO Enable (EIO_EN_DEV8)—R/W. 1=Enable PCI access to the device 8 enabled I/O ranges to be claimed by PIIX4 and forwarded to the ISA/EIO bus. 0=Disable. The LPT_MON_EN must be set to enable the decode." but not LPT_MON_EN (bit 18 at 50h): LPT Port Enable (LPT_MON_EN)—R/W. 1=Enable accesses to parallel port address range (LPT_DEC_SEL) to generate a device 8 (parallel port) decode event. 0=Disable. We're also setting the LPT_DEC_SEL field (that's the 0x60 written to 63h) to 11, which means reserved, rather than to 01 (378h-37Fh). Likewise we're not setting SA_MON_EN, SB_MON_EN (respectively bit 14 and bit 16 at address 50h) for the serial ports. However, we're setting COMA_DEC_SEL and COMB_DEC_SEL correctly, unlike the corresponding register for the parallel port. All these fields are left as they are, since they are probably only meant to be used in the DSDT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-15 19:10:15 +04:00
s->machine_ready.notify = piix4_pm_machine_ready;
qemu_add_machine_init_done_notifier(&s->machine_ready);
if (xen_enabled()) {
s->use_acpi_hotplug_bridge = false;
}
piix4_acpi_system_hot_add_init(pci_address_space_io(dev),
pci_get_bus(dev), s);
qbus_set_hotplug_handler(BUS(pci_get_bus(dev)), OBJECT(s));
piix4_pm_add_properties(s);
}
static void piix4_pm_init(Object *obj)
{
PIIX4PMState *s = PIIX4_PM(obj);
qdev_init_gpio_out(DEVICE(obj), &s->irq, 1);
qdev_init_gpio_out_named(DEVICE(obj), &s->smi_irq, "smi-irq", 1);
}
static uint64_t gpe_readb(void *opaque, hwaddr addr, unsigned width)
{
PIIX4PMState *s = opaque;
uint32_t val = acpi_gpe_ioport_readb(&s->ar, addr);
trace_piix4_gpe_readb(addr, width, val);
return val;
}
static void gpe_writeb(void *opaque, hwaddr addr, uint64_t val,
unsigned width)
{
PIIX4PMState *s = opaque;
trace_piix4_gpe_writeb(addr, width, val);
acpi_gpe_ioport_writeb(&s->ar, addr, val);
acpi_update_sci(&s->ar, s->irq);
}
static const MemoryRegionOps piix4_gpe_ops = {
.read = gpe_readb,
.write = gpe_writeb,
.valid.min_access_size = 1,
.valid.max_access_size = 4,
.impl.min_access_size = 1,
.impl.max_access_size = 1,
.endianness = DEVICE_LITTLE_ENDIAN,
};
static bool piix4_get_cpu_hotplug_legacy(Object *obj, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(obj);
return s->cpu_hotplug_legacy;
}
static void piix4_set_cpu_hotplug_legacy(Object *obj, bool value, Error **errp)
{
PIIX4PMState *s = PIIX4_PM(obj);
assert(!value);
if (s->cpu_hotplug_legacy && value == false) {
acpi_switch_to_modern_cphp(&s->gpe_cpu, &s->cpuhp_state,
PIIX4_CPU_HOTPLUG_IO_BASE);
}
s->cpu_hotplug_legacy = value;
}
static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
PCIBus *bus, PIIX4PMState *s)
{
memory_region_init_io(&s->io_gpe, OBJECT(s), &piix4_gpe_ops, s,
"acpi-gpe0", GPE_LEN);
memory_region_add_subregion(parent, GPE_BASE, &s->io_gpe);
piix4: don't reserve hw resources when hotplug is off globally When acpi hotplug is turned off for both root pci bus as well as for pci bridges, we should not generate the related ACPI code for DSDT table or initialize related hw ports or reserve hw resources. This change makes sure all those operations are turned off in the case ACPI pci hotplug is off globally. In this change, we also make sure ACPI code for the PCNT method are only added when bsel is enabled for the corresponding pci bus or bridge hotplug is turned on. As q35 machines do not use bsel for it's pci buses at this point in time, this change affects DSDT acpi table for q35 machines as well. Therefore, we will also need to commit the updated golden master DSDT table acpi binary blobs as well. Following is the list of blobs which needs updating: tests/data/acpi/q35/DSDT tests/data/acpi/q35/DSDT.acpihmat tests/data/acpi/q35/DSDT.bridge tests/data/acpi/q35/DSDT.cphp tests/data/acpi/q35/DSDT.dimmpxm tests/data/acpi/q35/DSDT.ipmibt tests/data/acpi/q35/DSDT.memhp tests/data/acpi/q35/DSDT.mmio64 tests/data/acpi/q35/DSDT.numamem tests/data/acpi/q35/DSDT.tis These tables are updated in the following commit. Without the updated table blobs, the unit tests would fail with this patch. Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200918084111.15339-11-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-18 11:41:08 +03:00
if (s->use_acpi_hotplug_bridge || s->use_acpi_root_pci_hotplug) {
acpi_pcihp_init(OBJECT(s), &s->acpi_pci_hotplug, bus, parent,
s->use_acpi_hotplug_bridge, ACPI_PCIHP_ADDR_PIIX4);
piix4: don't reserve hw resources when hotplug is off globally When acpi hotplug is turned off for both root pci bus as well as for pci bridges, we should not generate the related ACPI code for DSDT table or initialize related hw ports or reserve hw resources. This change makes sure all those operations are turned off in the case ACPI pci hotplug is off globally. In this change, we also make sure ACPI code for the PCNT method are only added when bsel is enabled for the corresponding pci bus or bridge hotplug is turned on. As q35 machines do not use bsel for it's pci buses at this point in time, this change affects DSDT acpi table for q35 machines as well. Therefore, we will also need to commit the updated golden master DSDT table acpi binary blobs as well. Following is the list of blobs which needs updating: tests/data/acpi/q35/DSDT tests/data/acpi/q35/DSDT.acpihmat tests/data/acpi/q35/DSDT.bridge tests/data/acpi/q35/DSDT.cphp tests/data/acpi/q35/DSDT.dimmpxm tests/data/acpi/q35/DSDT.ipmibt tests/data/acpi/q35/DSDT.memhp tests/data/acpi/q35/DSDT.mmio64 tests/data/acpi/q35/DSDT.numamem tests/data/acpi/q35/DSDT.tis These tables are updated in the following commit. Without the updated table blobs, the unit tests would fail with this patch. Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200918084111.15339-11-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-18 11:41:08 +03:00
}
s->cpu_hotplug_legacy = true;
object_property_add_bool(OBJECT(s), "cpu-hotplug-legacy",
piix4_get_cpu_hotplug_legacy,
qom: Drop parameter @errp of object_property_add() & friends The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
piix4_set_cpu_hotplug_legacy);
legacy_acpi_cpu_hotplug_init(parent, OBJECT(s), &s->gpe_cpu,
PIIX4_CPU_HOTPLUG_IO_BASE);
if (s->acpi_memory_hotplug.is_enabled) {
acpi_memory_hotplug_init(parent, OBJECT(s), &s->acpi_memory_hotplug,
ACPI_MEMORY_HOTPLUG_BASE);
}
}
static void piix4_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list)
{
PIIX4PMState *s = PIIX4_PM(adev);
acpi_memory_ospm_status(&s->acpi_memory_hotplug, list);
if (!s->cpu_hotplug_legacy) {
acpi_cpu_ospm_status(&s->cpuhp_state, list);
}
}
static void piix4_send_gpe(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
{
PIIX4PMState *s = PIIX4_PM(adev);
acpi_send_gpe_event(&s->ar, s->irq, ev);
}
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S4_DISABLED, PIIX4PMState, disable_s4, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S4_VAL, PIIX4PMState, s4_val, 2),
DEFINE_PROP_BOOL(ACPI_PM_PROP_ACPI_PCIHP_BRIDGE, PIIX4PMState,
use_acpi_hotplug_bridge, true),
DEFINE_PROP_BOOL(ACPI_PM_PROP_ACPI_PCI_ROOTHP, PIIX4PMState,
Introduce a new flag for i440fx to disable PCI hotplug on the root bus We introduce a new global flag 'acpi-root-pci-hotplug' for i440fx with which we can turn on or off PCI device hotplug on the root bus. This flag can be used to prevent all PCI devices from getting hotplugged or unplugged from the root PCI bus. This feature is targetted mostly towards Windows VMs. It is useful in cases where some hypervisor admins want to deploy guest VMs in a way so that the users of the guest OSes are not able to hot-eject certain PCI devices from the Windows system tray. Laine has explained the use case here in detail: https://www.redhat.com/archives/libvir-list/2020-February/msg00110.html Julia has resolved this issue for PCIE buses with the following commit: 530a0963184e57e71a5b538 ("pcie_root_port: Add hotplug disabling option") This commit attempts to introduce similar behavior for PCI root buses used in i440fx machine types (although in this case, we do not have a per-slot capability to turn hotplug on or off). Usage: -global PIIX4_PM.acpi-root-pci-hotplug=off By default, this option is enabled which means that hotplug is turned on for the PCI root bus. The previously existing flag 'acpi-pci-hotplug-with-bridge-support' for PCI-PCI bridges remain as is and can be used along with this new flag to control PCI hotplug on PCI bridges. This change has been tested using a Windows 2012R2 server guest image and also with a Windows 2019 server guest image on a Ubuntu 18.04 host using the latest master qemu from upstream. Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20200821165403.26589-1-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2020-08-21 19:54:03 +03:00
use_acpi_root_pci_hotplug, true),
DEFINE_PROP_BOOL("memory-hotplug-support", PIIX4PMState,
acpi_memory_hotplug.is_enabled, true),
DEFINE_PROP_BOOL("smm-compat", PIIX4PMState, smm_compat, false),
DEFINE_PROP_BOOL("smm-enabled", PIIX4PMState, smm_enabled, false),
DEFINE_PROP_BOOL("x-not-migrate-acpi-index", PIIX4PMState,
not_migrate_acpi_index, false),
DEFINE_PROP_END_OF_LIST(),
};
static void piix4_pm_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_CLASS(klass);
k->realize = piix4_pm_realize;
k->config_write = pm_write_config;
k->vendor_id = PCI_VENDOR_ID_INTEL;
k->device_id = PCI_DEVICE_ID_INTEL_82371AB_3;
k->revision = 0x03;
k->class_id = PCI_CLASS_BRIDGE_OTHER;
dc->reset = piix4_pm_reset;
dc->desc = "PM";
dc->vmsd = &vmstate_acpi;
device_class_set_props(dc, piix4_pm_properties);
/*
* Reason: part of PIIX4 southbridge, needs to be wired up,
* e.g. by mips_malta_init()
*/
qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-03 23:35:44 +03:00
dc->user_creatable = false;
dc->hotpluggable = false;
hc->pre_plug = piix4_device_pre_plug_cb;
hc->plug = piix4_device_plug_cb;
hc->unplug_request = piix4_device_unplug_request_cb;
hc->unplug = piix4_device_unplug_cb;
adevc->ospm_status = piix4_ospm_status;
adevc->send_event = piix4_send_gpe;
adevc->madt_cpu = pc_madt_cpu_entry;
}
static const TypeInfo piix4_pm_info = {
.name = TYPE_PIIX4_PM,
.parent = TYPE_PCI_DEVICE,
.instance_init = piix4_pm_init,
.instance_size = sizeof(PIIX4PMState),
.class_init = piix4_pm_class_init,
.interfaces = (InterfaceInfo[]) {
{ TYPE_HOTPLUG_HANDLER },
{ TYPE_ACPI_DEVICE_IF },
pci: Add INTERFACE_CONVENTIONAL_PCI_DEVICE to Conventional PCI devices Add INTERFACE_CONVENTIONAL_PCI_DEVICE to all direct subtypes of TYPE_PCI_DEVICE, except: 1) The ones that already have INTERFACE_PCIE_DEVICE set: * base-xhci * e1000e * nvme * pvscsi * vfio-pci * virtio-pci * vmxnet3 2) base-pci-bridge Not all PCI bridges are Conventional PCI devices, so INTERFACE_CONVENTIONAL_PCI_DEVICE is added only to the subtypes that are actually Conventional PCI: * dec-21154-p2p-bridge * i82801b11-bridge * pbm-bridge * pci-bridge The direct subtypes of base-pci-bridge not touched by this patch are: * xilinx-pcie-root: Already marked as PCIe-only. * pcie-pci-bridge: Already marked as PCIe-only. * pcie-port: all non-abstract subtypes of pcie-port are already marked as PCIe-only devices. 3) megasas-base Not all megasas devices are Conventional PCI devices, so the interface names are added to the subclasses registered by megasas_register_types(), according to information in the megasas_devices[] array. "megasas-gen2" already implements INTERFACE_PCIE_DEVICE, so add INTERFACE_CONVENTIONAL_PCI_DEVICE only to "megasas". Acked-by: Alberto Garcia <berto@igalia.com> Acked-by: John Snow <jsnow@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-09-27 22:56:34 +03:00
{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
{ }
}
};
static void piix4_pm_register_types(void)
{
type_register_static(&piix4_pm_info);
}
type_init(piix4_pm_register_types)