2012-11-14 21:54:05 +01:00
|
|
|
/*
|
2012-10-30 03:11:31 +01:00
|
|
|
* QEMU ICH9 Emulation
|
|
|
|
*
|
2012-11-14 21:54:05 +01:00
|
|
|
* Copyright (c) 2006 Fabrice Bellard
|
2012-10-30 03:11:31 +01:00
|
|
|
* Copyright (c) 2009, 2010, 2011
|
|
|
|
* Isaku Yamahata <yamahata at valinux co jp>
|
|
|
|
* VA Linux Systems Japan K.K.
|
|
|
|
* Copyright (C) 2012 Jason Baron <jbaron@redhat.com>
|
|
|
|
*
|
2014-08-11 10:10:25 +02:00
|
|
|
* This is based on piix.c, but heavily modified.
|
2012-11-14 21:54:05 +01:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2019-08-12 07:23:42 +02:00
|
|
|
|
2016-01-26 19:17:03 +01:00
|
|
|
#include "qemu/osdep.h"
|
2020-07-17 17:17:05 +02:00
|
|
|
#include "qemu/log.h"
|
2016-01-19 21:51:44 +01:00
|
|
|
#include "cpu.h"
|
2013-07-24 17:56:10 +02:00
|
|
|
#include "qapi/visitor.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/range.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/isa/isa.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/sysbus.h"
|
2019-08-12 07:23:45 +02:00
|
|
|
#include "migration/vmstate.h"
|
2019-08-12 07:23:42 +02:00
|
|
|
#include "hw/irq.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/isa/apm.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/pci/pci.h"
|
|
|
|
#include "hw/pci/pci_bridge.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/i386/ich9.h"
|
|
|
|
#include "hw/acpi/acpi.h"
|
|
|
|
#include "hw/acpi/ich9.h"
|
2013-02-04 15:40:22 +01:00
|
|
|
#include "hw/pci/pci_bus.h"
|
2019-08-12 07:23:51 +02:00
|
|
|
#include "hw/qdev-properties.h"
|
2012-12-17 18:19:49 +01:00
|
|
|
#include "exec/address-spaces.h"
|
2019-08-12 07:23:59 +02:00
|
|
|
#include "sysemu/runstate.h"
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/sysemu.h"
|
2019-07-09 17:20:52 +02:00
|
|
|
#include "hw/core/cpu.h"
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
#include "hw/nvram/fw_cfg.h"
|
|
|
|
#include "qemu/cutils.h"
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
/*****************************************************************************/
|
|
|
|
/* ICH9 LPC PCI to ISA bridge */
|
|
|
|
|
|
|
|
static void ich9_lpc_reset(DeviceState *qdev);
|
|
|
|
|
|
|
|
/* chipset configuration register
|
|
|
|
* to access chipset configuration registers, pci_[sg]et_{byte, word, long}
|
|
|
|
* are used.
|
|
|
|
* Although it's not pci configuration space, it's little endian as Intel.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void ich9_cc_update_ir(uint8_t irr[PCI_NUM_PINS], uint16_t ir)
|
|
|
|
{
|
|
|
|
int intx;
|
|
|
|
for (intx = 0; intx < PCI_NUM_PINS; intx++) {
|
|
|
|
irr[intx] = (ir >> (intx * ICH9_CC_DIR_SHIFT)) & ICH9_CC_DIR_MASK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_cc_update(ICH9LPCState *lpc)
|
|
|
|
{
|
|
|
|
int slot;
|
|
|
|
int pci_intx;
|
|
|
|
|
|
|
|
const int reg_offsets[] = {
|
|
|
|
ICH9_CC_D25IR,
|
|
|
|
ICH9_CC_D26IR,
|
|
|
|
ICH9_CC_D27IR,
|
|
|
|
ICH9_CC_D28IR,
|
|
|
|
ICH9_CC_D29IR,
|
|
|
|
ICH9_CC_D30IR,
|
|
|
|
ICH9_CC_D31IR,
|
|
|
|
};
|
|
|
|
const int *offset;
|
|
|
|
|
|
|
|
/* D{25 - 31}IR, but D30IR is read only to 0. */
|
|
|
|
for (slot = 25, offset = reg_offsets; slot < 32; slot++, offset++) {
|
|
|
|
if (slot == 30) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
ich9_cc_update_ir(lpc->irr[slot],
|
|
|
|
pci_get_word(lpc->chip_config + *offset));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* D30: DMI2PCI bridge
|
2016-05-17 03:41:18 +02:00
|
|
|
* It is arbitrarily decided how INTx lines of PCI devices behind
|
|
|
|
* the bridge are connected to pirq lines. Our choice is PIRQ[E-H].
|
2012-11-14 21:54:05 +01:00
|
|
|
* INT[A-D] are connected to PIRQ[E-H]
|
|
|
|
*/
|
|
|
|
for (pci_intx = 0; pci_intx < PCI_NUM_PINS; pci_intx++) {
|
|
|
|
lpc->irr[30][pci_intx] = pci_intx + 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_cc_init(ICH9LPCState *lpc)
|
|
|
|
{
|
|
|
|
int slot;
|
|
|
|
int intx;
|
|
|
|
|
|
|
|
/* the default irq routing is arbitrary as long as it matches with
|
|
|
|
* acpi irq routing table.
|
|
|
|
* The one that is incompatible with piix_pci(= bochs) one is
|
|
|
|
* intentionally chosen to let the users know that the different
|
|
|
|
* board is used.
|
|
|
|
*
|
|
|
|
* int[A-D] -> pirq[E-F]
|
|
|
|
* avoid pirq A-D because they are used for pci express port
|
|
|
|
*/
|
|
|
|
for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
|
|
|
|
for (intx = 0; intx < PCI_NUM_PINS; intx++) {
|
|
|
|
lpc->irr[slot][intx] = (slot + intx) % 4 + 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ich9_cc_update(lpc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_cc_reset(ICH9LPCState *lpc)
|
|
|
|
{
|
|
|
|
uint8_t *c = lpc->chip_config;
|
|
|
|
|
|
|
|
memset(lpc->chip_config, 0, sizeof(lpc->chip_config));
|
|
|
|
|
|
|
|
pci_set_long(c + ICH9_CC_D31IR, ICH9_CC_DIR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D30IR, ICH9_CC_D30IR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D29IR, ICH9_CC_DIR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D28IR, ICH9_CC_DIR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D27IR, ICH9_CC_DIR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D26IR, ICH9_CC_DIR_DEFAULT);
|
|
|
|
pci_set_long(c + ICH9_CC_D25IR, ICH9_CC_DIR_DEFAULT);
|
2015-06-28 19:58:56 +02:00
|
|
|
pci_set_long(c + ICH9_CC_GCS, ICH9_CC_GCS_DEFAULT);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
ich9_cc_update(lpc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_cc_addr_len(uint64_t *addr, unsigned *len)
|
|
|
|
{
|
|
|
|
*addr &= ICH9_CC_ADDR_MASK;
|
|
|
|
if (*addr + *len >= ICH9_CC_SIZE) {
|
|
|
|
*len = ICH9_CC_SIZE - *addr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* val: little endian */
|
|
|
|
static void ich9_cc_write(void *opaque, hwaddr addr,
|
|
|
|
uint64_t val, unsigned len)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = (ICH9LPCState *)opaque;
|
|
|
|
|
|
|
|
ich9_cc_addr_len(&addr, &len);
|
|
|
|
memcpy(lpc->chip_config + addr, &val, len);
|
2017-11-29 09:46:27 +01:00
|
|
|
pci_bus_fire_intx_routing_notifier(pci_get_bus(&lpc->d));
|
2012-11-14 21:54:05 +01:00
|
|
|
ich9_cc_update(lpc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* return value: little endian */
|
|
|
|
static uint64_t ich9_cc_read(void *opaque, hwaddr addr,
|
|
|
|
unsigned len)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = (ICH9LPCState *)opaque;
|
|
|
|
|
|
|
|
uint32_t val = 0;
|
|
|
|
ich9_cc_addr_len(&addr, &len);
|
|
|
|
memcpy(&val, lpc->chip_config + addr, len);
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* IRQ routing */
|
|
|
|
/* */
|
|
|
|
static void ich9_lpc_rout(uint8_t pirq_rout, int *pic_irq, int *pic_dis)
|
|
|
|
{
|
|
|
|
*pic_irq = pirq_rout & ICH9_LPC_PIRQ_ROUT_MASK;
|
|
|
|
*pic_dis = pirq_rout & ICH9_LPC_PIRQ_ROUT_IRQEN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_lpc_pic_irq(ICH9LPCState *lpc, int pirq_num,
|
|
|
|
int *pic_irq, int *pic_dis)
|
|
|
|
{
|
|
|
|
switch (pirq_num) {
|
|
|
|
case 0 ... 3: /* A-D */
|
|
|
|
ich9_lpc_rout(lpc->d.config[ICH9_LPC_PIRQA_ROUT + pirq_num],
|
|
|
|
pic_irq, pic_dis);
|
|
|
|
return;
|
|
|
|
case 4 ... 7: /* E-H */
|
|
|
|
ich9_lpc_rout(lpc->d.config[ICH9_LPC_PIRQE_ROUT + (pirq_num - 4)],
|
|
|
|
pic_irq, pic_dis);
|
|
|
|
return;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:07:31 +02:00
|
|
|
/* gsi: i8259+ioapic irq 0-15, otherwise assert */
|
|
|
|
static void ich9_lpc_update_pic(ICH9LPCState *lpc, int gsi)
|
2012-11-14 21:54:05 +01:00
|
|
|
{
|
|
|
|
int i, pic_level;
|
|
|
|
|
2016-06-17 17:07:31 +02:00
|
|
|
assert(gsi < ICH9_LPC_PIC_NUM_PINS);
|
|
|
|
|
2012-11-14 21:54:05 +01:00
|
|
|
/* The pic level is the logical OR of all the PCI irqs mapped to it */
|
|
|
|
pic_level = 0;
|
|
|
|
for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
|
|
|
|
int tmp_irq;
|
|
|
|
int tmp_dis;
|
|
|
|
ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
|
2016-06-17 17:07:31 +02:00
|
|
|
if (!tmp_dis && tmp_irq == gsi) {
|
2017-11-29 09:46:27 +01:00
|
|
|
pic_level |= pci_bus_get_irq_level(pci_get_bus(&lpc->d), i);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
}
|
2016-06-23 07:54:22 +02:00
|
|
|
if (gsi == lpc->sci_gsi) {
|
2012-11-14 21:54:05 +01:00
|
|
|
pic_level |= lpc->sci_level;
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:12:09 +02:00
|
|
|
qemu_set_irq(lpc->gsi[gsi], pic_level);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* APIC mode: GSIx: PIRQ[A-H] -> GSI 16, ... no pirq shares same APIC pins. */
|
|
|
|
static int ich9_pirq_to_gsi(int pirq)
|
|
|
|
{
|
|
|
|
return pirq + ICH9_LPC_PIC_NUM_PINS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ich9_gsi_to_pirq(int gsi)
|
|
|
|
{
|
|
|
|
return gsi - ICH9_LPC_PIC_NUM_PINS;
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:07:31 +02:00
|
|
|
/* gsi: ioapic irq 16-23, otherwise assert */
|
2012-11-14 21:54:05 +01:00
|
|
|
static void ich9_lpc_update_apic(ICH9LPCState *lpc, int gsi)
|
|
|
|
{
|
2012-11-14 21:54:08 +01:00
|
|
|
int level = 0;
|
2012-11-14 21:54:05 +01:00
|
|
|
|
2016-06-17 17:07:31 +02:00
|
|
|
assert(gsi >= ICH9_LPC_PIC_NUM_PINS);
|
|
|
|
|
2017-11-29 09:46:27 +01:00
|
|
|
level |= pci_bus_get_irq_level(pci_get_bus(&lpc->d), ich9_gsi_to_pirq(gsi));
|
2016-06-23 07:54:22 +02:00
|
|
|
if (gsi == lpc->sci_gsi) {
|
2012-11-14 21:54:05 +01:00
|
|
|
level |= lpc->sci_level;
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:12:09 +02:00
|
|
|
qemu_set_irq(lpc->gsi[gsi], level);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ich9_lpc_set_irq(void *opaque, int pirq, int level)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
2016-06-17 17:07:31 +02:00
|
|
|
int pic_irq, pic_dis;
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
assert(0 <= pirq);
|
|
|
|
assert(pirq < ICH9_LPC_NB_PIRQS);
|
|
|
|
|
|
|
|
ich9_lpc_update_apic(lpc, ich9_pirq_to_gsi(pirq));
|
2016-06-17 17:07:31 +02:00
|
|
|
ich9_lpc_pic_irq(lpc, pirq, &pic_irq, &pic_dis);
|
|
|
|
ich9_lpc_update_pic(lpc, pic_irq);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* return the pirq number (PIRQ[A-H]:0-7) corresponding to
|
|
|
|
* a given device irq pin.
|
|
|
|
*/
|
|
|
|
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx)
|
|
|
|
{
|
|
|
|
BusState *bus = qdev_get_parent_bus(&pci_dev->qdev);
|
|
|
|
PCIBus *pci_bus = PCI_BUS(bus);
|
|
|
|
PCIDevice *lpc_pdev =
|
|
|
|
pci_bus->devices[PCI_DEVFN(ICH9_LPC_DEV, ICH9_LPC_FUNC)];
|
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pdev);
|
|
|
|
|
|
|
|
return lpc->irr[PCI_SLOT(pci_dev->devfn)][intx];
|
|
|
|
}
|
|
|
|
|
2013-01-23 03:11:37 +01:00
|
|
|
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
PCIINTxRoute route;
|
|
|
|
int pic_irq;
|
|
|
|
int pic_dis;
|
|
|
|
|
|
|
|
assert(0 <= pirq_pin);
|
|
|
|
assert(pirq_pin < ICH9_LPC_NB_PIRQS);
|
|
|
|
|
|
|
|
route.mode = PCI_INTX_ENABLED;
|
|
|
|
ich9_lpc_pic_irq(lpc, pirq_pin, &pic_irq, &pic_dis);
|
|
|
|
if (!pic_dis) {
|
|
|
|
if (pic_irq < ICH9_LPC_PIC_NUM_PINS) {
|
|
|
|
route.irq = pic_irq;
|
|
|
|
} else {
|
|
|
|
route.mode = PCI_INTX_DISABLED;
|
|
|
|
route.irq = -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
route.irq = ich9_pirq_to_gsi(pirq_pin);
|
|
|
|
}
|
|
|
|
|
|
|
|
return route;
|
|
|
|
}
|
|
|
|
|
2015-06-28 19:58:56 +02:00
|
|
|
void ich9_generate_smi(void)
|
|
|
|
{
|
|
|
|
cpu_interrupt(first_cpu, CPU_INTERRUPT_SMI);
|
|
|
|
}
|
|
|
|
|
2020-07-17 17:17:05 +02:00
|
|
|
/* Returns -1 on error, IRQ number on success */
|
2012-11-14 21:54:05 +01:00
|
|
|
static int ich9_lpc_sci_irq(ICH9LPCState *lpc)
|
|
|
|
{
|
2020-07-17 17:17:05 +02:00
|
|
|
uint8_t sel = lpc->d.config[ICH9_LPC_ACPI_CTRL] &
|
|
|
|
ICH9_LPC_ACPI_CTRL_SCI_IRQ_SEL_MASK;
|
|
|
|
switch (sel) {
|
2012-11-14 21:54:05 +01:00
|
|
|
case ICH9_LPC_ACPI_CTRL_9:
|
|
|
|
return 9;
|
|
|
|
case ICH9_LPC_ACPI_CTRL_10:
|
|
|
|
return 10;
|
|
|
|
case ICH9_LPC_ACPI_CTRL_11:
|
|
|
|
return 11;
|
|
|
|
case ICH9_LPC_ACPI_CTRL_20:
|
|
|
|
return 20;
|
|
|
|
case ICH9_LPC_ACPI_CTRL_21:
|
|
|
|
return 21;
|
|
|
|
default:
|
|
|
|
/* reserved */
|
2020-07-17 17:17:05 +02:00
|
|
|
qemu_log_mask(LOG_GUEST_ERROR,
|
|
|
|
"ICH9 LPC: SCI IRQ SEL #%u is reserved\n", sel);
|
2012-11-14 21:54:05 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_set_sci(void *opaque, int irq_num, int level)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
int irq;
|
|
|
|
|
|
|
|
assert(irq_num == 0);
|
|
|
|
level = !!level;
|
|
|
|
if (level == lpc->sci_level) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
lpc->sci_level = level;
|
|
|
|
|
2016-06-23 07:54:22 +02:00
|
|
|
irq = lpc->sci_gsi;
|
2012-11-14 21:54:05 +01:00
|
|
|
if (irq < 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:07:31 +02:00
|
|
|
if (irq >= ICH9_LPC_PIC_NUM_PINS) {
|
|
|
|
ich9_lpc_update_apic(lpc, irq);
|
|
|
|
} else {
|
2012-11-14 21:54:05 +01:00
|
|
|
ich9_lpc_update_pic(lpc, irq);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
static void smi_features_ok_callback(void *opaque)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
uint64_t guest_features;
|
2020-12-07 15:07:38 +01:00
|
|
|
uint64_t guest_cpu_hotplug_features;
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
|
|
|
|
if (lpc->smi_features_ok) {
|
|
|
|
/* negotiation already complete, features locked */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(&guest_features, lpc->smi_guest_features_le, sizeof guest_features);
|
|
|
|
le64_to_cpus(&guest_features);
|
|
|
|
if (guest_features & ~lpc->smi_host_features) {
|
|
|
|
/* guest requests invalid features, leave @features_ok at zero */
|
|
|
|
return;
|
|
|
|
}
|
2020-12-07 15:07:38 +01:00
|
|
|
|
|
|
|
guest_cpu_hotplug_features = guest_features &
|
|
|
|
(BIT_ULL(ICH9_LPC_SMI_F_CPU_HOTPLUG_BIT) |
|
|
|
|
BIT_ULL(ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT));
|
2020-09-23 11:46:40 +02:00
|
|
|
if (!(guest_features & BIT_ULL(ICH9_LPC_SMI_F_BROADCAST_BIT)) &&
|
2020-12-07 15:07:38 +01:00
|
|
|
guest_cpu_hotplug_features) {
|
2020-09-23 11:46:40 +02:00
|
|
|
/*
|
|
|
|
* cpu hot-[un]plug with SMI requires SMI broadcast,
|
|
|
|
* leave @features_ok at zero
|
|
|
|
*/
|
|
|
|
return;
|
|
|
|
}
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
|
2020-12-07 15:07:39 +01:00
|
|
|
if (guest_cpu_hotplug_features ==
|
|
|
|
BIT_ULL(ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT)) {
|
|
|
|
/* cpu hot-unplug is unsupported without cpu-hotplug */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
/* valid feature subset requested, lock it down, report success */
|
|
|
|
lpc->smi_negotiated_features = guest_features;
|
|
|
|
lpc->smi_features_ok = 1;
|
|
|
|
}
|
|
|
|
|
2016-01-23 17:02:11 +01:00
|
|
|
void ich9_lpc_pm_init(PCIDevice *lpc_pci, bool smm_enabled)
|
2012-11-14 21:54:05 +01:00
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(lpc_pci);
|
2015-06-18 18:30:51 +02:00
|
|
|
qemu_irq sci_irq;
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
FWCfgState *fw_cfg = fw_cfg_find();
|
2012-11-14 21:54:05 +01:00
|
|
|
|
2015-06-18 18:30:51 +02:00
|
|
|
sci_irq = qemu_allocate_irq(ich9_set_sci, lpc, 0);
|
2016-01-23 17:02:11 +01:00
|
|
|
ich9_pm_init(lpc_pci, &lpc->pm, smm_enabled, sci_irq);
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
|
|
|
|
if (lpc->smi_host_features && fw_cfg) {
|
|
|
|
uint64_t host_features_le;
|
|
|
|
|
|
|
|
host_features_le = cpu_to_le64(lpc->smi_host_features);
|
|
|
|
memcpy(lpc->smi_host_features_le, &host_features_le,
|
|
|
|
sizeof host_features_le);
|
|
|
|
fw_cfg_add_file(fw_cfg, "etc/smi/supported-features",
|
|
|
|
lpc->smi_host_features_le,
|
|
|
|
sizeof lpc->smi_host_features_le);
|
|
|
|
|
|
|
|
/* The other two guest-visible fields are cleared on device reset, we
|
|
|
|
* just link them into fw_cfg here.
|
|
|
|
*/
|
|
|
|
fw_cfg_add_file_callback(fw_cfg, "etc/smi/requested-features",
|
2017-09-11 18:59:23 +02:00
|
|
|
NULL, NULL, NULL,
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
lpc->smi_guest_features_le,
|
|
|
|
sizeof lpc->smi_guest_features_le,
|
|
|
|
false);
|
|
|
|
fw_cfg_add_file_callback(fw_cfg, "etc/smi/features-ok",
|
2017-09-11 18:59:23 +02:00
|
|
|
smi_features_ok_callback, NULL, lpc,
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
&lpc->smi_features_ok,
|
|
|
|
sizeof lpc->smi_features_ok,
|
|
|
|
true);
|
|
|
|
}
|
|
|
|
|
2019-05-28 18:40:17 +02:00
|
|
|
ich9_lpc_reset(DEVICE(lpc));
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* APM */
|
|
|
|
|
|
|
|
static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = arg;
|
|
|
|
|
|
|
|
/* ACPI specs 3.0, 4.7.2.5 */
|
|
|
|
acpi_pm1_cnt_update(&lpc->pm.acpi_regs,
|
|
|
|
val == ICH9_APM_ACPI_ENABLE,
|
|
|
|
val == ICH9_APM_ACPI_DISABLE);
|
2015-06-18 18:28:41 +02:00
|
|
|
if (val == ICH9_APM_ACPI_ENABLE || val == ICH9_APM_ACPI_DISABLE) {
|
|
|
|
return;
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
/* SMI_EN = PMBASE + 30. SMI control and enable register */
|
|
|
|
if (lpc->pm.smi_en & ICH9_PMIO_SMI_EN_APMC_EN) {
|
hw/isa/lpc_ich9: add broadcast SMI feature
The generic edk2 SMM infrastructure prefers
EFI_SMM_CONTROL2_PROTOCOL.Trigger() to inject an SMI on each processor. If
Trigger() only brings the current processor into SMM, then edk2 handles it
in the following ways:
(1) If Trigger() is executed by the BSP (which is guaranteed before
ExitBootServices(), but is not necessarily true at runtime), then:
(a) If edk2 has been configured for "traditional" SMM synchronization,
then the BSP sends directed SMIs to the APs with APIC delivery,
bringing them into SMM individually. Then the BSP runs the SMI
handler / dispatcher.
(b) If edk2 has been configured for "relaxed" SMM synchronization,
then the APs that are not already in SMM are not brought in, and
the BSP runs the SMI handler / dispatcher.
(2) If Trigger() is executed by an AP (which is possible after
ExitBootServices(), and can be forced e.g. by "taskset -c 1
efibootmgr"), then the AP in question brings in the BSP with a
directed SMI, and the BSP runs the SMI handler / dispatcher.
The smaller problem with (1a) and (2) is that the BSP and AP
synchronization is slow. For example, the "taskset -c 1 efibootmgr"
command from (2) can take more than 3 seconds to complete, because
efibootmgr accesses non-volatile UEFI variables intensively.
The larger problem is that QEMU's current behavior diverges from the
behavior usually seen on physical hardware, and that keeps exposing
obscure corner cases, race conditions and other instabilities in edk2,
which generally expects / prefers a software SMI to affect all CPUs at
once.
Therefore introduce the "broadcast SMI" feature that causes QEMU to inject
the SMI on all VCPUs.
While the original posting of this patch
<http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05658.html>
only intended to speed up (2), based on our recent "stress testing" of SMM
this patch actually provides functional improvements.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-3-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:15 +01:00
|
|
|
if (lpc->smi_negotiated_features &
|
|
|
|
(UINT64_C(1) << ICH9_LPC_SMI_F_BROADCAST_BIT)) {
|
|
|
|
CPUState *cs;
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
cpu_interrupt(cs, CPU_INTERRUPT_SMI);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* config:PMBASE */
|
|
|
|
static void
|
2016-06-23 07:49:16 +02:00
|
|
|
ich9_lpc_pmbase_sci_update(ICH9LPCState *lpc)
|
2012-11-14 21:54:05 +01:00
|
|
|
{
|
|
|
|
uint32_t pm_io_base = pci_get_long(lpc->d.config + ICH9_LPC_PMBASE);
|
2016-06-23 07:49:16 +02:00
|
|
|
uint8_t acpi_cntl = pci_get_long(lpc->d.config + ICH9_LPC_ACPI_CTRL);
|
2020-07-17 17:17:05 +02:00
|
|
|
int new_gsi;
|
2016-06-23 07:49:16 +02:00
|
|
|
|
|
|
|
if (acpi_cntl & ICH9_LPC_ACPI_CTRL_ACPI_EN) {
|
|
|
|
pm_io_base &= ICH9_LPC_PMBASE_BASE_ADDRESS_MASK;
|
|
|
|
} else {
|
|
|
|
pm_io_base = 0;
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
ich9_pm_iospace_update(&lpc->pm, pm_io_base);
|
2016-06-23 07:54:22 +02:00
|
|
|
|
|
|
|
new_gsi = ich9_lpc_sci_irq(lpc);
|
2020-07-17 17:17:05 +02:00
|
|
|
if (new_gsi == -1) {
|
|
|
|
return;
|
|
|
|
}
|
2016-06-23 07:54:22 +02:00
|
|
|
if (lpc->sci_level && new_gsi != lpc->sci_gsi) {
|
|
|
|
qemu_set_irq(lpc->pm.irq, 0);
|
|
|
|
lpc->sci_gsi = new_gsi;
|
|
|
|
qemu_set_irq(lpc->pm.irq, 1);
|
|
|
|
}
|
|
|
|
lpc->sci_gsi = new_gsi;
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
2016-03-07 13:38:58 +01:00
|
|
|
/* config:RCBA */
|
|
|
|
static void ich9_lpc_rcba_update(ICH9LPCState *lpc, uint32_t rcba_old)
|
2012-11-14 21:54:05 +01:00
|
|
|
{
|
2016-03-07 13:38:58 +01:00
|
|
|
uint32_t rcba = pci_get_long(lpc->d.config + ICH9_LPC_RCBA);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
2016-03-07 13:38:58 +01:00
|
|
|
if (rcba_old & ICH9_LPC_RCBA_EN) {
|
|
|
|
memory_region_del_subregion(get_system_memory(), &lpc->rcrb_mem);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
2016-03-07 13:38:58 +01:00
|
|
|
if (rcba & ICH9_LPC_RCBA_EN) {
|
|
|
|
memory_region_add_subregion_overlap(get_system_memory(),
|
|
|
|
rcba & ICH9_LPC_RCBA_BA_MASK,
|
|
|
|
&lpc->rcrb_mem, 1);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-06 10:58:30 +02:00
|
|
|
/* config:GEN_PMCON* */
|
|
|
|
static void
|
|
|
|
ich9_lpc_pmcon_update(ICH9LPCState *lpc)
|
|
|
|
{
|
|
|
|
uint16_t gen_pmcon_1 = pci_get_word(lpc->d.config + ICH9_LPC_GEN_PMCON_1);
|
|
|
|
uint16_t wmask;
|
|
|
|
|
|
|
|
if (gen_pmcon_1 & ICH9_LPC_GEN_PMCON_1_SMI_LOCK) {
|
|
|
|
wmask = pci_get_word(lpc->d.wmask + ICH9_LPC_GEN_PMCON_1);
|
|
|
|
wmask &= ~ICH9_LPC_GEN_PMCON_1_SMI_LOCK;
|
|
|
|
pci_set_word(lpc->d.wmask + ICH9_LPC_GEN_PMCON_1, wmask);
|
|
|
|
lpc->pm.smi_en_wmask &= ~1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:05 +01:00
|
|
|
static int ich9_lpc_post_load(void *opaque, int version_id)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
|
2016-06-23 07:54:22 +02:00
|
|
|
ich9_lpc_pmbase_sci_update(lpc);
|
2016-03-07 13:38:58 +01:00
|
|
|
ich9_lpc_rcba_update(lpc, 0 /* disabled ICH9_LPC_RCBA_EN */);
|
2015-05-06 10:58:30 +02:00
|
|
|
ich9_lpc_pmcon_update(lpc);
|
2012-11-14 21:54:05 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_lpc_config_write(PCIDevice *d,
|
|
|
|
uint32_t addr, uint32_t val, int len)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
|
2016-03-07 13:38:58 +01:00
|
|
|
uint32_t rcba_old = pci_get_long(d->config + ICH9_LPC_RCBA);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
pci_default_write_config(d, addr, val, len);
|
2016-06-23 07:49:16 +02:00
|
|
|
if (ranges_overlap(addr, len, ICH9_LPC_PMBASE, 4) ||
|
|
|
|
ranges_overlap(addr, len, ICH9_LPC_ACPI_CTRL, 1)) {
|
2016-06-23 07:54:22 +02:00
|
|
|
ich9_lpc_pmbase_sci_update(lpc);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
if (ranges_overlap(addr, len, ICH9_LPC_RCBA, 4)) {
|
2016-03-07 13:38:58 +01:00
|
|
|
ich9_lpc_rcba_update(lpc, rcba_old);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
2013-01-23 03:11:37 +01:00
|
|
|
if (ranges_overlap(addr, len, ICH9_LPC_PIRQA_ROUT, 4)) {
|
2017-11-29 09:46:27 +01:00
|
|
|
pci_bus_fire_intx_routing_notifier(pci_get_bus(&lpc->d));
|
2013-01-23 03:11:37 +01:00
|
|
|
}
|
|
|
|
if (ranges_overlap(addr, len, ICH9_LPC_PIRQE_ROUT, 4)) {
|
2017-11-29 09:46:27 +01:00
|
|
|
pci_bus_fire_intx_routing_notifier(pci_get_bus(&lpc->d));
|
2013-01-23 03:11:37 +01:00
|
|
|
}
|
2015-05-06 10:58:30 +02:00
|
|
|
if (ranges_overlap(addr, len, ICH9_LPC_GEN_PMCON_1, 8)) {
|
|
|
|
ich9_lpc_pmcon_update(lpc);
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ich9_lpc_reset(DeviceState *qdev)
|
|
|
|
{
|
|
|
|
PCIDevice *d = PCI_DEVICE(qdev);
|
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
|
2016-03-07 13:38:58 +01:00
|
|
|
uint32_t rcba_old = pci_get_long(d->config + ICH9_LPC_RCBA);
|
2012-11-14 21:54:05 +01:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
pci_set_byte(d->config + ICH9_LPC_PIRQA_ROUT + i,
|
|
|
|
ICH9_LPC_PIRQ_ROUT_DEFAULT);
|
|
|
|
}
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
pci_set_byte(d->config + ICH9_LPC_PIRQE_ROUT + i,
|
|
|
|
ICH9_LPC_PIRQ_ROUT_DEFAULT);
|
|
|
|
}
|
|
|
|
pci_set_byte(d->config + ICH9_LPC_ACPI_CTRL, ICH9_LPC_ACPI_CTRL_DEFAULT);
|
|
|
|
|
|
|
|
pci_set_long(d->config + ICH9_LPC_PMBASE, ICH9_LPC_PMBASE_DEFAULT);
|
|
|
|
pci_set_long(d->config + ICH9_LPC_RCBA, ICH9_LPC_RCBA_DEFAULT);
|
|
|
|
|
|
|
|
ich9_cc_reset(lpc);
|
|
|
|
|
2016-06-23 07:54:22 +02:00
|
|
|
ich9_lpc_pmbase_sci_update(lpc);
|
2016-03-07 13:38:58 +01:00
|
|
|
ich9_lpc_rcba_update(lpc, rcba_old);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
lpc->sci_level = 0;
|
2013-02-20 02:51:24 +01:00
|
|
|
lpc->rst_cnt = 0;
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
|
|
|
|
memset(lpc->smi_guest_features_le, 0, sizeof lpc->smi_guest_features_le);
|
|
|
|
lpc->smi_features_ok = 0;
|
|
|
|
lpc->smi_negotiated_features = 0;
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
2016-03-07 13:38:58 +01:00
|
|
|
/* root complex register block is mapped into memory space */
|
|
|
|
static const MemoryRegionOps rcrb_mmio_ops = {
|
2012-11-14 21:54:05 +01:00
|
|
|
.read = ich9_cc_read,
|
|
|
|
.write = ich9_cc_write,
|
|
|
|
.endianness = DEVICE_LITTLE_ENDIAN,
|
|
|
|
};
|
|
|
|
|
2012-11-23 15:02:18 +01:00
|
|
|
static void ich9_lpc_machine_ready(Notifier *n, void *opaque)
|
|
|
|
{
|
|
|
|
ICH9LPCState *s = container_of(n, ICH9LPCState, machine_ready);
|
2013-06-22 08:07:01 +02:00
|
|
|
MemoryRegion *io_as = pci_address_space_io(&s->d);
|
2012-11-23 15:02:18 +01:00
|
|
|
uint8_t *pci_conf;
|
|
|
|
|
|
|
|
pci_conf = s->d.config;
|
2013-07-02 13:40:48 +02:00
|
|
|
if (memory_region_present(io_as, 0x3f8)) {
|
2012-11-23 15:02:18 +01:00
|
|
|
/* com1 */
|
|
|
|
pci_conf[0x82] |= 0x01;
|
|
|
|
}
|
2013-07-02 13:40:48 +02:00
|
|
|
if (memory_region_present(io_as, 0x2f8)) {
|
2012-11-23 15:02:18 +01:00
|
|
|
/* com2 */
|
|
|
|
pci_conf[0x82] |= 0x02;
|
|
|
|
}
|
2013-07-02 13:40:48 +02:00
|
|
|
if (memory_region_present(io_as, 0x378)) {
|
2012-11-23 15:02:18 +01:00
|
|
|
/* lpt */
|
|
|
|
pci_conf[0x82] |= 0x04;
|
|
|
|
}
|
2015-06-01 16:09:12 +02:00
|
|
|
if (memory_region_present(io_as, 0x3f2)) {
|
2012-11-23 15:02:18 +01:00
|
|
|
/* floppy */
|
|
|
|
pci_conf[0x82] |= 0x08;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-02-20 02:51:24 +01:00
|
|
|
/* reset control */
|
|
|
|
static void ich9_rst_cnt_write(void *opaque, hwaddr addr, uint64_t val,
|
|
|
|
unsigned len)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
|
|
|
|
if (val & 4) {
|
2017-05-15 23:41:13 +02:00
|
|
|
qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
|
2013-02-20 02:51:24 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
lpc->rst_cnt = val & 0xA; /* keep FULL_RST (bit 3) and SYS_RST (bit 1) */
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t ich9_rst_cnt_read(void *opaque, hwaddr addr, unsigned len)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
|
|
|
|
return lpc->rst_cnt;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const MemoryRegionOps ich9_rst_cnt_ops = {
|
|
|
|
.read = ich9_rst_cnt_read,
|
|
|
|
.write = ich9_rst_cnt_write,
|
|
|
|
.endianness = DEVICE_LITTLE_ENDIAN
|
|
|
|
};
|
|
|
|
|
2020-02-04 14:16:00 +01:00
|
|
|
static void ich9_lpc_initfn(Object *obj)
|
2013-07-24 17:56:10 +02:00
|
|
|
{
|
2020-02-04 14:16:00 +01:00
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(obj);
|
|
|
|
|
2013-07-24 17:56:10 +02:00
|
|
|
static const uint8_t acpi_enable_cmd = ICH9_APM_ACPI_ENABLE;
|
|
|
|
static const uint8_t acpi_disable_cmd = ICH9_APM_ACPI_DISABLE;
|
|
|
|
|
2020-02-04 14:16:01 +01:00
|
|
|
object_property_add_uint8_ptr(obj, 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 17:29:22 +02:00
|
|
|
&lpc->sci_gsi, OBJ_PROP_FLAG_READ);
|
2013-07-24 17:56:10 +02:00
|
|
|
object_property_add_uint8_ptr(OBJECT(lpc), 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 17:29:22 +02:00
|
|
|
&acpi_enable_cmd, OBJ_PROP_FLAG_READ);
|
2013-07-24 17:56:10 +02:00
|
|
|
object_property_add_uint8_ptr(OBJECT(lpc), 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 17:29:22 +02:00
|
|
|
&acpi_disable_cmd, OBJ_PROP_FLAG_READ);
|
2020-09-23 11:46:45 +02:00
|
|
|
object_property_add_uint64_ptr(obj, ICH9_LPC_SMI_NEGOTIATED_FEAT_PROP,
|
|
|
|
&lpc->smi_negotiated_features,
|
|
|
|
OBJ_PROP_FLAG_READ);
|
2013-07-24 17:56:10 +02:00
|
|
|
|
2020-05-05 17:29:23 +02:00
|
|
|
ich9_pm_add_properties(obj, &lpc->pm);
|
2014-06-02 15:25:21 +02:00
|
|
|
}
|
|
|
|
|
2015-12-17 17:35:17 +01:00
|
|
|
static void ich9_lpc_realize(PCIDevice *d, Error **errp)
|
2012-11-14 21:54:05 +01:00
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
|
2016-06-22 14:24:54 +02:00
|
|
|
DeviceState *dev = DEVICE(d);
|
2012-11-14 21:54:05 +01:00
|
|
|
ISABus *isa_bus;
|
|
|
|
|
isa: Clean up error handling around isa_bus_new()
We can have at most one ISA bus. If you try to create another one,
isa_bus_new() complains to stderr and returns null.
isa_bus_new() is called in two contexts, machine's init() and device's
realize() methods. Since complaining to stderr is not proper in the
latter context, convert isa_bus_new() to Error.
Machine's init():
* mips_jazz_init(), called from the init() methods of machines
"magnum" and "pica"
* mips_r4k_init(), the init() method of machine "mips"
* pc_init1() called from the init() methods of non-q35 PC machines
* typhoon_init(), called from clipper_init(), the init() method of
machine "clipper"
These callers always create the first ISA bus, hence isa_bus_new()
can't fail. Simply pass &error_abort.
Device's realize():
* i82378_realize(), of PCI device "i82378"
* ich9_lpc_realize(), of PCI device "ICH9-LPC"
* pci_ebus_realize(), of PCI device "ebus"
* piix3_realize(), of PCI device "pci-piix3", abstract parent of
"PIIX3" and "PIIX3-xen"
* piix4_realize(), of PCI device "PIIX4"
* vt82c686b_realize(), of PCI device "VT82C686B"
Propagate the error. Note that these devices are typically created
only by machine init() methods with qdev_init_nofail() or similar. If
we screwed up and created an ISA bus before that call, we now give up
right away. Before, we'd hobble on, and typically die in
isa_bus_irqs(). Similar if someone finds a way to hot-plug one of
these critters.
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <1450370121-5768-11-git-send-email-armbru@redhat.com>
2015-12-17 17:35:18 +01:00
|
|
|
isa_bus = isa_bus_new(DEVICE(d), get_system_memory(), get_system_io(),
|
|
|
|
errp);
|
|
|
|
if (!isa_bus) {
|
|
|
|
return;
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
pci_set_long(d->wmask + ICH9_LPC_PMBASE,
|
|
|
|
ICH9_LPC_PMBASE_BASE_ADDRESS_MASK);
|
2016-06-23 07:49:16 +02:00
|
|
|
pci_set_byte(d->wmask + ICH9_LPC_PMBASE,
|
2016-06-23 07:54:22 +02:00
|
|
|
ICH9_LPC_ACPI_CTRL_ACPI_EN |
|
|
|
|
ICH9_LPC_ACPI_CTRL_SCI_IRQ_SEL_MASK);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
2016-03-07 13:38:58 +01:00
|
|
|
memory_region_init_io(&lpc->rcrb_mem, OBJECT(d), &rcrb_mmio_ops, lpc,
|
|
|
|
"lpc-rcrb-mmio", ICH9_CC_SIZE);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
|
|
|
lpc->isa_bus = isa_bus;
|
|
|
|
|
|
|
|
ich9_cc_init(lpc);
|
2012-09-19 13:50:03 +02:00
|
|
|
apm_init(d, &lpc->apm, ich9_apm_ctrl_changed, lpc);
|
2012-11-23 15:02:18 +01:00
|
|
|
|
|
|
|
lpc->machine_ready.notify = ich9_lpc_machine_ready;
|
|
|
|
qemu_add_machine_init_done_notifier(&lpc->machine_ready);
|
|
|
|
|
2013-06-07 03:25:08 +02:00
|
|
|
memory_region_init_io(&lpc->rst_cnt_mem, OBJECT(d), &ich9_rst_cnt_ops, lpc,
|
2013-02-20 02:51:24 +01:00
|
|
|
"lpc-reset-control", 1);
|
|
|
|
memory_region_add_subregion_overlap(pci_address_space_io(d),
|
|
|
|
ICH9_RST_CNT_IOPORT, &lpc->rst_cnt_mem,
|
|
|
|
1);
|
2016-06-22 14:24:54 +02:00
|
|
|
|
|
|
|
qdev_init_gpio_out_named(dev, lpc->gsi, ICH9_GPIO_GSI, GSI_NUM_PINS);
|
2016-06-22 14:24:55 +02:00
|
|
|
|
|
|
|
isa_bus_irqs(isa_bus, lpc->gsi);
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
2013-02-20 02:51:24 +01:00
|
|
|
static bool ich9_rst_cnt_needed(void *opaque)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
|
|
|
|
return (lpc->rst_cnt != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_ich9_rst_cnt = {
|
|
|
|
.name = "ICH9LPC/rst_cnt",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
2014-09-23 14:09:54 +02:00
|
|
|
.needed = ich9_rst_cnt_needed,
|
2013-02-20 02:51:24 +01:00
|
|
|
.fields = (VMStateField[]) {
|
|
|
|
VMSTATE_UINT8(rst_cnt, ICH9LPCState),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
static bool ich9_smi_feat_needed(void *opaque)
|
|
|
|
{
|
|
|
|
ICH9LPCState *lpc = opaque;
|
|
|
|
|
|
|
|
return !buffer_is_zero(lpc->smi_guest_features_le,
|
|
|
|
sizeof lpc->smi_guest_features_le) ||
|
|
|
|
lpc->smi_features_ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_ich9_smi_feat = {
|
|
|
|
.name = "ICH9LPC/smi_feat",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = ich9_smi_feat_needed,
|
|
|
|
.fields = (VMStateField[]) {
|
|
|
|
VMSTATE_UINT8_ARRAY(smi_guest_features_le, ICH9LPCState,
|
|
|
|
sizeof(uint64_t)),
|
|
|
|
VMSTATE_UINT8(smi_features_ok, ICH9LPCState),
|
|
|
|
VMSTATE_UINT64(smi_negotiated_features, ICH9LPCState),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2012-11-14 21:54:05 +01:00
|
|
|
static const VMStateDescription vmstate_ich9_lpc = {
|
|
|
|
.name = "ICH9LPC",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.post_load = ich9_lpc_post_load,
|
|
|
|
.fields = (VMStateField[]) {
|
|
|
|
VMSTATE_PCI_DEVICE(d, ICH9LPCState),
|
|
|
|
VMSTATE_STRUCT(apm, ICH9LPCState, 0, vmstate_apm, APMState),
|
|
|
|
VMSTATE_STRUCT(pm, ICH9LPCState, 0, vmstate_ich9_pm, ICH9LPCPMRegs),
|
|
|
|
VMSTATE_UINT8_ARRAY(chip_config, ICH9LPCState, ICH9_CC_SIZE),
|
|
|
|
VMSTATE_UINT32(sci_level, ICH9LPCState),
|
|
|
|
VMSTATE_END_OF_LIST()
|
2013-02-20 02:51:24 +01:00
|
|
|
},
|
2014-09-23 14:09:54 +02:00
|
|
|
.subsections = (const VMStateDescription*[]) {
|
|
|
|
&vmstate_ich9_rst_cnt,
|
hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
Introduce the following fw_cfg files:
- "etc/smi/supported-features": a little endian uint64_t feature bitmap,
presenting the features known by the host to the guest. Read-only for
the guest.
The content of this file will be determined via bit-granularity ICH9-LPC
device properties, to be introduced later. For now, the bitmask is left
zeroed. The bits will be set from machine type compat properties and on
the QEMU command line, hence this file is not migrated.
- "etc/smi/requested-features": a little endian uint64_t feature bitmap,
representing the features the guest would like to request. Read-write
for the guest.
The guest can freely (re)write this file, it has no direct consequence.
Initial value is zero. A nonzero value causes the SMI-related fw_cfg
files and fields that are under guest influence to be migrated.
- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
the guest. When the guest selects the associated fw_cfg key, the guest
features are validated against the host features. In case of error, the
negotiation doesn't proceed, and the "features-ok" file remains zero. In
case of success, the "features-ok" file becomes (uint8_t)1, and the
negotiated features are locked down internally (to which no further
changes are possible until reset).
The initial value is zero. A nonzero value causes the SMI-related
fw_cfg files and fields that are under guest influence to be migrated.
The C-language fields backing the "supported-features" and
"requested-features" files are uint8_t arrays. This is because they carry
guest-side representation (our choice is little endian), while
VMSTATE_UINT64() assumes / implies host-side endianness for any uint64_t
fields. If we migrate a guest between hosts with different endiannesses
(which is possible with TCG), then the host-side value is preserved, and
the host-side representation is translated. This would be visible to the
guest through fw_cfg, unless we used plain byte arrays. So we do.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20170126014416.11211-2-lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-26 02:44:14 +01:00
|
|
|
&vmstate_ich9_smi_feat,
|
2014-09-23 14:09:54 +02:00
|
|
|
NULL
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-06-28 19:58:58 +02:00
|
|
|
static Property ich9_lpc_properties[] = {
|
|
|
|
DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
|
2021-02-18 06:51:11 +01:00
|
|
|
DEFINE_PROP_BOOL("smm-compat", ICH9LPCState, pm.smm_compat, false),
|
2017-01-26 02:44:16 +01:00
|
|
|
DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
|
|
|
|
ICH9_LPC_SMI_F_BROADCAST_BIT, true),
|
2020-09-23 11:46:40 +02:00
|
|
|
DEFINE_PROP_BIT64("x-smi-cpu-hotplug", ICH9LPCState, smi_host_features,
|
|
|
|
ICH9_LPC_SMI_F_CPU_HOTPLUG_BIT, true),
|
|
|
|
DEFINE_PROP_BIT64("x-smi-cpu-hotunplug", ICH9LPCState, smi_host_features,
|
2020-12-07 15:07:39 +01:00
|
|
|
ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT, true),
|
2015-06-28 19:58:58 +02:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
2016-05-31 11:57:57 +02:00
|
|
|
static void ich9_send_gpe(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
|
|
|
|
{
|
|
|
|
ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
|
|
|
|
|
|
|
|
acpi_send_gpe_event(&s->pm.acpi_regs, s->pm.irq, ev);
|
|
|
|
}
|
|
|
|
|
2012-11-14 21:54:05 +01:00
|
|
|
static void ich9_lpc_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
2014-06-02 15:25:22 +02:00
|
|
|
HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
|
2014-06-16 19:12:27 +02:00
|
|
|
AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_CLASS(klass);
|
2012-11-14 21:54:05 +01:00
|
|
|
|
2013-07-29 16:17:45 +02:00
|
|
|
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
|
2012-11-14 21:54:05 +01:00
|
|
|
dc->reset = ich9_lpc_reset;
|
2015-12-17 17:35:17 +01:00
|
|
|
k->realize = ich9_lpc_realize;
|
2012-11-14 21:54:05 +01:00
|
|
|
dc->vmsd = &vmstate_ich9_lpc;
|
2020-01-10 16:30:32 +01:00
|
|
|
device_class_set_props(dc, ich9_lpc_properties);
|
2012-11-14 21:54:05 +01:00
|
|
|
k->config_write = ich9_lpc_config_write;
|
|
|
|
dc->desc = "ICH9 LPC bridge";
|
|
|
|
k->vendor_id = PCI_VENDOR_ID_INTEL;
|
|
|
|
k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
|
|
|
|
k->revision = ICH9_A2_LPC_REVISION;
|
|
|
|
k->class_id = PCI_CLASS_BRIDGE_ISA;
|
2013-11-28 17:26:59 +01:00
|
|
|
/*
|
|
|
|
* Reason: part of ICH9 southbridge, needs to be wired up by
|
|
|
|
* pc_q35_init()
|
|
|
|
*/
|
2017-05-03 22:35:44 +02:00
|
|
|
dc->user_creatable = false;
|
2019-03-01 04:35:48 +01:00
|
|
|
hc->pre_plug = ich9_pm_device_pre_plug_cb;
|
2016-05-31 12:01:17 +02:00
|
|
|
hc->plug = ich9_pm_device_plug_cb;
|
|
|
|
hc->unplug_request = ich9_pm_device_unplug_request_cb;
|
|
|
|
hc->unplug = ich9_pm_device_unplug_cb;
|
2014-06-16 19:12:27 +02:00
|
|
|
adevc->ospm_status = ich9_pm_ospm_status;
|
2016-05-31 11:57:57 +02:00
|
|
|
adevc->send_event = ich9_send_gpe;
|
2016-04-20 11:28:57 +02:00
|
|
|
adevc->madt_cpu = pc_madt_cpu_entry;
|
2012-11-14 21:54:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo ich9_lpc_info = {
|
|
|
|
.name = TYPE_ICH9_LPC_DEVICE,
|
|
|
|
.parent = TYPE_PCI_DEVICE,
|
2020-08-24 23:59:33 +02:00
|
|
|
.instance_size = sizeof(ICH9LPCState),
|
2014-06-02 15:25:21 +02:00
|
|
|
.instance_init = ich9_lpc_initfn,
|
2012-11-14 21:54:05 +01:00
|
|
|
.class_init = ich9_lpc_class_init,
|
2014-06-02 15:25:22 +02:00
|
|
|
.interfaces = (InterfaceInfo[]) {
|
|
|
|
{ TYPE_HOTPLUG_HANDLER },
|
2014-06-16 19:12:27 +02:00
|
|
|
{ TYPE_ACPI_DEVICE_IF },
|
2017-09-27 21:56:34 +02:00
|
|
|
{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
|
2014-06-02 15:25:22 +02:00
|
|
|
{ }
|
|
|
|
}
|
2012-11-14 21:54:05 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static void ich9_lpc_register(void)
|
|
|
|
{
|
|
|
|
type_register_static(&ich9_lpc_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(ich9_lpc_register);
|