2006-05-13 16:11:23 +00:00
|
|
|
/*
|
|
|
|
* QEMU i440FX/PIIX3 PCI Bridge Emulation
|
|
|
|
*
|
|
|
|
* Copyright (c) 2006 Fabrice Bellard
|
2007-09-16 21:08:06 +00:00
|
|
|
*
|
2006-05-13 16:11:23 +00: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.
|
|
|
|
*/
|
|
|
|
|
2013-02-04 14:40:22 +00:00
|
|
|
#include "hw/hw.h"
|
2013-02-05 16:06:20 +00:00
|
|
|
#include "hw/i386/pc.h"
|
2013-02-04 14:40:22 +00:00
|
|
|
#include "hw/pci/pci.h"
|
|
|
|
#include "hw/pci/pci_host.h"
|
2013-02-05 16:06:20 +00:00
|
|
|
#include "hw/isa/isa.h"
|
2013-02-04 14:40:22 +00:00
|
|
|
#include "hw/sysbus.h"
|
2012-12-17 17:20:00 +00:00
|
|
|
#include "qemu/range.h"
|
2013-02-05 16:06:20 +00:00
|
|
|
#include "hw/xen/xen.h"
|
|
|
|
#include "hw/pci-host/pam.h"
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
#include "sysemu/sysemu.h"
|
2013-07-29 14:47:57 +00:00
|
|
|
#include "hw/i386/ioapic.h"
|
|
|
|
#include "qapi/visitor.h"
|
2007-11-17 17:14:51 +00:00
|
|
|
|
2009-12-15 11:26:07 +00:00
|
|
|
/*
|
|
|
|
* I440FX chipset data sheet.
|
|
|
|
* http://download.intel.com/design/chipsets/datashts/29054901.pdf
|
|
|
|
*/
|
|
|
|
|
2013-07-29 14:47:52 +00:00
|
|
|
#define TYPE_I440FX_PCI_HOST_BRIDGE "i440FX-pcihost"
|
|
|
|
#define I440FX_PCI_HOST_BRIDGE(obj) \
|
|
|
|
OBJECT_CHECK(I440FXState, (obj), TYPE_I440FX_PCI_HOST_BRIDGE)
|
|
|
|
|
2012-08-20 17:08:09 +00:00
|
|
|
typedef struct I440FXState {
|
|
|
|
PCIHostState parent_obj;
|
2013-07-29 14:47:57 +00:00
|
|
|
PcPciInfo pci_info;
|
|
|
|
uint64_t pci_hole64_size;
|
2013-11-05 23:46:27 +00:00
|
|
|
uint32_t short_root_bus;
|
2012-08-20 17:08:09 +00:00
|
|
|
} I440FXState;
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2011-04-01 11:43:23 +00:00
|
|
|
#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
|
2011-04-01 11:43:22 +00:00
|
|
|
#define PIIX_NUM_PIRQS 4ULL /* PIRQ[A-D] */
|
2011-06-15 16:36:56 +00:00
|
|
|
#define XEN_PIIX_NUM_PIRQS 128ULL
|
2011-04-01 11:43:23 +00:00
|
|
|
#define PIIX_PIRQC 0x60
|
2011-04-01 11:43:22 +00:00
|
|
|
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
/*
|
|
|
|
* Reset Control Register: PCI-accessible ISA-Compatible Register at address
|
|
|
|
* 0xcf9, provided by the PCI/ISA bridge (PIIX3 PCI function 0, 8086:7000).
|
|
|
|
*/
|
|
|
|
#define RCR_IOPORT 0xcf9
|
|
|
|
|
2009-08-28 13:28:18 +00:00
|
|
|
typedef struct PIIX3State {
|
|
|
|
PCIDevice dev;
|
2011-04-01 11:43:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* bitmap to track pic levels.
|
|
|
|
* The pic level is the logical OR of all the PCI irqs mapped to it
|
|
|
|
* So one PIC level is tracked by PIIX_NUM_PIRQS bits.
|
|
|
|
*
|
|
|
|
* PIRQ is mapped to PIC pins, we track it by
|
|
|
|
* PIIX_NUM_PIRQS * PIIX_NUM_PIC_IRQS = 64 bits with
|
|
|
|
* pic_irq * PIIX_NUM_PIRQS + pirq
|
|
|
|
*/
|
|
|
|
#if PIIX_NUM_PIC_IRQS * PIIX_NUM_PIRQS > 64
|
|
|
|
#error "unable to encode pic state in 64bit in pic_levels."
|
|
|
|
#endif
|
|
|
|
uint64_t pic_levels;
|
|
|
|
|
2009-08-28 13:28:19 +00:00
|
|
|
qemu_irq *pic;
|
2011-04-01 11:43:22 +00:00
|
|
|
|
|
|
|
/* This member isn't used. Just for save/load compatibility */
|
|
|
|
int32_t pci_irq_levels_vmstate[PIIX_NUM_PIRQS];
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
|
|
|
|
/* Reset Control Register contents */
|
|
|
|
uint8_t rcr;
|
|
|
|
|
|
|
|
/* IO memory region for Reset Control Register (RCR_IOPORT) */
|
|
|
|
MemoryRegion rcr_mem;
|
2009-09-16 20:25:33 +00:00
|
|
|
} PIIX3State;
|
2009-08-28 13:28:19 +00:00
|
|
|
|
2013-02-23 00:40:37 +00:00
|
|
|
#define TYPE_I440FX_PCI_DEVICE "i440FX"
|
|
|
|
#define I440FX_PCI_DEVICE(obj) \
|
|
|
|
OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_PCI_DEVICE)
|
|
|
|
|
2009-08-28 13:28:15 +00:00
|
|
|
struct PCII440FXState {
|
2013-07-01 10:18:21 +00:00
|
|
|
/*< private >*/
|
|
|
|
PCIDevice parent_obj;
|
|
|
|
/*< public >*/
|
|
|
|
|
2011-08-15 14:17:38 +00:00
|
|
|
MemoryRegion *system_memory;
|
|
|
|
MemoryRegion *pci_address_space;
|
|
|
|
MemoryRegion *ram_memory;
|
|
|
|
PAMMemoryRegion pam_regions[13];
|
|
|
|
MemoryRegion smram_region;
|
2009-08-28 13:28:16 +00:00
|
|
|
uint8_t smm_enabled;
|
2009-08-28 13:28:15 +00:00
|
|
|
};
|
|
|
|
|
2009-12-15 11:26:05 +00:00
|
|
|
|
|
|
|
#define I440FX_PAM 0x59
|
|
|
|
#define I440FX_PAM_SIZE 7
|
|
|
|
#define I440FX_SMRAM 0x72
|
|
|
|
|
2011-04-01 11:43:23 +00:00
|
|
|
static void piix3_set_irq(void *opaque, int pirq, int level);
|
2012-07-19 14:11:47 +00:00
|
|
|
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pci_intx);
|
2011-06-15 16:36:56 +00:00
|
|
|
static void piix3_write_config_xen(PCIDevice *dev,
|
|
|
|
uint32_t address, uint32_t val, int len);
|
2006-09-24 00:16:34 +00:00
|
|
|
|
|
|
|
/* return the global irq number corresponding to a given device irq
|
|
|
|
pin. We could also use the bus number to have a more precise
|
|
|
|
mapping. */
|
2011-04-01 11:43:23 +00:00
|
|
|
static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
|
2006-09-24 00:16:34 +00:00
|
|
|
{
|
|
|
|
int slot_addend;
|
|
|
|
slot_addend = (pci_dev->devfn >> 3) - 1;
|
2011-04-01 11:43:23 +00:00
|
|
|
return (pci_intx + slot_addend) & 3;
|
2006-09-24 00:16:34 +00:00
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2009-08-28 13:28:15 +00:00
|
|
|
static void i440fx_update_memory_mappings(PCII440FXState *d)
|
2006-09-24 18:49:13 +00:00
|
|
|
{
|
2012-11-14 20:54:02 +00:00
|
|
|
int i;
|
2013-07-01 10:18:21 +00:00
|
|
|
PCIDevice *pd = PCI_DEVICE(d);
|
2006-09-24 19:31:43 +00:00
|
|
|
|
2011-08-01 08:04:39 +00:00
|
|
|
memory_region_transaction_begin();
|
2012-11-14 20:54:02 +00:00
|
|
|
for (i = 0; i < 13; i++) {
|
|
|
|
pam_update(&d->pam_regions[i], i,
|
2013-07-01 10:18:21 +00:00
|
|
|
pd->config[I440FX_PAM + ((i + 1) / 2)]);
|
2006-09-24 18:49:13 +00:00
|
|
|
}
|
2013-07-01 10:18:21 +00:00
|
|
|
smram_update(&d->smram_region, pd->config[I440FX_SMRAM], d->smm_enabled);
|
2011-08-01 08:04:39 +00:00
|
|
|
memory_region_transaction_commit();
|
2006-09-24 18:49:13 +00:00
|
|
|
}
|
|
|
|
|
2010-05-14 07:29:04 +00:00
|
|
|
static void i440fx_set_smm(int val, void *arg)
|
2006-09-24 18:49:13 +00:00
|
|
|
{
|
2010-05-14 07:29:04 +00:00
|
|
|
PCII440FXState *d = arg;
|
2013-07-01 10:18:21 +00:00
|
|
|
PCIDevice *pd = PCI_DEVICE(d);
|
2010-05-14 07:29:04 +00:00
|
|
|
|
2012-11-14 20:54:02 +00:00
|
|
|
memory_region_transaction_begin();
|
2013-07-01 10:18:21 +00:00
|
|
|
smram_set_smm(&d->smm_enabled, val, pd->config[I440FX_SMRAM],
|
2012-11-14 20:54:02 +00:00
|
|
|
&d->smram_region);
|
|
|
|
memory_region_transaction_commit();
|
2006-09-24 18:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-08-28 13:28:15 +00:00
|
|
|
static void i440fx_write_config(PCIDevice *dev,
|
2006-09-24 18:49:13 +00:00
|
|
|
uint32_t address, uint32_t val, int len)
|
|
|
|
{
|
2013-02-23 00:40:37 +00:00
|
|
|
PCII440FXState *d = I440FX_PCI_DEVICE(dev);
|
2009-08-28 13:28:15 +00:00
|
|
|
|
2006-09-24 18:49:13 +00:00
|
|
|
/* XXX: implement SMRAM.D_LOCK */
|
2009-08-28 13:28:15 +00:00
|
|
|
pci_default_write_config(dev, address, val, len);
|
2009-12-15 11:26:06 +00:00
|
|
|
if (ranges_overlap(address, len, I440FX_PAM, I440FX_PAM_SIZE) ||
|
|
|
|
range_covers_byte(address, len, I440FX_SMRAM)) {
|
2006-09-24 18:49:13 +00:00
|
|
|
i440fx_update_memory_mappings(d);
|
2009-12-15 11:26:06 +00:00
|
|
|
}
|
2006-09-24 18:49:13 +00:00
|
|
|
}
|
|
|
|
|
2009-08-28 13:28:26 +00:00
|
|
|
static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
|
2006-09-24 18:49:13 +00:00
|
|
|
{
|
2009-08-28 13:28:15 +00:00
|
|
|
PCII440FXState *d = opaque;
|
2013-07-01 10:18:21 +00:00
|
|
|
PCIDevice *pd = PCI_DEVICE(d);
|
2007-12-09 23:56:13 +00:00
|
|
|
int ret, i;
|
2006-09-24 18:49:13 +00:00
|
|
|
|
2013-07-01 10:18:21 +00:00
|
|
|
ret = pci_device_load(pd, f);
|
2006-09-24 18:49:13 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
i440fx_update_memory_mappings(d);
|
2009-08-28 13:28:16 +00:00
|
|
|
qemu_get_8s(f, &d->smm_enabled);
|
2007-12-09 23:56:13 +00:00
|
|
|
|
2011-04-01 11:43:22 +00:00
|
|
|
if (version_id == 2) {
|
|
|
|
for (i = 0; i < PIIX_NUM_PIRQS; i++) {
|
|
|
|
qemu_get_be32(f); /* dummy load for compatibility */
|
|
|
|
}
|
|
|
|
}
|
2007-12-09 23:56:13 +00:00
|
|
|
|
2006-09-24 18:49:13 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-29 20:48:21 +00:00
|
|
|
static int i440fx_post_load(void *opaque, int version_id)
|
2009-08-28 13:28:26 +00:00
|
|
|
{
|
|
|
|
PCII440FXState *d = opaque;
|
|
|
|
|
|
|
|
i440fx_update_memory_mappings(d);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_i440fx = {
|
|
|
|
.name = "I440FX",
|
|
|
|
.version_id = 3,
|
|
|
|
.minimum_version_id = 3,
|
|
|
|
.minimum_version_id_old = 1,
|
|
|
|
.load_state_old = i440fx_load_old,
|
2009-09-10 01:04:30 +00:00
|
|
|
.post_load = i440fx_post_load,
|
2009-08-28 13:28:26 +00:00
|
|
|
.fields = (VMStateField []) {
|
2013-07-01 10:18:21 +00:00
|
|
|
VMSTATE_PCI_DEVICE(parent_obj, PCII440FXState),
|
2009-08-28 13:28:26 +00:00
|
|
|
VMSTATE_UINT8(smm_enabled, PCII440FXState),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-07-29 14:47:57 +00:00
|
|
|
static void i440fx_pcihost_get_pci_hole_start(Object *obj, Visitor *v,
|
|
|
|
void *opaque, const char *name,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
I440FXState *s = I440FX_PCI_HOST_BRIDGE(obj);
|
|
|
|
uint32_t value = s->pci_info.w32.begin;
|
|
|
|
|
|
|
|
visit_type_uint32(v, &value, name, errp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i440fx_pcihost_get_pci_hole_end(Object *obj, Visitor *v,
|
|
|
|
void *opaque, const char *name,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
I440FXState *s = I440FX_PCI_HOST_BRIDGE(obj);
|
|
|
|
uint32_t value = s->pci_info.w32.end;
|
|
|
|
|
|
|
|
visit_type_uint32(v, &value, name, errp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i440fx_pcihost_get_pci_hole64_start(Object *obj, Visitor *v,
|
|
|
|
void *opaque, const char *name,
|
|
|
|
Error **errp)
|
|
|
|
{
|
2013-09-02 09:58:57 +00:00
|
|
|
PCIHostState *h = PCI_HOST_BRIDGE(obj);
|
|
|
|
Range w64;
|
|
|
|
|
|
|
|
pci_bus_get_w64_range(h->bus, &w64);
|
2013-07-29 14:47:57 +00:00
|
|
|
|
2013-09-02 09:58:57 +00:00
|
|
|
visit_type_uint64(v, &w64.begin, name, errp);
|
2013-07-29 14:47:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void i440fx_pcihost_get_pci_hole64_end(Object *obj, Visitor *v,
|
|
|
|
void *opaque, const char *name,
|
|
|
|
Error **errp)
|
|
|
|
{
|
2013-09-02 09:58:57 +00:00
|
|
|
PCIHostState *h = PCI_HOST_BRIDGE(obj);
|
|
|
|
Range w64;
|
|
|
|
|
|
|
|
pci_bus_get_w64_range(h->bus, &w64);
|
2013-07-29 14:47:57 +00:00
|
|
|
|
2013-09-02 09:58:57 +00:00
|
|
|
visit_type_uint64(v, &w64.end, name, errp);
|
2013-07-29 14:47:57 +00:00
|
|
|
}
|
|
|
|
|
2013-07-01 10:18:20 +00:00
|
|
|
static void i440fx_pcihost_initfn(Object *obj)
|
2006-05-13 16:11:23 +00:00
|
|
|
{
|
2013-07-01 10:18:20 +00:00
|
|
|
PCIHostState *s = PCI_HOST_BRIDGE(obj);
|
2013-07-29 14:47:57 +00:00
|
|
|
I440FXState *d = I440FX_PCI_HOST_BRIDGE(obj);
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2013-07-01 10:18:20 +00:00
|
|
|
memory_region_init_io(&s->conf_mem, obj, &pci_host_conf_le_ops, s,
|
2011-07-24 14:47:18 +00:00
|
|
|
"pci-conf-idx", 4);
|
2013-07-01 10:18:20 +00:00
|
|
|
memory_region_init_io(&s->data_mem, obj, &pci_host_data_le_ops, s,
|
2011-07-24 14:47:18 +00:00
|
|
|
"pci-conf-data", 4);
|
2013-07-29 14:47:57 +00:00
|
|
|
|
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "int",
|
|
|
|
i440fx_pcihost_get_pci_hole_start,
|
|
|
|
NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "int",
|
|
|
|
i440fx_pcihost_get_pci_hole_end,
|
|
|
|
NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "int",
|
|
|
|
i440fx_pcihost_get_pci_hole64_start,
|
|
|
|
NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "int",
|
|
|
|
i440fx_pcihost_get_pci_hole64_end,
|
|
|
|
NULL, NULL, NULL, NULL);
|
|
|
|
|
|
|
|
d->pci_info.w32.end = IO_APIC_DEFAULT_ADDRESS;
|
2013-07-01 10:18:20 +00:00
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2013-07-01 10:18:20 +00:00
|
|
|
static void i440fx_pcihost_realize(DeviceState *dev, Error **errp)
|
|
|
|
{
|
|
|
|
PCIHostState *s = PCI_HOST_BRIDGE(dev);
|
|
|
|
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
|
|
|
|
|
|
|
|
sysbus_add_io(sbd, 0xcf8, &s->conf_mem);
|
|
|
|
sysbus_init_ioports(sbd, 0xcf8, 4);
|
|
|
|
|
|
|
|
sysbus_add_io(sbd, 0xcfc, &s->data_mem);
|
|
|
|
sysbus_init_ioports(sbd, 0xcfc, 4);
|
2009-07-22 13:17:01 +00:00
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2009-08-28 13:28:15 +00:00
|
|
|
static int i440fx_initfn(PCIDevice *dev)
|
2009-07-22 13:17:01 +00:00
|
|
|
{
|
2013-02-23 00:40:37 +00:00
|
|
|
PCII440FXState *d = I440FX_PCI_DEVICE(dev);
|
2006-09-24 18:49:13 +00:00
|
|
|
|
2013-07-01 10:18:21 +00:00
|
|
|
dev->config[I440FX_SMRAM] = 0x02;
|
2006-09-24 18:49:13 +00:00
|
|
|
|
2010-05-14 07:29:04 +00:00
|
|
|
cpu_smm_register(&i440fx_set_smm, d);
|
2009-08-14 08:36:05 +00:00
|
|
|
return 0;
|
2009-07-22 13:17:01 +00:00
|
|
|
}
|
|
|
|
|
2013-07-29 14:47:53 +00:00
|
|
|
PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
|
|
|
|
int *piix3_devfn,
|
|
|
|
ISABus **isa_bus, qemu_irq *pic,
|
|
|
|
MemoryRegion *address_space_mem,
|
|
|
|
MemoryRegion *address_space_io,
|
|
|
|
ram_addr_t ram_size,
|
2013-07-29 14:47:57 +00:00
|
|
|
ram_addr_t above_4g_mem_size,
|
2013-07-29 14:47:53 +00:00
|
|
|
MemoryRegion *pci_address_space,
|
|
|
|
MemoryRegion *ram_memory)
|
2009-07-22 13:17:01 +00:00
|
|
|
{
|
|
|
|
DeviceState *dev;
|
|
|
|
PCIBus *b;
|
|
|
|
PCIDevice *d;
|
2012-08-20 17:08:08 +00:00
|
|
|
PCIHostState *s;
|
2009-09-16 20:25:33 +00:00
|
|
|
PIIX3State *piix3;
|
2011-08-15 14:17:38 +00:00
|
|
|
PCII440FXState *f;
|
2012-10-17 15:10:04 +00:00
|
|
|
unsigned i;
|
2013-07-29 14:47:57 +00:00
|
|
|
I440FXState *i440fx;
|
2009-07-22 13:17:01 +00:00
|
|
|
|
2013-07-29 14:47:52 +00:00
|
|
|
dev = qdev_create(NULL, TYPE_I440FX_PCI_HOST_BRIDGE);
|
2012-08-20 17:08:08 +00:00
|
|
|
s = PCI_HOST_BRIDGE(dev);
|
2012-08-20 17:08:09 +00:00
|
|
|
b = pci_bus_new(dev, NULL, pci_address_space,
|
2013-03-14 22:01:11 +00:00
|
|
|
address_space_io, 0, TYPE_PCI_BUS);
|
2009-07-22 13:17:01 +00:00
|
|
|
s->bus = b;
|
2012-03-28 14:34:12 +00:00
|
|
|
object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL);
|
2012-03-27 16:38:46 +00:00
|
|
|
qdev_init_nofail(dev);
|
2009-07-22 13:17:01 +00:00
|
|
|
|
2013-07-29 14:47:53 +00:00
|
|
|
d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
|
2013-02-23 00:40:37 +00:00
|
|
|
*pi440fx_state = I440FX_PCI_DEVICE(d);
|
2011-08-15 14:17:38 +00:00
|
|
|
f = *pi440fx_state;
|
|
|
|
f->system_memory = address_space_mem;
|
|
|
|
f->pci_address_space = pci_address_space;
|
|
|
|
f->ram_memory = ram_memory;
|
2013-07-29 14:47:57 +00:00
|
|
|
|
|
|
|
i440fx = I440FX_PCI_HOST_BRIDGE(dev);
|
|
|
|
/* Set PCI window size the way seabios has always done it. */
|
|
|
|
/* Power of 2 so bios can cover it with a single MTRR */
|
|
|
|
if (ram_size <= 0x80000000) {
|
|
|
|
i440fx->pci_info.w32.begin = 0x80000000;
|
|
|
|
} else if (ram_size <= 0xc0000000) {
|
|
|
|
i440fx->pci_info.w32.begin = 0xc0000000;
|
|
|
|
} else {
|
|
|
|
i440fx->pci_info.w32.begin = 0xe0000000;
|
|
|
|
}
|
|
|
|
|
2013-10-29 12:57:34 +00:00
|
|
|
/* setup pci memory mapping */
|
|
|
|
pc_pci_as_mapping_init(OBJECT(f), f->system_memory,
|
|
|
|
f->pci_address_space);
|
|
|
|
|
2013-06-07 01:25:08 +00:00
|
|
|
memory_region_init_alias(&f->smram_region, OBJECT(d), "smram-region",
|
2011-08-15 14:17:38 +00:00
|
|
|
f->pci_address_space, 0xa0000, 0x20000);
|
2011-12-04 18:06:16 +00:00
|
|
|
memory_region_add_subregion_overlap(f->system_memory, 0xa0000,
|
|
|
|
&f->smram_region, 1);
|
|
|
|
memory_region_set_enabled(&f->smram_region, false);
|
2013-06-25 10:33:01 +00:00
|
|
|
init_pam(dev, f->ram_memory, f->system_memory, f->pci_address_space,
|
2012-11-14 20:54:02 +00:00
|
|
|
&f->pam_regions[0], PAM_BIOS_BASE, PAM_BIOS_SIZE);
|
2012-10-17 15:10:04 +00:00
|
|
|
for (i = 0; i < 12; ++i) {
|
2013-06-25 10:33:01 +00:00
|
|
|
init_pam(dev, f->ram_memory, f->system_memory, f->pci_address_space,
|
2012-11-14 20:54:02 +00:00
|
|
|
&f->pam_regions[i+1], PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE,
|
|
|
|
PAM_EXPAN_SIZE);
|
2012-10-17 15:10:04 +00:00
|
|
|
}
|
2009-07-22 13:17:01 +00:00
|
|
|
|
2011-06-15 16:36:56 +00:00
|
|
|
/* Xen supports additional interrupt routes from the PCI devices to
|
|
|
|
* the IOAPIC: the four pins of each PCI device on the bus are also
|
|
|
|
* connected to the IOAPIC directly.
|
|
|
|
* These additional routes can be discovered through ACPI. */
|
|
|
|
if (xen_enabled()) {
|
|
|
|
piix3 = DO_UPCAST(PIIX3State, dev,
|
|
|
|
pci_create_simple_multifunction(b, -1, true, "PIIX3-xen"));
|
|
|
|
pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq,
|
|
|
|
piix3, XEN_PIIX_NUM_PIRQS);
|
|
|
|
} else {
|
|
|
|
piix3 = DO_UPCAST(PIIX3State, dev,
|
|
|
|
pci_create_simple_multifunction(b, -1, true, "PIIX3"));
|
|
|
|
pci_bus_irqs(b, piix3_set_irq, pci_slot_get_pirq, piix3,
|
|
|
|
PIIX_NUM_PIRQS);
|
2012-07-19 14:11:47 +00:00
|
|
|
pci_bus_set_route_irq_fn(b, piix3_route_intx_pin_to_irq);
|
2011-06-15 16:36:56 +00:00
|
|
|
}
|
2009-09-16 20:25:33 +00:00
|
|
|
piix3->pic = pic;
|
2013-02-23 00:40:38 +00:00
|
|
|
*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(piix3), "isa.0"));
|
2010-07-16 13:55:39 +00:00
|
|
|
|
2009-09-16 20:25:33 +00:00
|
|
|
*piix3_devfn = piix3->dev.devfn;
|
2009-08-28 13:28:20 +00:00
|
|
|
|
2010-04-20 18:48:06 +00:00
|
|
|
ram_size = ram_size / 8 / 1024 / 1024;
|
2013-07-01 10:18:21 +00:00
|
|
|
if (ram_size > 255) {
|
2010-04-20 18:48:06 +00:00
|
|
|
ram_size = 255;
|
2013-07-01 10:18:21 +00:00
|
|
|
}
|
|
|
|
d->config[0x57] = ram_size;
|
2010-04-20 18:48:06 +00:00
|
|
|
|
2011-08-15 14:17:38 +00:00
|
|
|
i440fx_update_memory_mappings(f);
|
|
|
|
|
2006-05-13 16:11:23 +00:00
|
|
|
return b;
|
|
|
|
}
|
|
|
|
|
2013-07-24 15:56:11 +00:00
|
|
|
PCIBus *find_i440fx(void)
|
|
|
|
{
|
|
|
|
PCIHostState *s = OBJECT_CHECK(PCIHostState,
|
|
|
|
object_resolve_path("/machine/i440fx", NULL),
|
|
|
|
TYPE_PCI_HOST_BRIDGE);
|
|
|
|
return s ? s->bus : NULL;
|
|
|
|
}
|
|
|
|
|
2006-05-13 16:11:23 +00:00
|
|
|
/* PIIX3 PCI to ISA bridge */
|
2011-04-01 11:43:23 +00:00
|
|
|
static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
|
|
|
|
{
|
|
|
|
qemu_set_irq(piix3->pic[pic_irq],
|
|
|
|
!!(piix3->pic_levels &
|
2011-05-16 11:50:55 +00:00
|
|
|
(((1ULL << PIIX_NUM_PIRQS) - 1) <<
|
2011-04-01 11:43:23 +00:00
|
|
|
(pic_irq * PIIX_NUM_PIRQS))));
|
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2011-04-01 11:43:24 +00:00
|
|
|
static void piix3_set_irq_level(PIIX3State *piix3, int pirq, int level)
|
2011-04-01 11:43:23 +00:00
|
|
|
{
|
|
|
|
int pic_irq;
|
|
|
|
uint64_t mask;
|
|
|
|
|
|
|
|
pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
|
|
|
|
if (pic_irq >= PIIX_NUM_PIC_IRQS) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mask = 1ULL << ((pic_irq * PIIX_NUM_PIRQS) + pirq);
|
|
|
|
piix3->pic_levels &= ~mask;
|
|
|
|
piix3->pic_levels |= mask * !!level;
|
|
|
|
|
2011-04-01 11:43:24 +00:00
|
|
|
piix3_set_irq_pic(piix3, pic_irq);
|
2011-04-01 11:43:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void piix3_set_irq(void *opaque, int pirq, int level)
|
2006-05-13 16:11:23 +00:00
|
|
|
{
|
2009-09-16 20:25:33 +00:00
|
|
|
PIIX3State *piix3 = opaque;
|
2011-04-01 11:43:24 +00:00
|
|
|
piix3_set_irq_level(piix3, pirq, level);
|
2011-04-01 11:43:23 +00:00
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2012-07-19 14:11:47 +00:00
|
|
|
static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pin)
|
|
|
|
{
|
|
|
|
PIIX3State *piix3 = opaque;
|
|
|
|
int irq = piix3->dev.config[PIIX_PIRQC + pin];
|
|
|
|
PCIINTxRoute route;
|
|
|
|
|
|
|
|
if (irq < PIIX_NUM_PIC_IRQS) {
|
|
|
|
route.mode = PCI_INTX_ENABLED;
|
|
|
|
route.irq = irq;
|
|
|
|
} else {
|
|
|
|
route.mode = PCI_INTX_DISABLED;
|
|
|
|
route.irq = -1;
|
|
|
|
}
|
|
|
|
return route;
|
|
|
|
}
|
|
|
|
|
2011-04-01 11:43:23 +00:00
|
|
|
/* irq routing is changed. so rebuild bitmap */
|
|
|
|
static void piix3_update_irq_levels(PIIX3State *piix3)
|
|
|
|
{
|
|
|
|
int pirq;
|
|
|
|
|
|
|
|
piix3->pic_levels = 0;
|
|
|
|
for (pirq = 0; pirq < PIIX_NUM_PIRQS; pirq++) {
|
|
|
|
piix3_set_irq_level(piix3, pirq,
|
2011-04-01 11:43:24 +00:00
|
|
|
pci_bus_get_irq_level(piix3->dev.bus, pirq));
|
2011-04-01 11:43:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void piix3_write_config(PCIDevice *dev,
|
|
|
|
uint32_t address, uint32_t val, int len)
|
|
|
|
{
|
|
|
|
pci_default_write_config(dev, address, val, len);
|
|
|
|
if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
|
|
|
|
PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev);
|
|
|
|
int pic_irq;
|
2012-07-02 12:38:47 +00:00
|
|
|
|
|
|
|
pci_bus_fire_intx_routing_notifier(piix3->dev.bus);
|
2011-04-01 11:43:23 +00:00
|
|
|
piix3_update_irq_levels(piix3);
|
|
|
|
for (pic_irq = 0; pic_irq < PIIX_NUM_PIC_IRQS; pic_irq++) {
|
|
|
|
piix3_set_irq_pic(piix3, pic_irq);
|
2006-09-24 00:16:34 +00:00
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-06-15 16:36:56 +00:00
|
|
|
static void piix3_write_config_xen(PCIDevice *dev,
|
|
|
|
uint32_t address, uint32_t val, int len)
|
|
|
|
{
|
|
|
|
xen_piix_pci_write_config_client(address, val, len);
|
|
|
|
piix3_write_config(dev, address, val, len);
|
|
|
|
}
|
|
|
|
|
2009-06-17 16:32:01 +00:00
|
|
|
static void piix3_reset(void *opaque)
|
2006-05-13 16:11:23 +00:00
|
|
|
{
|
2009-08-28 13:28:18 +00:00
|
|
|
PIIX3State *d = opaque;
|
|
|
|
uint8_t *pci_conf = d->dev.config;
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2013-02-23 00:40:39 +00:00
|
|
|
pci_conf[0x04] = 0x07; /* master, memory and I/O */
|
2006-05-13 16:11:23 +00:00
|
|
|
pci_conf[0x05] = 0x00;
|
|
|
|
pci_conf[0x06] = 0x00;
|
2013-02-23 00:40:39 +00:00
|
|
|
pci_conf[0x07] = 0x02; /* PCI_status_devsel_medium */
|
2006-05-13 16:11:23 +00:00
|
|
|
pci_conf[0x4c] = 0x4d;
|
|
|
|
pci_conf[0x4e] = 0x03;
|
|
|
|
pci_conf[0x4f] = 0x00;
|
|
|
|
pci_conf[0x60] = 0x80;
|
2008-03-28 22:28:45 +00:00
|
|
|
pci_conf[0x61] = 0x80;
|
|
|
|
pci_conf[0x62] = 0x80;
|
|
|
|
pci_conf[0x63] = 0x80;
|
2006-05-13 16:11:23 +00:00
|
|
|
pci_conf[0x69] = 0x02;
|
|
|
|
pci_conf[0x70] = 0x80;
|
|
|
|
pci_conf[0x76] = 0x0c;
|
|
|
|
pci_conf[0x77] = 0x0c;
|
|
|
|
pci_conf[0x78] = 0x02;
|
|
|
|
pci_conf[0x79] = 0x00;
|
|
|
|
pci_conf[0x80] = 0x00;
|
|
|
|
pci_conf[0x82] = 0x00;
|
|
|
|
pci_conf[0xa0] = 0x08;
|
|
|
|
pci_conf[0xa2] = 0x00;
|
|
|
|
pci_conf[0xa3] = 0x00;
|
|
|
|
pci_conf[0xa4] = 0x00;
|
|
|
|
pci_conf[0xa5] = 0x00;
|
|
|
|
pci_conf[0xa6] = 0x00;
|
|
|
|
pci_conf[0xa7] = 0x00;
|
|
|
|
pci_conf[0xa8] = 0x0f;
|
|
|
|
pci_conf[0xaa] = 0x00;
|
|
|
|
pci_conf[0xab] = 0x00;
|
|
|
|
pci_conf[0xac] = 0x00;
|
|
|
|
pci_conf[0xae] = 0x00;
|
2011-04-01 11:43:23 +00:00
|
|
|
|
|
|
|
d->pic_levels = 0;
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
d->rcr = 0;
|
2011-04-01 11:43:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int piix3_post_load(void *opaque, int version_id)
|
|
|
|
{
|
|
|
|
PIIX3State *piix3 = opaque;
|
|
|
|
piix3_update_irq_levels(piix3);
|
|
|
|
return 0;
|
2011-04-01 11:43:22 +00:00
|
|
|
}
|
2009-06-17 16:32:01 +00:00
|
|
|
|
2011-04-01 11:43:22 +00:00
|
|
|
static void piix3_pre_save(void *opaque)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
PIIX3State *piix3 = opaque;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(piix3->pci_irq_levels_vmstate); i++) {
|
|
|
|
piix3->pci_irq_levels_vmstate[i] =
|
|
|
|
pci_bus_get_irq_level(piix3->dev.bus, i);
|
|
|
|
}
|
2006-05-13 16:11:23 +00:00
|
|
|
}
|
|
|
|
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
static bool piix3_rcr_needed(void *opaque)
|
|
|
|
{
|
|
|
|
PIIX3State *piix3 = opaque;
|
|
|
|
|
|
|
|
return (piix3->rcr != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_piix3_rcr = {
|
|
|
|
.name = "PIIX3/rcr",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.fields = (VMStateField []) {
|
|
|
|
VMSTATE_UINT8(rcr, PIIX3State),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2009-08-28 13:28:27 +00:00
|
|
|
static const VMStateDescription vmstate_piix3 = {
|
|
|
|
.name = "PIIX3",
|
|
|
|
.version_id = 3,
|
|
|
|
.minimum_version_id = 2,
|
|
|
|
.minimum_version_id_old = 2,
|
2011-04-01 11:43:23 +00:00
|
|
|
.post_load = piix3_post_load,
|
2011-04-01 11:43:22 +00:00
|
|
|
.pre_save = piix3_pre_save,
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
.fields = (VMStateField[]) {
|
2009-08-28 13:28:27 +00:00
|
|
|
VMSTATE_PCI_DEVICE(dev, PIIX3State),
|
2011-04-01 11:43:22 +00:00
|
|
|
VMSTATE_INT32_ARRAY_V(pci_irq_levels_vmstate, PIIX3State,
|
|
|
|
PIIX_NUM_PIRQS, 3),
|
2009-08-28 13:28:27 +00:00
|
|
|
VMSTATE_END_OF_LIST()
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
},
|
|
|
|
.subsections = (VMStateSubsection[]) {
|
|
|
|
{
|
|
|
|
.vmsd = &vmstate_piix3_rcr,
|
|
|
|
.needed = piix3_rcr_needed,
|
|
|
|
},
|
|
|
|
{ 0 }
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static void rcr_write(void *opaque, hwaddr addr, uint64_t val, unsigned len)
|
|
|
|
{
|
|
|
|
PIIX3State *d = opaque;
|
|
|
|
|
|
|
|
if (val & 4) {
|
|
|
|
qemu_system_reset_request();
|
|
|
|
return;
|
2009-08-28 13:28:24 +00:00
|
|
|
}
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
d->rcr = val & 2; /* keep System Reset type only */
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t rcr_read(void *opaque, hwaddr addr, unsigned len)
|
|
|
|
{
|
|
|
|
PIIX3State *d = opaque;
|
|
|
|
|
|
|
|
return d->rcr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const MemoryRegionOps rcr_ops = {
|
|
|
|
.read = rcr_read,
|
|
|
|
.write = rcr_write,
|
|
|
|
.endianness = DEVICE_LITTLE_ENDIAN
|
2009-08-28 13:28:27 +00:00
|
|
|
};
|
2006-08-17 10:46:34 +00:00
|
|
|
|
2009-08-28 13:28:18 +00:00
|
|
|
static int piix3_initfn(PCIDevice *dev)
|
2006-05-13 16:11:23 +00:00
|
|
|
{
|
2009-08-28 13:28:18 +00:00
|
|
|
PIIX3State *d = DO_UPCAST(PIIX3State, dev, dev);
|
2006-05-13 16:11:23 +00:00
|
|
|
|
2013-02-23 00:40:38 +00:00
|
|
|
isa_bus_new(DEVICE(d), pci_address_space_io(dev));
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
|
2013-06-07 01:25:08 +00:00
|
|
|
memory_region_init_io(&d->rcr_mem, OBJECT(dev), &rcr_ops, d,
|
|
|
|
"piix3-reset-control", 1);
|
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
Traditional PCI config space access is achieved by writing a 32 bit
value to io port 0xcf8 to identify the bus, device, function and config
register. Port 0xcfc then contains the register in question. But if you
write the appropriate pair of magic values to 0xcf9, the machine will
reboot. Spectacular! And not standardised in any way (certainly not part
of the PCI spec), so different chipsets may have different requirements.
Booo.
In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.
RHBZ reference: 890459
This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control
I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:
kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
count=1) [kvm-all.c:1422]
cpu_outb (addr=3321, val=6 '\006') [ioport.c:289]
ioport_write (index=0, address=3321, data=6) [ioport.c:83]
ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
[ioport.c:212]
memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
width=1, data=6) [memory.c:439]
access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
size=1, access_size_min=1,
access_size_max=4,
access=0x7f3f5f6e0f90
<memory_region_write_accessor>,
opaque=0x7f3f6227b668)
[memory.c:364]
memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
value=0x7f3f531fbac0, size=1,
shift=0, mask=255)
[memory.c:334]
rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
[hw/piix_pci.c:498]
The dispatch happens in ioport_write(); "index=0" means byte-wide access:
static void ioport_write(int index, uint32_t address, uint32_t data)
{
static IOPortWriteFunc * const default_func[3] = {
default_ioport_writeb,
default_ioport_writew,
default_ioport_writel
};
IOPortWriteFunc *func = ioport_write_table[index][address];
if (!func)
func = default_func[index];
func(ioport_opaque[address], address, data);
}
The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.
4-byte wide access to 0xcf8 (pci-conf-idx):
(gdb) print ioport_write_table[2][0xcf8]
$1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
$2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f5575cb <pci_host_config_write>
1-byte wide access to 0xcf9 (piix3-reset-control):
(gdb) print ioport_write_table[0][0xcf9]
$3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>
(gdb) print \
((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
$4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
0x7f3f5f6b42f1 <rcr_write>
The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-24 09:31:20 +00:00
|
|
|
memory_region_add_subregion_overlap(pci_address_space_io(dev), RCR_IOPORT,
|
|
|
|
&d->rcr_mem, 1);
|
|
|
|
|
2009-06-27 07:25:07 +00:00
|
|
|
qemu_register_reset(piix3_reset, d);
|
2009-08-14 08:36:05 +00:00
|
|
|
return 0;
|
2006-05-13 16:11:23 +00:00
|
|
|
}
|
2007-01-15 17:08:08 +00:00
|
|
|
|
2011-12-04 18:22:06 +00:00
|
|
|
static void piix3_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 03:34:16 +00:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2011-12-04 18:22:06 +00:00
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
|
|
|
|
2011-12-08 03:34:16 +00:00
|
|
|
dc->desc = "ISA bridge";
|
|
|
|
dc->vmsd = &vmstate_piix3;
|
qdev: Replace no_user by cannot_instantiate_with_device_add_yet
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add such a device, it'll fail
in sometimes mysterious ways. If you're lucky, you get an
unmysterious immediate crash.
To protect users from such badness, DeviceClass member no_user used to
make device models unavailable with -device / device_add, but that
regressed in commit 18b6dad. The device model is still omitted from
help, but is available anyway.
Attempts to fix the regression have been rejected with the argument
that the purpose of no_user isn't clear, and it's prone to misuse.
This commit clarifies no_user's purpose. Anthony suggested to rename
it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
I shorten somewhat to keep checkpatch happy. While there, make it
bool.
Every use of cannot_instantiate_with_device_add_yet gets a FIXME
comment asking for rationale. The next few commits will clean them
all up, either by providing a rationale, or by getting rid of the use.
With that done, the regression fix is hopefully acceptable.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-11-28 16:26:54 +00:00
|
|
|
dc->cannot_instantiate_with_device_add_yet = true; /* FIXME explain why */
|
2011-12-04 18:22:06 +00:00
|
|
|
k->no_hotplug = 1;
|
|
|
|
k->init = piix3_initfn;
|
|
|
|
k->config_write = piix3_write_config;
|
|
|
|
k->vendor_id = PCI_VENDOR_ID_INTEL;
|
2013-02-23 00:40:39 +00:00
|
|
|
/* 82371SB PIIX3 PCI-to-ISA bridge (Step A1) */
|
|
|
|
k->device_id = PCI_DEVICE_ID_INTEL_82371SB_0;
|
2011-12-04 18:22:06 +00:00
|
|
|
k->class_id = PCI_CLASS_BRIDGE_ISA;
|
|
|
|
}
|
|
|
|
|
2012-08-20 17:07:56 +00:00
|
|
|
static const TypeInfo piix3_info = {
|
2011-12-08 03:34:16 +00:00
|
|
|
.name = "PIIX3",
|
|
|
|
.parent = TYPE_PCI_DEVICE,
|
|
|
|
.instance_size = sizeof(PIIX3State),
|
|
|
|
.class_init = piix3_class_init,
|
2011-12-07 01:32:44 +00:00
|
|
|
};
|
|
|
|
|
2011-12-04 18:22:06 +00:00
|
|
|
static void piix3_xen_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 03:34:16 +00:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2011-12-04 18:22:06 +00:00
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
|
|
|
|
2011-12-08 03:34:16 +00:00
|
|
|
dc->desc = "ISA bridge";
|
|
|
|
dc->vmsd = &vmstate_piix3;
|
qdev: Replace no_user by cannot_instantiate_with_device_add_yet
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add such a device, it'll fail
in sometimes mysterious ways. If you're lucky, you get an
unmysterious immediate crash.
To protect users from such badness, DeviceClass member no_user used to
make device models unavailable with -device / device_add, but that
regressed in commit 18b6dad. The device model is still omitted from
help, but is available anyway.
Attempts to fix the regression have been rejected with the argument
that the purpose of no_user isn't clear, and it's prone to misuse.
This commit clarifies no_user's purpose. Anthony suggested to rename
it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
I shorten somewhat to keep checkpatch happy. While there, make it
bool.
Every use of cannot_instantiate_with_device_add_yet gets a FIXME
comment asking for rationale. The next few commits will clean them
all up, either by providing a rationale, or by getting rid of the use.
With that done, the regression fix is hopefully acceptable.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-11-28 16:26:54 +00:00
|
|
|
dc->cannot_instantiate_with_device_add_yet = true; /* FIXME explain why */
|
2011-12-04 18:22:06 +00:00
|
|
|
k->no_hotplug = 1;
|
|
|
|
k->init = piix3_initfn;
|
|
|
|
k->config_write = piix3_write_config_xen;
|
|
|
|
k->vendor_id = PCI_VENDOR_ID_INTEL;
|
2013-02-23 00:40:39 +00:00
|
|
|
/* 82371SB PIIX3 PCI-to-ISA bridge (Step A1) */
|
|
|
|
k->device_id = PCI_DEVICE_ID_INTEL_82371SB_0;
|
2011-12-04 18:22:06 +00:00
|
|
|
k->class_id = PCI_CLASS_BRIDGE_ISA;
|
2011-12-07 01:32:44 +00:00
|
|
|
};
|
|
|
|
|
2012-08-20 17:07:56 +00:00
|
|
|
static const TypeInfo piix3_xen_info = {
|
2011-12-08 03:34:16 +00:00
|
|
|
.name = "PIIX3-xen",
|
|
|
|
.parent = TYPE_PCI_DEVICE,
|
|
|
|
.instance_size = sizeof(PIIX3State),
|
|
|
|
.class_init = piix3_xen_class_init,
|
2011-12-04 18:22:06 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void i440fx_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 03:34:16 +00:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2011-12-04 18:22:06 +00:00
|
|
|
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
|
|
|
|
|
|
|
|
k->no_hotplug = 1;
|
|
|
|
k->init = i440fx_initfn;
|
|
|
|
k->config_write = i440fx_write_config;
|
|
|
|
k->vendor_id = PCI_VENDOR_ID_INTEL;
|
|
|
|
k->device_id = PCI_DEVICE_ID_INTEL_82441;
|
|
|
|
k->revision = 0x02;
|
|
|
|
k->class_id = PCI_CLASS_BRIDGE_HOST;
|
2011-12-08 03:34:16 +00:00
|
|
|
dc->desc = "Host bridge";
|
qdev: Replace no_user by cannot_instantiate_with_device_add_yet
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add such a device, it'll fail
in sometimes mysterious ways. If you're lucky, you get an
unmysterious immediate crash.
To protect users from such badness, DeviceClass member no_user used to
make device models unavailable with -device / device_add, but that
regressed in commit 18b6dad. The device model is still omitted from
help, but is available anyway.
Attempts to fix the regression have been rejected with the argument
that the purpose of no_user isn't clear, and it's prone to misuse.
This commit clarifies no_user's purpose. Anthony suggested to rename
it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
I shorten somewhat to keep checkpatch happy. While there, make it
bool.
Every use of cannot_instantiate_with_device_add_yet gets a FIXME
comment asking for rationale. The next few commits will clean them
all up, either by providing a rationale, or by getting rid of the use.
With that done, the regression fix is hopefully acceptable.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-11-28 16:26:54 +00:00
|
|
|
dc->cannot_instantiate_with_device_add_yet = true; /* FIXME explain why */
|
2011-12-08 03:34:16 +00:00
|
|
|
dc->vmsd = &vmstate_i440fx;
|
2011-12-04 18:22:06 +00:00
|
|
|
}
|
|
|
|
|
2012-08-20 17:07:56 +00:00
|
|
|
static const TypeInfo i440fx_info = {
|
2013-02-23 00:40:37 +00:00
|
|
|
.name = TYPE_I440FX_PCI_DEVICE,
|
2011-12-08 03:34:16 +00:00
|
|
|
.parent = TYPE_PCI_DEVICE,
|
|
|
|
.instance_size = sizeof(PCII440FXState),
|
|
|
|
.class_init = i440fx_class_init,
|
2009-07-22 13:17:01 +00:00
|
|
|
};
|
|
|
|
|
2013-06-06 08:48:49 +00:00
|
|
|
static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
|
|
|
|
PCIBus *rootbus)
|
|
|
|
{
|
2013-11-05 23:46:27 +00:00
|
|
|
I440FXState *s = I440FX_PCI_HOST_BRIDGE(host_bridge);
|
|
|
|
|
2013-06-06 08:48:49 +00:00
|
|
|
/* For backwards compat with old device paths */
|
2013-11-05 23:46:27 +00:00
|
|
|
if (s->short_root_bus) {
|
|
|
|
return "0000";
|
|
|
|
}
|
|
|
|
return "0000:00";
|
2013-06-06 08:48:49 +00:00
|
|
|
}
|
|
|
|
|
2013-07-29 14:47:57 +00:00
|
|
|
static Property i440fx_props[] = {
|
|
|
|
DEFINE_PROP_SIZE(PCI_HOST_PROP_PCI_HOLE64_SIZE, I440FXState,
|
|
|
|
pci_hole64_size, DEFAULT_PCI_HOLE64_SIZE),
|
2013-11-05 23:46:27 +00:00
|
|
|
DEFINE_PROP_UINT32("short_root_bus", I440FXState, short_root_bus, 0),
|
2013-07-29 14:47:57 +00:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
2012-01-24 19:12:29 +00:00
|
|
|
static void i440fx_pcihost_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2011-12-08 03:34:16 +00:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2013-06-06 08:48:49 +00:00
|
|
|
PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(klass);
|
2012-01-24 19:12:29 +00:00
|
|
|
|
2013-06-06 08:48:49 +00:00
|
|
|
hc->root_bus_path = i440fx_pcihost_root_bus_path;
|
2013-07-01 10:18:20 +00:00
|
|
|
dc->realize = i440fx_pcihost_realize;
|
2011-12-08 03:34:16 +00:00
|
|
|
dc->fw_name = "pci";
|
2013-07-29 14:47:57 +00:00
|
|
|
dc->props = i440fx_props;
|
2012-01-24 19:12:29 +00:00
|
|
|
}
|
|
|
|
|
2012-08-20 17:07:56 +00:00
|
|
|
static const TypeInfo i440fx_pcihost_info = {
|
2013-07-29 14:47:52 +00:00
|
|
|
.name = TYPE_I440FX_PCI_HOST_BRIDGE,
|
2012-08-20 17:08:08 +00:00
|
|
|
.parent = TYPE_PCI_HOST_BRIDGE,
|
2011-12-08 03:34:16 +00:00
|
|
|
.instance_size = sizeof(I440FXState),
|
2013-07-01 10:18:20 +00:00
|
|
|
.instance_init = i440fx_pcihost_initfn,
|
2011-12-08 03:34:16 +00:00
|
|
|
.class_init = i440fx_pcihost_class_init,
|
2009-07-22 13:17:01 +00:00
|
|
|
};
|
|
|
|
|
2012-02-09 14:20:55 +00:00
|
|
|
static void i440fx_register_types(void)
|
2009-07-22 13:17:01 +00:00
|
|
|
{
|
2011-12-08 03:34:16 +00:00
|
|
|
type_register_static(&i440fx_info);
|
|
|
|
type_register_static(&piix3_info);
|
|
|
|
type_register_static(&piix3_xen_info);
|
|
|
|
type_register_static(&i440fx_pcihost_info);
|
2009-07-22 13:17:01 +00:00
|
|
|
}
|
2012-02-09 14:20:55 +00:00
|
|
|
|
|
|
|
type_init(i440fx_register_types)
|