2010-05-14 09:29:02 +02:00
|
|
|
/*
|
|
|
|
* 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 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/>
|
2012-01-13 17:44:23 +01:00
|
|
|
*
|
|
|
|
* Contributions after 2012-01-13 are licensed under the terms of the
|
|
|
|
* GNU GPL, version 2 or (at your option) any later version.
|
2010-05-14 09:29:02 +02:00
|
|
|
*/
|
|
|
|
#include "hw.h"
|
|
|
|
#include "pc.h"
|
|
|
|
#include "apm.h"
|
|
|
|
#include "pm_smbus.h"
|
|
|
|
#include "pci.h"
|
|
|
|
#include "acpi.h"
|
2010-06-02 18:48:27 +02:00
|
|
|
#include "sysemu.h"
|
2010-09-18 07:53:14 +02:00
|
|
|
#include "range.h"
|
2011-07-15 17:10:15 +02:00
|
|
|
#include "ioport.h"
|
2012-06-04 13:31:55 +02:00
|
|
|
#include "fw_cfg.h"
|
2010-05-14 09:29:02 +02:00
|
|
|
|
|
|
|
//#define DEBUG
|
|
|
|
|
2010-05-14 09:29:22 +02:00
|
|
|
#ifdef DEBUG
|
|
|
|
# define PIIX4_DPRINTF(format, ...) printf(format, ## __VA_ARGS__)
|
|
|
|
#else
|
|
|
|
# define PIIX4_DPRINTF(format, ...) do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
#define ACPI_DBG_IO_ADDR 0xb044
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
#define GPE_BASE 0xafe0
|
2011-03-25 11:54:41 +01:00
|
|
|
#define GPE_LEN 4
|
2012-04-05 19:07:08 +02:00
|
|
|
#define PCI_UP_BASE 0xae00
|
|
|
|
#define PCI_DOWN_BASE 0xae04
|
2010-05-14 09:29:20 +02:00
|
|
|
#define PCI_EJ_BASE 0xae08
|
2011-01-11 17:20:39 +01:00
|
|
|
#define PCI_RMV_BASE 0xae0c
|
2010-05-14 09:29:20 +02:00
|
|
|
|
2010-10-17 11:45:24 +02:00
|
|
|
#define PIIX4_PCI_HOTPLUG_STATUS 2
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
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 19:07:15 +02:00
|
|
|
uint32_t up; /* deprecated, maintained for migration compatibility */
|
2010-05-14 09:29:20 +02:00
|
|
|
uint32_t down;
|
|
|
|
};
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
typedef struct PIIX4PMState {
|
|
|
|
PCIDevice dev;
|
2010-11-17 10:50:10 +01:00
|
|
|
IORange ioport;
|
2012-02-23 13:45:16 +01:00
|
|
|
ACPIREGS ar;
|
2010-05-14 09:29:02 +02:00
|
|
|
|
|
|
|
APMState apm;
|
|
|
|
|
|
|
|
PMSMBus smb;
|
2010-05-14 09:29:18 +02:00
|
|
|
uint32_t smb_io_base;
|
2010-05-14 09:29:02 +02:00
|
|
|
|
|
|
|
qemu_irq irq;
|
|
|
|
qemu_irq smi_irq;
|
|
|
|
int kvm_enabled;
|
2011-07-15 17:10:15 +02:00
|
|
|
Notifier machine_ready;
|
2010-05-14 09:29:20 +02:00
|
|
|
|
|
|
|
/* for pci hotplug */
|
|
|
|
struct pci_status pci0_status;
|
2011-01-11 17:20:39 +01:00
|
|
|
uint32_t pci0_hotplug_enable;
|
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 19:07:15 +02:00
|
|
|
uint32_t pci0_slot_device_present;
|
2012-06-04 13:31:55 +02:00
|
|
|
|
|
|
|
uint8_t disable_s3;
|
|
|
|
uint8_t disable_s4;
|
|
|
|
uint8_t s4_val;
|
2010-05-14 09:29:02 +02:00
|
|
|
} PIIX4PMState;
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s);
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
#define ACPI_ENABLE 0xf1
|
|
|
|
#define ACPI_DISABLE 0xf0
|
|
|
|
|
|
|
|
static void pm_update_sci(PIIX4PMState *s)
|
|
|
|
{
|
|
|
|
int sci_level, pmsts;
|
|
|
|
|
2012-02-23 13:45:17 +01:00
|
|
|
pmsts = acpi_pm1_evt_get_sts(&s->ar);
|
2012-02-23 13:45:16 +01:00
|
|
|
sci_level = (((pmsts & s->ar.pm1.evt.en) &
|
2010-05-14 09:29:02 +02:00
|
|
|
(ACPI_BITMASK_RT_CLOCK_ENABLE |
|
|
|
|
ACPI_BITMASK_POWER_BUTTON_ENABLE |
|
|
|
|
ACPI_BITMASK_GLOBAL_LOCK_ENABLE |
|
2010-10-17 11:45:25 +02:00
|
|
|
ACPI_BITMASK_TIMER_ENABLE)) != 0) ||
|
2012-02-23 13:45:16 +01:00
|
|
|
(((s->ar.gpe.sts[0] & s->ar.gpe.en[0])
|
|
|
|
& PIIX4_PCI_HOTPLUG_STATUS) != 0);
|
2010-10-17 11:45:25 +02:00
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
qemu_set_irq(s->irq, sci_level);
|
|
|
|
/* schedule a timer interruption if needed */
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_pm_tmr_update(&s->ar, (s->ar.pm1.evt.en & ACPI_BITMASK_TIMER_ENABLE) &&
|
2011-03-25 11:54:38 +01:00
|
|
|
!(pmsts & ACPI_BITMASK_TIMER_STATUS));
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2012-02-23 13:45:16 +01:00
|
|
|
static void pm_tmr_timer(ACPIREGS *ar)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-02-23 13:45:16 +01:00
|
|
|
PIIX4PMState *s = container_of(ar, PIIX4PMState, ar);
|
2010-05-14 09:29:02 +02:00
|
|
|
pm_update_sci(s);
|
|
|
|
}
|
|
|
|
|
2010-11-17 10:50:10 +01:00
|
|
|
static void pm_ioport_write(IORange *ioport, uint64_t addr, unsigned width,
|
|
|
|
uint64_t val)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2010-11-17 10:50:10 +01:00
|
|
|
PIIX4PMState *s = container_of(ioport, PIIX4PMState, ioport);
|
|
|
|
|
|
|
|
if (width != 2) {
|
|
|
|
PIIX4_DPRINTF("PM write port=0x%04x width=%d val=0x%08x\n",
|
|
|
|
(unsigned)addr, width, (unsigned)val);
|
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
switch(addr) {
|
|
|
|
case 0x00:
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_pm1_evt_write_sts(&s->ar, val);
|
2011-03-25 11:54:39 +01:00
|
|
|
pm_update_sci(s);
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
case 0x02:
|
2012-02-23 13:45:18 +01:00
|
|
|
acpi_pm1_evt_write_en(&s->ar, val);
|
2010-05-14 09:29:02 +02:00
|
|
|
pm_update_sci(s);
|
|
|
|
break;
|
|
|
|
case 0x04:
|
2012-06-04 13:31:55 +02:00
|
|
|
acpi_pm1_cnt_write(&s->ar, val, s->s4_val);
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2011-02-28 03:22:33 +01:00
|
|
|
PIIX4_DPRINTF("PM writew port=0x%04x val=0x%04x\n", (unsigned int)addr,
|
|
|
|
(unsigned int)val);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2010-11-17 10:50:10 +01:00
|
|
|
static void pm_ioport_read(IORange *ioport, uint64_t addr, unsigned width,
|
|
|
|
uint64_t *data)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2010-11-17 10:50:10 +01:00
|
|
|
PIIX4PMState *s = container_of(ioport, PIIX4PMState, ioport);
|
2010-05-14 09:29:02 +02:00
|
|
|
uint32_t val;
|
|
|
|
|
|
|
|
switch(addr) {
|
|
|
|
case 0x00:
|
2012-02-23 13:45:17 +01:00
|
|
|
val = acpi_pm1_evt_get_sts(&s->ar);
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
case 0x02:
|
2012-02-23 13:45:16 +01:00
|
|
|
val = s->ar.pm1.evt.en;
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
case 0x04:
|
2012-02-23 13:45:16 +01:00
|
|
|
val = s->ar.pm1.cnt.cnt;
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
case 0x08:
|
2012-02-23 13:45:16 +01:00
|
|
|
val = acpi_pm_tmr_get(&s->ar);
|
2010-05-14 09:29:02 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
val = 0;
|
|
|
|
break;
|
|
|
|
}
|
2011-02-28 03:22:33 +01:00
|
|
|
PIIX4_DPRINTF("PM readw port=0x%04x val=0x%04x\n", (unsigned int)addr, val);
|
2010-11-17 10:50:10 +01:00
|
|
|
*data = val;
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2010-11-17 10:50:10 +01:00
|
|
|
static const IORangeOps pm_iorange_ops = {
|
|
|
|
.read = pm_ioport_read,
|
|
|
|
.write = pm_ioport_write,
|
|
|
|
};
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
static void apm_ctrl_changed(uint32_t val, void *arg)
|
|
|
|
{
|
|
|
|
PIIX4PMState *s = arg;
|
|
|
|
|
|
|
|
/* ACPI specs 3.0, 4.7.2.5 */
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_pm1_cnt_update(&s->ar, val == ACPI_ENABLE, val == ACPI_DISABLE);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
|
|
|
if (s->dev.config[0x5b] & (1 << 1)) {
|
|
|
|
if (s->smi_irq) {
|
|
|
|
qemu_irq_raise(s->smi_irq);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_dbg_writel(void *opaque, uint32_t addr, uint32_t val)
|
|
|
|
{
|
2010-05-14 09:29:22 +02:00
|
|
|
PIIX4_DPRINTF("ACPI: DBG: 0x%08x\n", val);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void pm_io_space_update(PIIX4PMState *s)
|
|
|
|
{
|
|
|
|
uint32_t pm_io_base;
|
|
|
|
|
|
|
|
if (s->dev.config[0x80] & 1) {
|
|
|
|
pm_io_base = le32_to_cpu(*(uint32_t *)(s->dev.config + 0x40));
|
|
|
|
pm_io_base &= 0xffc0;
|
|
|
|
|
|
|
|
/* XXX: need to improve memory and ioport allocation */
|
2010-05-14 09:29:22 +02:00
|
|
|
PIIX4_DPRINTF("PM: mapping to 0x%x\n", pm_io_base);
|
2010-11-17 10:50:10 +01:00
|
|
|
iorange_init(&s->ioport, &pm_iorange_ops, pm_io_base, 64);
|
|
|
|
ioport_register(&s->ioport);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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))
|
|
|
|
pm_io_space_update((PIIX4PMState *)d);
|
|
|
|
}
|
|
|
|
|
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 19:07:15 +02:00
|
|
|
static void vmstate_pci_status_pre_save(void *opaque)
|
|
|
|
{
|
|
|
|
struct pci_status *pci0_status = opaque;
|
|
|
|
PIIX4PMState *s = container_of(pci0_status, PIIX4PMState, pci0_status);
|
|
|
|
|
|
|
|
/* We no longer track up, so build a safe value for migrating
|
|
|
|
* to a version that still does... of course these might get lost
|
|
|
|
* by an old buggy implementation, but we try. */
|
|
|
|
pci0_status->up = s->pci0_slot_device_present & s->pci0_hotplug_enable;
|
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
static int vmstate_acpi_post_load(void *opaque, int version_id)
|
|
|
|
{
|
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
|
|
|
|
pm_io_space_update(s);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-03-25 11:54:41 +01:00
|
|
|
#define VMSTATE_GPE_ARRAY(_field, _state) \
|
|
|
|
{ \
|
|
|
|
.name = (stringify(_field)), \
|
|
|
|
.version_id = 0, \
|
|
|
|
.num = GPE_LEN, \
|
|
|
|
.info = &vmstate_info_uint16, \
|
|
|
|
.size = sizeof(uint16_t), \
|
|
|
|
.flags = VMS_ARRAY | VMS_POINTER, \
|
|
|
|
.offset = vmstate_offset_pointer(_state, _field, uint8_t), \
|
|
|
|
}
|
|
|
|
|
2010-06-02 18:58:29 +02:00
|
|
|
static const VMStateDescription vmstate_gpe = {
|
|
|
|
.name = "gpe",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.minimum_version_id_old = 1,
|
|
|
|
.fields = (VMStateField []) {
|
2011-03-25 11:54:41 +01:00
|
|
|
VMSTATE_GPE_ARRAY(sts, ACPIGPE),
|
|
|
|
VMSTATE_GPE_ARRAY(en, ACPIGPE),
|
2010-06-02 18:58:29 +02:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_pci_status = {
|
|
|
|
.name = "pci_status",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.minimum_version_id_old = 1,
|
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 19:07:15 +02:00
|
|
|
.pre_save = vmstate_pci_status_pre_save,
|
2010-06-02 18:58:29 +02:00
|
|
|
.fields = (VMStateField []) {
|
|
|
|
VMSTATE_UINT32(up, struct pci_status),
|
|
|
|
VMSTATE_UINT32(down, struct pci_status),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
static const VMStateDescription vmstate_acpi = {
|
|
|
|
.name = "piix4_pm",
|
2010-06-02 18:58:29 +02:00
|
|
|
.version_id = 2,
|
2010-05-14 09:29:02 +02:00
|
|
|
.minimum_version_id = 1,
|
|
|
|
.minimum_version_id_old = 1,
|
|
|
|
.post_load = vmstate_acpi_post_load,
|
|
|
|
.fields = (VMStateField []) {
|
|
|
|
VMSTATE_PCI_DEVICE(dev, PIIX4PMState),
|
2012-02-23 13:45:16 +01:00
|
|
|
VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState),
|
|
|
|
VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState),
|
|
|
|
VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState),
|
2010-05-14 09:29:02 +02:00
|
|
|
VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState),
|
2012-02-23 13:45:16 +01:00
|
|
|
VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState),
|
|
|
|
VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState),
|
|
|
|
VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE),
|
2010-06-02 18:58:29 +02:00
|
|
|
VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2, vmstate_pci_status,
|
|
|
|
struct pci_status),
|
2010-05-14 09:29:02 +02:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
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 19:07:15 +02:00
|
|
|
static void acpi_piix_eject_slot(PIIX4PMState *s, unsigned slots)
|
|
|
|
{
|
2011-12-23 22:34:39 +01:00
|
|
|
BusChild *kid, *next;
|
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 19:07:15 +02:00
|
|
|
BusState *bus = qdev_get_parent_bus(&s->dev.qdev);
|
|
|
|
int slot = ffs(slots) - 1;
|
2012-04-15 11:00:52 +02:00
|
|
|
bool slot_free = true;
|
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 19:07:15 +02:00
|
|
|
|
|
|
|
/* Mark request as complete */
|
|
|
|
s->pci0_status.down &= ~(1U << slot);
|
|
|
|
|
2011-12-23 22:34:39 +01:00
|
|
|
QTAILQ_FOREACH_SAFE(kid, &bus->children, sibling, next) {
|
|
|
|
DeviceState *qdev = kid->child;
|
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 19:07:15 +02:00
|
|
|
PCIDevice *dev = PCI_DEVICE(qdev);
|
|
|
|
PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
|
2012-04-15 11:00:52 +02:00
|
|
|
if (PCI_SLOT(dev->devfn) == slot) {
|
|
|
|
if (pc->no_hotplug) {
|
|
|
|
slot_free = false;
|
|
|
|
} else {
|
2012-05-20 11:57:45 +02:00
|
|
|
object_unparent(OBJECT(dev));
|
2012-04-15 11:00:52 +02:00
|
|
|
qdev_free(qdev);
|
|
|
|
}
|
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 19:07:15 +02:00
|
|
|
}
|
|
|
|
}
|
2012-04-15 11:00:52 +02:00
|
|
|
if (slot_free) {
|
|
|
|
s->pci0_slot_device_present &= ~(1U << slot);
|
|
|
|
}
|
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 19:07:15 +02:00
|
|
|
}
|
|
|
|
|
2011-01-11 17:20:39 +01:00
|
|
|
static void piix4_update_hotplug(PIIX4PMState *s)
|
|
|
|
{
|
|
|
|
PCIDevice *dev = &s->dev;
|
|
|
|
BusState *bus = qdev_get_parent_bus(&dev->qdev);
|
2011-12-23 22:34:39 +01:00
|
|
|
BusChild *kid, *next;
|
2011-01-11 17:20:39 +01:00
|
|
|
|
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 19:07:15 +02:00
|
|
|
/* Execute any pending removes during reset */
|
|
|
|
while (s->pci0_status.down) {
|
|
|
|
acpi_piix_eject_slot(s, s->pci0_status.down);
|
|
|
|
}
|
|
|
|
|
2011-01-11 17:20:39 +01:00
|
|
|
s->pci0_hotplug_enable = ~0;
|
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 19:07:15 +02:00
|
|
|
s->pci0_slot_device_present = 0;
|
2011-01-11 17:20:39 +01:00
|
|
|
|
2011-12-23 22:34:39 +01:00
|
|
|
QTAILQ_FOREACH_SAFE(kid, &bus->children, sibling, next) {
|
|
|
|
DeviceState *qdev = kid->child;
|
2011-12-04 19:22:06 +01:00
|
|
|
PCIDevice *pdev = PCI_DEVICE(qdev);
|
|
|
|
PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pdev);
|
2011-01-11 17:20:39 +01:00
|
|
|
int slot = PCI_SLOT(pdev->devfn);
|
|
|
|
|
2011-12-04 19:22:06 +01:00
|
|
|
if (pc->no_hotplug) {
|
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 19:07:15 +02:00
|
|
|
s->pci0_hotplug_enable &= ~(1U << slot);
|
2011-01-11 17:20:39 +01:00
|
|
|
}
|
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 19:07:15 +02:00
|
|
|
|
|
|
|
s->pci0_slot_device_present |= (1U << slot);
|
2011-01-11 17:20:39 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
static void piix4_reset(void *opaque)
|
|
|
|
{
|
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
uint8_t *pci_conf = s->dev.config;
|
|
|
|
|
|
|
|
pci_conf[0x58] = 0;
|
|
|
|
pci_conf[0x59] = 0;
|
|
|
|
pci_conf[0x5a] = 0;
|
|
|
|
pci_conf[0x5b] = 0;
|
|
|
|
|
|
|
|
if (s->kvm_enabled) {
|
|
|
|
/* Mark SMM as already inited (until KVM supports SMM). */
|
|
|
|
pci_conf[0x5B] = 0x02;
|
|
|
|
}
|
2011-01-11 17:20:39 +01:00
|
|
|
piix4_update_hotplug(s);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void piix4_powerdown(void *opaque, int irq, int power_failing)
|
|
|
|
{
|
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
|
2012-02-23 13:45:16 +01:00
|
|
|
assert(s != NULL);
|
|
|
|
acpi_pm1_evt_power_down(&s->ar);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2011-06-20 14:06:26 +02:00
|
|
|
static void piix4_pm_machine_ready(Notifier *n, void *opaque)
|
2011-07-15 17:10:15 +02:00
|
|
|
{
|
|
|
|
PIIX4PMState *s = container_of(n, PIIX4PMState, machine_ready);
|
|
|
|
uint8_t *pci_conf;
|
|
|
|
|
|
|
|
pci_conf = s->dev.config;
|
|
|
|
pci_conf[0x5f] = (isa_is_ioport_assigned(0x378) ? 0x80 : 0) | 0x10;
|
|
|
|
pci_conf[0x63] = 0x60;
|
|
|
|
pci_conf[0x67] = (isa_is_ioport_assigned(0x3f8) ? 0x08 : 0) |
|
|
|
|
(isa_is_ioport_assigned(0x2f8) ? 0x90 : 0);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:18 +02:00
|
|
|
static int piix4_pm_initfn(PCIDevice *dev)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2010-05-14 09:29:18 +02:00
|
|
|
PIIX4PMState *s = DO_UPCAST(PIIX4PMState, dev, dev);
|
2010-05-14 09:29:02 +02:00
|
|
|
uint8_t *pci_conf;
|
|
|
|
|
|
|
|
pci_conf = s->dev.config;
|
|
|
|
pci_conf[0x06] = 0x80;
|
|
|
|
pci_conf[0x07] = 0x02;
|
|
|
|
pci_conf[0x09] = 0x00;
|
|
|
|
pci_conf[0x3d] = 0x01; // interrupt pin 1
|
|
|
|
|
|
|
|
pci_conf[0x40] = 0x01; /* PM io base read only bit */
|
|
|
|
|
|
|
|
/* APM */
|
|
|
|
apm_init(&s->apm, apm_ctrl_changed, s);
|
|
|
|
|
|
|
|
register_ioport_write(ACPI_DBG_IO_ADDR, 4, 4, acpi_dbg_writel, s);
|
|
|
|
|
|
|
|
if (s->kvm_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 */
|
2010-05-14 09:29:18 +02:00
|
|
|
pci_conf[0x90] = s->smb_io_base | 1;
|
|
|
|
pci_conf[0x91] = s->smb_io_base >> 8;
|
2010-05-14 09:29:02 +02:00
|
|
|
pci_conf[0xd2] = 0x09;
|
2010-05-14 09:29:18 +02:00
|
|
|
register_ioport_write(s->smb_io_base, 64, 1, smb_ioport_writeb, &s->smb);
|
|
|
|
register_ioport_read(s->smb_io_base, 64, 1, smb_ioport_readb, &s->smb);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_pm_tmr_init(&s->ar, pm_tmr_timer);
|
|
|
|
acpi_gpe_init(&s->ar, GPE_LEN);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
|
|
|
qemu_system_powerdown = *qemu_allocate_irqs(piix4_powerdown, s, 1);
|
|
|
|
|
2010-05-14 09:29:18 +02:00
|
|
|
pm_smbus_init(&s->dev.qdev, &s->smb);
|
2011-07-15 17:10:15 +02:00
|
|
|
s->machine_ready.notify = piix4_pm_machine_ready;
|
|
|
|
qemu_add_machine_init_done_notifier(&s->machine_ready);
|
2010-05-14 09:29:18 +02:00
|
|
|
qemu_register_reset(piix4_reset, s);
|
2010-05-14 09:29:20 +02:00
|
|
|
piix4_acpi_system_hot_add_init(dev->bus, s);
|
2010-05-14 09:29:18 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
|
2012-02-23 13:45:20 +01:00
|
|
|
qemu_irq sci_irq, qemu_irq smi_irq,
|
2012-06-04 13:31:55 +02:00
|
|
|
int kvm_enabled, void *fw_cfg)
|
2010-05-14 09:29:18 +02:00
|
|
|
{
|
|
|
|
PCIDevice *dev;
|
|
|
|
PIIX4PMState *s;
|
|
|
|
|
|
|
|
dev = pci_create(bus, devfn, "PIIX4_PM");
|
|
|
|
qdev_prop_set_uint32(&dev->qdev, "smb_io_base", smb_io_base);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-05-14 09:29:18 +02:00
|
|
|
s = DO_UPCAST(PIIX4PMState, dev, dev);
|
2010-05-14 09:29:02 +02:00
|
|
|
s->irq = sci_irq;
|
2012-02-23 13:45:20 +01:00
|
|
|
acpi_pm1_cnt_init(&s->ar);
|
2010-05-14 09:29:02 +02:00
|
|
|
s->smi_irq = smi_irq;
|
2010-05-14 09:29:18 +02:00
|
|
|
s->kvm_enabled = kvm_enabled;
|
|
|
|
|
|
|
|
qdev_init_nofail(&dev->qdev);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2012-06-04 13:31:55 +02:00
|
|
|
if (fw_cfg) {
|
|
|
|
uint8_t suspend[6] = {128, 0, 0, 129, 128, 128};
|
|
|
|
suspend[3] = 1 | ((!s->disable_s3) << 7);
|
|
|
|
suspend[4] = s->s4_val | ((!s->disable_s4) << 7);
|
|
|
|
|
|
|
|
fw_cfg_add_file(fw_cfg, "etc/system-states", g_memdup(suspend, 6), 6);
|
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
return s->smb.smbus;
|
|
|
|
}
|
|
|
|
|
2011-12-04 19:22:06 +01:00
|
|
|
static Property piix4_pm_properties[] = {
|
|
|
|
DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
|
2012-06-04 13:31:55 +02:00
|
|
|
DEFINE_PROP_UINT8("disable_s3", PIIX4PMState, disable_s3, 0),
|
|
|
|
DEFINE_PROP_UINT8("disable_s4", PIIX4PMState, disable_s4, 0),
|
|
|
|
DEFINE_PROP_UINT8("s4_val", PIIX4PMState, s4_val, 2),
|
2011-12-04 19:22:06 +01:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void piix4_pm_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 04:34:16 +01:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2011-12-04 19:22:06 +01:00
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
|
|
|
|
|
|
|
k->no_hotplug = 1;
|
|
|
|
k->init = piix4_pm_initfn;
|
|
|
|
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;
|
2011-12-08 04:34:16 +01:00
|
|
|
dc->desc = "PM";
|
|
|
|
dc->no_user = 1;
|
|
|
|
dc->vmsd = &vmstate_acpi;
|
|
|
|
dc->props = piix4_pm_properties;
|
2011-12-04 19:22:06 +01:00
|
|
|
}
|
|
|
|
|
2011-12-08 04:34:16 +01:00
|
|
|
static TypeInfo piix4_pm_info = {
|
|
|
|
.name = "PIIX4_PM",
|
|
|
|
.parent = TYPE_PCI_DEVICE,
|
|
|
|
.instance_size = sizeof(PIIX4PMState),
|
|
|
|
.class_init = piix4_pm_class_init,
|
2010-05-14 09:29:18 +02:00
|
|
|
};
|
|
|
|
|
2012-02-09 15:20:55 +01:00
|
|
|
static void piix4_pm_register_types(void)
|
2010-05-14 09:29:18 +02:00
|
|
|
{
|
2011-12-08 04:34:16 +01:00
|
|
|
type_register_static(&piix4_pm_info);
|
2010-05-14 09:29:18 +02:00
|
|
|
}
|
|
|
|
|
2012-02-09 15:20:55 +01:00
|
|
|
type_init(piix4_pm_register_types)
|
2010-05-14 09:29:18 +02:00
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
static uint32_t gpe_readb(void *opaque, uint32_t addr)
|
|
|
|
{
|
2010-10-17 11:45:25 +02:00
|
|
|
PIIX4PMState *s = opaque;
|
2012-02-23 13:45:16 +01:00
|
|
|
uint32_t val = acpi_gpe_ioport_readb(&s->ar, addr);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-05-14 09:29:22 +02:00
|
|
|
PIIX4_DPRINTF("gpe read %x == %x\n", addr, val);
|
2010-05-14 09:29:02 +02:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void gpe_writeb(void *opaque, uint32_t addr, uint32_t val)
|
|
|
|
{
|
2010-10-17 11:45:25 +02:00
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_gpe_ioport_writeb(&s->ar, addr, val);
|
2010-10-17 11:45:25 +02:00
|
|
|
pm_update_sci(s);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-05-14 09:29:22 +02:00
|
|
|
PIIX4_DPRINTF("gpe write %x <== %d\n", addr, val);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2012-04-05 19:07:08 +02:00
|
|
|
static uint32_t pci_up_read(void *opaque, uint32_t addr)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-04-05 19:07:08 +02:00
|
|
|
PIIX4PMState *s = opaque;
|
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 19:07:15 +02:00
|
|
|
uint32_t val;
|
|
|
|
|
|
|
|
/* Manufacture an "up" value to cause a device check on any hotplug
|
|
|
|
* slot with a device. Extra device checks are harmless. */
|
|
|
|
val = s->pci0_slot_device_present & s->pci0_hotplug_enable;
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2012-04-05 19:07:08 +02:00
|
|
|
PIIX4_DPRINTF("pci_up_read %x\n", val);
|
2010-05-14 09:29:02 +02:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2012-04-05 19:07:08 +02:00
|
|
|
static uint32_t pci_down_read(void *opaque, uint32_t addr)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-04-05 19:07:08 +02:00
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
uint32_t val = s->pci0_status.down;
|
|
|
|
|
|
|
|
PIIX4_DPRINTF("pci_down_read %x\n", val);
|
|
|
|
return val;
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2012-04-05 19:07:28 +02:00
|
|
|
static uint32_t pci_features_read(void *opaque, uint32_t addr)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-04-05 19:07:28 +02:00
|
|
|
/* No feature defined yet */
|
|
|
|
PIIX4_DPRINTF("pci_features_read %x\n", 0);
|
2010-05-14 09:29:02 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pciej_write(void *opaque, uint32_t addr, uint32_t val)
|
|
|
|
{
|
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 19:07:15 +02:00
|
|
|
acpi_piix_eject_slot(opaque, val);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-05-14 09:29:22 +02:00
|
|
|
PIIX4_DPRINTF("pciej write %x <== %d\n", addr, val);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2011-01-11 17:20:39 +01:00
|
|
|
static uint32_t pcirmv_read(void *opaque, uint32_t addr)
|
|
|
|
{
|
|
|
|
PIIX4PMState *s = opaque;
|
|
|
|
|
|
|
|
return s->pci0_hotplug_enable;
|
|
|
|
}
|
|
|
|
|
2010-11-12 08:21:35 +01:00
|
|
|
static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
|
|
|
|
PCIHotplugState state);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
|
|
|
|
2011-03-25 11:54:41 +01:00
|
|
|
register_ioport_write(GPE_BASE, GPE_LEN, 1, gpe_writeb, s);
|
|
|
|
register_ioport_read(GPE_BASE, GPE_LEN, 1, gpe_readb, s);
|
2012-02-23 13:45:16 +01:00
|
|
|
acpi_gpe_blk(&s->ar, GPE_BASE);
|
2010-05-14 09:29:20 +02:00
|
|
|
|
2012-04-05 19:07:08 +02:00
|
|
|
register_ioport_read(PCI_UP_BASE, 4, 4, pci_up_read, s);
|
|
|
|
register_ioport_read(PCI_DOWN_BASE, 4, 4, pci_down_read, s);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
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 19:07:15 +02:00
|
|
|
register_ioport_write(PCI_EJ_BASE, 4, 4, pciej_write, s);
|
2012-04-05 19:07:28 +02:00
|
|
|
register_ioport_read(PCI_EJ_BASE, 4, 4, pci_features_read, s);
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2011-01-11 17:20:39 +01:00
|
|
|
register_ioport_read(PCI_RMV_BASE, 4, 4, pcirmv_read, s);
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
pci_bus_hotplug(bus, piix4_device_hotplug, &s->dev.qdev);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
static void enable_device(PIIX4PMState *s, int slot)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-02-23 13:45:16 +01:00
|
|
|
s->ar.gpe.sts[0] |= PIIX4_PCI_HOTPLUG_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 19:07:15 +02:00
|
|
|
s->pci0_slot_device_present |= (1U << slot);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2010-05-14 09:29:20 +02:00
|
|
|
static void disable_device(PIIX4PMState *s, int slot)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
2012-02-23 13:45:16 +01:00
|
|
|
s->ar.gpe.sts[0] |= PIIX4_PCI_HOTPLUG_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 19:07:15 +02:00
|
|
|
s->pci0_status.down |= (1U << slot);
|
2010-05-14 09:29:02 +02:00
|
|
|
}
|
|
|
|
|
2010-11-12 08:21:35 +01:00
|
|
|
static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
|
|
|
|
PCIHotplugState state)
|
2010-05-14 09:29:02 +02:00
|
|
|
{
|
|
|
|
int slot = PCI_SLOT(dev->devfn);
|
2010-05-14 09:29:20 +02:00
|
|
|
PIIX4PMState *s = DO_UPCAST(PIIX4PMState, dev,
|
2011-12-04 19:22:06 +01:00
|
|
|
PCI_DEVICE(qdev));
|
2010-05-14 09:29:02 +02:00
|
|
|
|
2010-11-12 08:21:35 +01:00
|
|
|
/* Don't send event when device is enabled during qemu machine creation:
|
|
|
|
* it is present on boot, no hotplug event is necessary. We do send an
|
|
|
|
* event when the device is disabled later. */
|
|
|
|
if (state == PCI_COLDPLUG_ENABLED) {
|
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 19:07:15 +02:00
|
|
|
s->pci0_slot_device_present |= (1U << slot);
|
2010-09-06 09:46:18 +02:00
|
|
|
return 0;
|
2010-11-12 08:21:35 +01:00
|
|
|
}
|
2010-09-06 09:46:18 +02:00
|
|
|
|
2010-11-12 08:21:35 +01:00
|
|
|
if (state == PCI_HOTPLUG_ENABLED) {
|
2010-05-14 09:29:20 +02:00
|
|
|
enable_device(s, slot);
|
|
|
|
} else {
|
|
|
|
disable_device(s, slot);
|
|
|
|
}
|
2010-10-17 11:45:25 +02:00
|
|
|
|
|
|
|
pm_update_sci(s);
|
|
|
|
|
2010-05-14 09:29:02 +02:00
|
|
|
return 0;
|
|
|
|
}
|