2010-05-14 11:29:15 +04:00
|
|
|
/*
|
|
|
|
* QEMU PC System Emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2004 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:03 +03:00
|
|
|
#include "qemu/osdep.h"
|
2020-02-03 13:42:03 +03:00
|
|
|
#include CONFIG_DEVICES
|
2011-08-15 18:17:38 +04:00
|
|
|
|
2018-06-29 17:22:13 +03:00
|
|
|
#include "qemu/units.h"
|
2023-06-12 11:12:38 +03:00
|
|
|
#include "hw/char/parallel-isa.h"
|
2022-10-22 18:04:26 +03:00
|
|
|
#include "hw/dma/i8257.h"
|
2013-08-19 18:26:55 +04:00
|
|
|
#include "hw/loader.h"
|
2019-10-08 12:56:49 +03:00
|
|
|
#include "hw/i386/x86.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/i386/pc.h"
|
|
|
|
#include "hw/i386/apic.h"
|
2019-02-02 22:57:47 +03:00
|
|
|
#include "hw/pci-host/i440fx.h"
|
2023-05-19 11:47:33 +03:00
|
|
|
#include "hw/rtc/mc146818rtc.h"
|
2018-01-06 18:37:26 +03:00
|
|
|
#include "hw/southbridge/piix.h"
|
2018-06-13 15:29:46 +03:00
|
|
|
#include "hw/display/ramfb.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/pci/pci.h"
|
|
|
|
#include "hw/pci/pci_ids.h"
|
|
|
|
#include "hw/usb.h"
|
2012-10-24 10:43:34 +04:00
|
|
|
#include "net/net.h"
|
2023-02-10 01:26:36 +03:00
|
|
|
#include "hw/ide/isa.h"
|
2020-03-17 18:05:37 +03:00
|
|
|
#include "hw/ide/pci.h"
|
2019-08-12 08:23:42 +03:00
|
|
|
#include "hw/irq.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/kvm.h"
|
2023-06-20 08:50:26 +03:00
|
|
|
#include "hw/i386/kvm/clock.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/sysbus.h"
|
2018-11-14 03:31:27 +03:00
|
|
|
#include "hw/i2c/smbus_eeprom.h"
|
2012-12-17 21:19:49 +04:00
|
|
|
#include "exec/memory.h"
|
2013-04-15 10:19:22 +04:00
|
|
|
#include "hw/acpi/acpi.h"
|
2018-02-01 14:18:31 +03:00
|
|
|
#include "qapi/error.h"
|
2014-06-20 05:40:25 +04:00
|
|
|
#include "qemu/error-report.h"
|
2020-05-08 13:02:22 +03:00
|
|
|
#include "sysemu/xen.h"
|
2010-06-30 15:58:34 +04:00
|
|
|
#ifdef CONFIG_XEN
|
2015-07-15 08:37:49 +03:00
|
|
|
#include <xen/hvm/hvm_info_table.h>
|
|
|
|
#include "hw/xen/xen_pt.h"
|
2023-11-11 00:50:35 +03:00
|
|
|
#include "hw/xen/xen_igd.h"
|
2010-06-30 15:58:34 +04:00
|
|
|
#endif
|
2023-01-02 03:39:13 +03:00
|
|
|
#include "hw/xen/xen-x86.h"
|
|
|
|
#include "hw/xen/xen.h"
|
2017-04-24 19:53:30 +03:00
|
|
|
#include "migration/global_state.h"
|
2017-04-24 20:02:44 +03:00
|
|
|
#include "migration/misc.h"
|
2024-02-28 14:09:07 +03:00
|
|
|
#include "sysemu/runstate.h"
|
2017-05-02 19:29:55 +03:00
|
|
|
#include "sysemu/numa.h"
|
2020-04-24 15:34:42 +03:00
|
|
|
#include "hw/hyperv/vmbus-bridge.h"
|
hw/i386: Include "hw/mem/nvdimm.h"
All this files use methods/definitions declared in the NVDIMM
device header. Include it.
This fixes (when modifying unrelated headers):
hw/i386/acpi-build.c:2733:9: error: implicit declaration of function 'nvdimm_build_acpi' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_build_acpi(table_offsets, tables_blob, tables->linker,
^
hw/i386/pc.c:1996:61: error: use of undeclared identifier 'TYPE_NVDIMM'
const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
^
hw/i386/pc.c:2032:55: error: use of undeclared identifier 'TYPE_NVDIMM'
bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
^
hw/i386/pc.c:2040:9: error: implicit declaration of function 'nvdimm_plug' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_plug(ms->nvdimms_state);
^
hw/i386/pc.c:2040:9: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
nvdimm_plug(ms->nvdimms_state);
^
hw/i386/pc.c:2065:42: error: use of undeclared identifier 'TYPE_NVDIMM'
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
^
hw/i386/pc_i440fx.c:307:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
^
hw/i386/pc_q35.c:332:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
^
Acked-by: John Snow <jsnow@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200228114649.12818-17-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-28 14:46:47 +03:00
|
|
|
#include "hw/mem/nvdimm.h"
|
2020-04-21 15:59:29 +03:00
|
|
|
#include "hw/i386/acpi-build.h"
|
2023-09-04 15:43:13 +03:00
|
|
|
#include "target/i386/cpu.h"
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2023-04-03 10:41:21 +03:00
|
|
|
#define XEN_IOAPIC_NUM_PIRQS 128ULL
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2019-07-05 17:35:54 +03:00
|
|
|
#ifdef CONFIG_IDE_ISA
|
2010-05-14 11:29:15 +04:00
|
|
|
static const int ide_iobase[MAX_IDE_BUS] = { 0x1f0, 0x170 };
|
|
|
|
static const int ide_iobase2[MAX_IDE_BUS] = { 0x3f6, 0x376 };
|
|
|
|
static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
|
2019-07-05 17:35:54 +03:00
|
|
|
#endif
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2023-01-09 20:23:18 +03: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.
|
|
|
|
*/
|
|
|
|
static int pc_pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
|
|
|
|
{
|
|
|
|
int slot_addend;
|
|
|
|
slot_addend = PCI_SLOT(pci_dev->devfn) - 1;
|
|
|
|
return (pci_intx + slot_addend) & 3;
|
|
|
|
}
|
|
|
|
|
2023-04-03 10:41:22 +03:00
|
|
|
static void piix_intx_routing_notifier_xen(PCIDevice *dev)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2024-01-08 02:16:23 +03:00
|
|
|
/* Scan for updates to PCI link routes. */
|
2023-04-03 10:41:22 +03:00
|
|
|
for (i = 0; i < PIIX_NUM_PIRQS; i++) {
|
2024-01-08 02:16:23 +03:00
|
|
|
const PCIINTxRoute route = pci_device_route_intx_to_irq(dev, i);
|
|
|
|
const uint8_t v = route.mode == PCI_INTX_ENABLED ? route.irq : 0;
|
2023-04-03 10:41:22 +03:00
|
|
|
xen_set_pci_link_route(i, v);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-14 11:29:15 +04:00
|
|
|
/* PC hardware initialisation */
|
2024-02-28 11:16:42 +03:00
|
|
|
static void pc_init1(MachineState *machine, const char *pci_type)
|
2010-05-14 11:29:15 +04:00
|
|
|
{
|
2015-08-07 22:55:45 +03:00
|
|
|
PCMachineState *pcms = PC_MACHINE(machine);
|
2015-12-02 01:58:03 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
|
2019-10-22 10:39:50 +03:00
|
|
|
X86MachineState *x86ms = X86_MACHINE(machine);
|
2013-08-21 22:14:45 +04:00
|
|
|
MemoryRegion *system_memory = get_system_memory();
|
|
|
|
MemoryRegion *system_io = get_system_io();
|
2024-02-09 01:03:41 +03:00
|
|
|
Object *phb = NULL;
|
2011-12-16 01:09:51 +04:00
|
|
|
ISABus *isa_bus;
|
2023-10-07 15:38:21 +03:00
|
|
|
Object *piix4_pm = NULL;
|
2015-05-26 04:46:05 +03:00
|
|
|
qemu_irq smi_irq;
|
2011-10-07 11:19:35 +04:00
|
|
|
GSIState *gsi_state;
|
2011-08-15 18:17:38 +04:00
|
|
|
MemoryRegion *ram_memory;
|
2023-06-30 10:37:10 +03:00
|
|
|
MemoryRegion *pci_memory = NULL;
|
|
|
|
MemoryRegion *rom_memory = system_memory;
|
2014-06-20 05:40:25 +04:00
|
|
|
ram_addr_t lowmem;
|
2023-06-30 10:37:10 +03:00
|
|
|
uint64_t hole64_size = 0;
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2016-06-02 11:48:25 +03:00
|
|
|
/*
|
|
|
|
* Calculate ram split, for memory below and above 4G. It's a bit
|
|
|
|
* complicated for backward compatibility reasons ...
|
|
|
|
*
|
|
|
|
* - Traditional split is 3.5G (lowmem = 0xe0000000). This is the
|
|
|
|
* default value for max_ram_below_4g now.
|
|
|
|
*
|
|
|
|
* - Then, to gigabyte align the memory, we move the split to 3G
|
|
|
|
* (lowmem = 0xc0000000). But only in case we have to split in
|
|
|
|
* the first place, i.e. ram_size is larger than (traditional)
|
|
|
|
* lowmem. And for new machine types (gigabyte_align = true)
|
|
|
|
* only, for live migration compatibility reasons.
|
|
|
|
*
|
|
|
|
* - Next the max-ram-below-4g option was added, which allowed to
|
|
|
|
* reduce lowmem to a smaller value, to allow a larger PCI I/O
|
|
|
|
* window below 4G. qemu doesn't enforce gigabyte alignment here,
|
|
|
|
* but prints a warning.
|
|
|
|
*
|
|
|
|
* - Finally max-ram-below-4g got updated to also allow raising lowmem,
|
|
|
|
* so legacy non-PAE guests can get as much memory as possible in
|
|
|
|
* the 32bit address space below 4G.
|
|
|
|
*
|
2020-09-08 18:55:26 +03:00
|
|
|
* - Note that Xen has its own ram setup code in xen_ram_init(),
|
|
|
|
* called via xen_hvm_init_pc().
|
2016-06-24 14:35:17 +03:00
|
|
|
*
|
2016-06-02 11:48:25 +03:00
|
|
|
* Examples:
|
|
|
|
* qemu -M pc-1.7 -m 4G (old default) -> 3584M low, 512M high
|
|
|
|
* qemu -M pc -m 4G (new default) -> 3072M low, 1024M high
|
|
|
|
* qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high
|
|
|
|
* qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)
|
2013-12-16 15:54:19 +04:00
|
|
|
*/
|
2016-06-24 14:35:17 +03:00
|
|
|
if (xen_enabled()) {
|
2020-09-08 18:55:26 +03:00
|
|
|
xen_hvm_init_pc(pcms, &ram_memory);
|
2016-06-24 14:35:17 +03:00
|
|
|
} else {
|
2023-02-13 19:20:01 +03:00
|
|
|
ram_memory = machine->ram;
|
2020-05-29 10:39:56 +03:00
|
|
|
if (!pcms->max_ram_below_4g) {
|
|
|
|
pcms->max_ram_below_4g = 0xe0000000; /* default: 3.5G */
|
2016-06-24 14:35:17 +03:00
|
|
|
}
|
2020-05-29 10:39:56 +03:00
|
|
|
lowmem = pcms->max_ram_below_4g;
|
|
|
|
if (machine->ram_size >= pcms->max_ram_below_4g) {
|
2016-06-24 14:35:17 +03:00
|
|
|
if (pcmc->gigabyte_align) {
|
|
|
|
if (lowmem > 0xc0000000) {
|
|
|
|
lowmem = 0xc0000000;
|
|
|
|
}
|
2018-06-29 17:22:13 +03:00
|
|
|
if (lowmem & (1 * GiB - 1)) {
|
2017-07-12 16:57:41 +03:00
|
|
|
warn_report("Large machine and max_ram_below_4g "
|
|
|
|
"(%" PRIu64 ") not a multiple of 1G; "
|
|
|
|
"possible bad performance.",
|
2020-05-29 10:39:56 +03:00
|
|
|
pcms->max_ram_below_4g);
|
2016-06-24 14:35:17 +03:00
|
|
|
}
|
2016-06-02 11:48:25 +03:00
|
|
|
}
|
2014-06-20 05:40:25 +04:00
|
|
|
}
|
|
|
|
|
2016-06-24 14:35:17 +03:00
|
|
|
if (machine->ram_size >= lowmem) {
|
2019-10-22 10:39:50 +03:00
|
|
|
x86ms->above_4g_mem_size = machine->ram_size - lowmem;
|
|
|
|
x86ms->below_4g_mem_size = lowmem;
|
2016-06-24 14:35:17 +03:00
|
|
|
} else {
|
2019-10-22 10:39:50 +03:00
|
|
|
x86ms->above_4g_mem_size = 0;
|
|
|
|
x86ms->below_4g_mem_size = machine->ram_size;
|
2016-06-24 14:35:17 +03:00
|
|
|
}
|
2014-06-20 05:40:24 +04:00
|
|
|
}
|
|
|
|
|
2021-07-19 14:21:24 +03:00
|
|
|
pc_machine_init_sgx_epc(pcms);
|
2019-09-30 18:26:29 +03:00
|
|
|
x86_cpus_init(x86ms, pcmc->default_cpu_version);
|
2014-06-20 05:40:24 +04:00
|
|
|
|
2024-02-24 16:58:49 +03:00
|
|
|
if (kvm_enabled()) {
|
2020-09-22 18:19:34 +03:00
|
|
|
kvmclock_create(pcmc->kvmclock_create_always);
|
2014-06-20 05:40:24 +04:00
|
|
|
}
|
|
|
|
|
2015-12-02 01:58:03 +03:00
|
|
|
if (pcmc->pci_enabled) {
|
2011-09-21 22:49:29 +04:00
|
|
|
pci_memory = g_new(MemoryRegion, 1);
|
2013-11-06 22:18:08 +04:00
|
|
|
memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
|
2011-09-21 22:49:29 +04:00
|
|
|
rom_memory = pci_memory;
|
2023-06-30 10:37:20 +03:00
|
|
|
|
2024-02-28 11:16:42 +03:00
|
|
|
phb = OBJECT(qdev_new(TYPE_I440FX_PCI_HOST_BRIDGE));
|
2023-06-30 10:37:19 +03:00
|
|
|
object_property_add_child(OBJECT(machine), "i440fx", phb);
|
2023-06-30 10:37:20 +03:00
|
|
|
object_property_set_link(phb, PCI_HOST_PROP_RAM_MEM,
|
|
|
|
OBJECT(ram_memory), &error_fatal);
|
|
|
|
object_property_set_link(phb, PCI_HOST_PROP_PCI_MEM,
|
|
|
|
OBJECT(pci_memory), &error_fatal);
|
|
|
|
object_property_set_link(phb, PCI_HOST_PROP_SYSTEM_MEM,
|
|
|
|
OBJECT(system_memory), &error_fatal);
|
|
|
|
object_property_set_link(phb, PCI_HOST_PROP_IO_MEM,
|
|
|
|
OBJECT(system_io), &error_fatal);
|
|
|
|
object_property_set_uint(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
|
|
|
|
x86ms->below_4g_mem_size, &error_fatal);
|
|
|
|
object_property_set_uint(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
|
|
|
|
x86ms->above_4g_mem_size, &error_fatal);
|
|
|
|
object_property_set_str(phb, I440FX_HOST_PROP_PCI_TYPE, pci_type,
|
|
|
|
&error_fatal);
|
|
|
|
sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
|
|
|
|
|
2024-02-24 16:58:48 +03:00
|
|
|
pcms->pcibus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
|
|
|
|
pci_bus_map_irqs(pcms->pcibus,
|
2023-06-30 10:37:20 +03:00
|
|
|
xen_enabled() ? xen_pci_slot_get_pirq
|
|
|
|
: pc_pci_slot_get_pirq);
|
|
|
|
|
2023-06-30 10:37:19 +03:00
|
|
|
hole64_size = object_property_get_uint(phb,
|
2022-07-19 20:00:06 +03:00
|
|
|
PCI_HOST_PROP_PCI_HOLE64_SIZE,
|
|
|
|
&error_abort);
|
2011-09-21 22:49:29 +04:00
|
|
|
}
|
2011-08-15 18:17:38 +04:00
|
|
|
|
2010-05-14 11:29:15 +04:00
|
|
|
/* allocate ram and load rom/bios */
|
2010-06-30 15:58:34 +04:00
|
|
|
if (!xen_enabled()) {
|
2023-02-13 19:20:01 +03:00
|
|
|
pc_memory_init(pcms, system_memory, rom_memory, hole64_size);
|
2020-06-24 15:18:41 +03:00
|
|
|
} else {
|
2023-06-30 10:37:17 +03:00
|
|
|
assert(machine->ram_size == x86ms->below_4g_mem_size +
|
|
|
|
x86ms->above_4g_mem_size);
|
|
|
|
|
2024-02-27 00:59:09 +03:00
|
|
|
pc_system_flash_cleanup_unused(pcms);
|
2020-06-24 15:18:41 +03:00
|
|
|
if (machine->kernel_filename != NULL) {
|
|
|
|
/* For xen HVM direct kernel boot, load linux here */
|
|
|
|
xen_load_linux(pcms);
|
|
|
|
}
|
2010-06-30 15:58:34 +04:00
|
|
|
}
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2019-10-18 16:59:06 +03:00
|
|
|
gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2015-12-02 01:58:03 +03:00
|
|
|
if (pcmc->pci_enabled) {
|
2022-06-03 21:50:45 +03:00
|
|
|
PCIDevice *pci_dev;
|
2023-10-07 15:38:13 +03:00
|
|
|
DeviceState *dev;
|
|
|
|
size_t i;
|
2019-10-15 08:00:41 +03:00
|
|
|
|
2023-10-07 15:38:37 +03:00
|
|
|
pci_dev = pci_new_multifunction(-1, pcms->south_bridge);
|
2023-10-07 15:38:20 +03:00
|
|
|
object_property_set_bool(OBJECT(pci_dev), "has-usb",
|
|
|
|
machine_usb(machine), &error_abort);
|
2023-10-07 15:38:21 +03:00
|
|
|
object_property_set_bool(OBJECT(pci_dev), "has-acpi",
|
|
|
|
x86_machine_is_acpi_enabled(x86ms),
|
|
|
|
&error_abort);
|
2023-10-07 15:38:28 +03:00
|
|
|
object_property_set_bool(OBJECT(pci_dev), "has-pic", false,
|
|
|
|
&error_abort);
|
2023-10-07 15:38:29 +03:00
|
|
|
object_property_set_bool(OBJECT(pci_dev), "has-pit", false,
|
|
|
|
&error_abort);
|
2023-10-07 15:38:21 +03:00
|
|
|
qdev_prop_set_uint32(DEVICE(pci_dev), "smb_io_base", 0xb100);
|
|
|
|
object_property_set_bool(OBJECT(pci_dev), "smm-enabled",
|
|
|
|
x86_machine_is_smm_enabled(x86ms),
|
|
|
|
&error_abort);
|
2023-10-07 15:38:13 +03:00
|
|
|
dev = DEVICE(pci_dev);
|
|
|
|
for (i = 0; i < ISA_NUM_IRQS; i++) {
|
|
|
|
qdev_connect_gpio_out_named(dev, "isa-irqs", i, x86ms->gsi[i]);
|
|
|
|
}
|
2024-02-24 16:58:48 +03:00
|
|
|
pci_realize_and_unref(pci_dev, pcms->pcibus, &error_fatal);
|
2023-04-03 10:41:21 +03:00
|
|
|
|
|
|
|
if (xen_enabled()) {
|
2023-04-03 10:41:22 +03:00
|
|
|
pci_device_set_intx_routing_notifier(
|
|
|
|
pci_dev, piix_intx_routing_notifier_xen);
|
|
|
|
|
2023-04-03 10:41:21 +03: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.
|
|
|
|
*/
|
2024-02-24 16:58:48 +03:00
|
|
|
pci_bus_irqs(pcms->pcibus, xen_intx_set_irq, pci_dev,
|
2023-04-03 10:41:21 +03:00
|
|
|
XEN_IOAPIC_NUM_PIRQS);
|
|
|
|
}
|
|
|
|
|
2023-10-07 15:38:14 +03:00
|
|
|
isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(pci_dev), "isa.0"));
|
2024-02-24 16:58:50 +03:00
|
|
|
x86ms->rtc = ISA_DEVICE(object_resolve_path_component(OBJECT(pci_dev),
|
|
|
|
"rtc"));
|
2023-10-07 15:38:21 +03:00
|
|
|
piix4_pm = object_resolve_path_component(OBJECT(pci_dev), "pm");
|
2023-10-07 15:38:19 +03:00
|
|
|
dev = DEVICE(object_resolve_path_component(OBJECT(pci_dev), "ide"));
|
|
|
|
pci_ide_create_devs(PCI_DEVICE(dev));
|
2024-02-20 19:06:13 +03:00
|
|
|
pcms->idebus[0] = qdev_get_child_bus(dev, "ide.0");
|
|
|
|
pcms->idebus[1] = qdev_get_child_bus(dev, "ide.1");
|
2010-05-14 11:29:15 +04:00
|
|
|
} else {
|
2023-02-13 19:20:00 +03:00
|
|
|
isa_bus = isa_bus_new(NULL, system_memory, system_io,
|
isa: Clean up error handling around isa_bus_new()
We can have at most one ISA bus. If you try to create another one,
isa_bus_new() complains to stderr and returns null.
isa_bus_new() is called in two contexts, machine's init() and device's
realize() methods. Since complaining to stderr is not proper in the
latter context, convert isa_bus_new() to Error.
Machine's init():
* mips_jazz_init(), called from the init() methods of machines
"magnum" and "pica"
* mips_r4k_init(), the init() method of machine "mips"
* pc_init1() called from the init() methods of non-q35 PC machines
* typhoon_init(), called from clipper_init(), the init() method of
machine "clipper"
These callers always create the first ISA bus, hence isa_bus_new()
can't fail. Simply pass &error_abort.
Device's realize():
* i82378_realize(), of PCI device "i82378"
* ich9_lpc_realize(), of PCI device "ICH9-LPC"
* pci_ebus_realize(), of PCI device "ebus"
* piix3_realize(), of PCI device "pci-piix3", abstract parent of
"PIIX3" and "PIIX3-xen"
* piix4_realize(), of PCI device "PIIX4"
* vt82c686b_realize(), of PCI device "VT82C686B"
Propagate the error. Note that these devices are typically created
only by machine init() methods with qdev_init_nofail() or similar. If
we screwed up and created an ISA bus before that call, we now give up
right away. Before, we'd hobble on, and typically die in
isa_bus_irqs(). Similar if someone finds a way to hot-plug one of
these critters.
Cc: Richard Henderson <rth@twiddle.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <1450370121-5768-11-git-send-email-armbru@redhat.com>
2015-12-17 19:35:18 +03:00
|
|
|
&error_abort);
|
2023-10-07 15:38:17 +03:00
|
|
|
isa_bus_register_input_irqs(isa_bus, x86ms->gsi);
|
2023-05-19 11:47:33 +03:00
|
|
|
|
2024-02-24 16:58:50 +03:00
|
|
|
x86ms->rtc = isa_new(TYPE_MC146818_RTC);
|
|
|
|
qdev_prop_set_int32(DEVICE(x86ms->rtc), "base_year", 2000);
|
|
|
|
isa_realize_and_unref(x86ms->rtc, isa_bus, &error_fatal);
|
2023-05-19 11:47:33 +03:00
|
|
|
|
2024-02-13 14:42:14 +03:00
|
|
|
i8257_dma_init(OBJECT(machine), isa_bus, 0);
|
2020-10-21 17:47:16 +03:00
|
|
|
pcms->hpet_enabled = false;
|
2010-05-14 11:29:15 +04:00
|
|
|
}
|
|
|
|
|
2022-03-10 15:28:11 +03:00
|
|
|
if (x86ms->pic == ON_OFF_AUTO_ON || x86ms->pic == ON_OFF_AUTO_AUTO) {
|
|
|
|
pc_i8259_create(isa_bus, gsi_state->i8259_irq);
|
|
|
|
}
|
2011-08-11 02:28:13 +04:00
|
|
|
|
2024-02-09 01:03:41 +03:00
|
|
|
if (phb) {
|
|
|
|
ioapic_init_gsi(gsi_state, phb);
|
2011-08-11 02:28:13 +04:00
|
|
|
}
|
|
|
|
|
2019-10-16 11:18:10 +03:00
|
|
|
if (tcg_enabled()) {
|
|
|
|
x86_register_ferr_irq(x86ms->gsi[13]);
|
|
|
|
}
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2024-02-24 16:58:48 +03:00
|
|
|
pc_vga_init(isa_bus, pcmc->pci_enabled ? pcms->pcibus : NULL);
|
2011-06-16 20:05:17 +04:00
|
|
|
|
qapi: Don't let implicit enum MAX member collide
Now that we guarantee the user doesn't have any enum values
beginning with a single underscore, we can use that for our
own purposes. Renaming ENUM_MAX to ENUM__MAX makes it obvious
that the sentinel is generated.
This patch was mostly generated by applying a temporary patch:
|diff --git a/scripts/qapi.py b/scripts/qapi.py
|index e6d014b..b862ec9 100644
|--- a/scripts/qapi.py
|+++ b/scripts/qapi.py
|@@ -1570,6 +1570,7 @@ const char *const %(c_name)s_lookup[] = {
| max_index = c_enum_const(name, 'MAX', prefix)
| ret += mcgen('''
| [%(max_index)s] = NULL,
|+// %(max_index)s
| };
| ''',
| max_index=max_index)
then running:
$ cat qapi-{types,event}.c tests/test-qapi-types.c |
sed -n 's,^// \(.*\)MAX,s|\1MAX|\1_MAX|g,p' > list
$ git grep -l _MAX | xargs sed -i -f list
The only things not generated are the changes in scripts/qapi.py.
Rejecting enum members named 'MAX' is now useless, and will be dropped
in the next patch.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-23-git-send-email-eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
[Rebased to current master, commit message tweaked]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:57 +03:00
|
|
|
assert(pcms->vmport != ON_OFF_AUTO__MAX);
|
2015-08-07 22:55:45 +03:00
|
|
|
if (pcms->vmport == ON_OFF_AUTO_AUTO) {
|
|
|
|
pcms->vmport = xen_enabled() ? ON_OFF_AUTO_OFF : ON_OFF_AUTO_ON;
|
2014-11-21 19:18:52 +03:00
|
|
|
}
|
|
|
|
|
2010-05-14 11:29:15 +04:00
|
|
|
/* init basic PC hardware */
|
2024-04-25 21:43:15 +03:00
|
|
|
pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc,
|
|
|
|
!MACHINE_CLASS(pcmc)->no_floppy, 0x4);
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2024-02-24 16:58:48 +03:00
|
|
|
pc_nic_init(pcmc, isa_bus, pcms->pcibus);
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2019-07-05 17:35:54 +03:00
|
|
|
#ifdef CONFIG_IDE_ISA
|
2024-02-09 01:03:42 +03:00
|
|
|
if (!pcmc->pci_enabled) {
|
2020-03-17 18:05:37 +03:00
|
|
|
DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
|
2019-11-15 17:50:49 +03:00
|
|
|
int i;
|
2020-03-17 18:05:37 +03:00
|
|
|
|
|
|
|
ide_drive_get(hd, ARRAY_SIZE(hd));
|
2019-11-15 17:50:49 +03:00
|
|
|
for (i = 0; i < MAX_IDE_BUS; i++) {
|
2010-06-24 21:58:20 +04:00
|
|
|
ISADevice *dev;
|
qdev: Keep global allocation counter per bus
When we have 2 separate qdev devices that both create a qbus of the
same type without specifying a bus name or device name, we end up
with two buses of the same name, such as ide.0 on the Mac machines:
dev: macio-ide, id ""
bus: ide.0
type IDE
dev: macio-ide, id ""
bus: ide.0
type IDE
If we now spawn a device that connects to a ide.0 the last created
bus gets the device, with the first created bus inaccessible to the
command line.
After some discussion on IRC we concluded that the best quick fix way
forward for this is to make automated bus-class type based allocation
count a global counter. That's what this patch implements. With this
we instead get
dev: macio-ide, id ""
bus: ide.1
type IDE
dev: macio-ide, id ""
bus: ide.0
type IDE
on the example mentioned above.
This also means that if you did -device ...,bus=ide.0 you got a device
on the first bus (the last created one) before this patch and get that
device on the second one (the first created one) now. Breaks
migration unless you change bus=ide.0 to bus=ide.1 on the destination.
This is intended and makes the bus enumeration work as expected.
As per review request follows a list of otherwise affected boards and
the reasoning for the conclusion that they are ok:
target machine bus id times
------ ------- ------ -----
aarch64 n800 i2c-bus.0 2
aarch64 n810 i2c-bus.0 2
arm n800 i2c-bus.0 2
arm n810 i2c-bus.0 2
-> Devices are only created explicitly on one of the two buses, using
s->mpu->i2c[0], so no change to the guest.
aarch64 vexpress-a15 virtio-mmio-bus.0 4
aarch64 vexpress-a9 virtio-mmio-bus.0 4
aarch64 virt virtio-mmio-bus.0 32
arm vexpress-a15 virtio-mmio-bus.0 4
arm vexpress-a9 virtio-mmio-bus.0 4
arm virt virtio-mmio-bus.0 32
-> Makes -device bus= work for all virtio-mmio buses. Breaks
migration. Workaround for migration from old to new: specify
virtio-mmio-bus.4 or .32 respectively rather than .0 on the
destination.
aarch64 xilinx-zynq-a9 usb-bus.0 2
arm xilinx-zynq-a9 usb-bus.0 2
mips64el fulong2e usb-bus.0 2
-> Normal USB operation not affected. Migration driver needs command
line to use the other bus.
i386 isapc ide.0 2
x86_64 isapc ide.0 2
mips mips ide.0 2
mips64 mips ide.0 2
mips64el mips ide.0 2
mipsel mips ide.0 2
ppc g3beige ide.0 2
ppc mac99 ide.0 2
ppc prep ide.0 2
ppc64 g3beige ide.0 2
ppc64 mac99 ide.0 2
ppc64 prep ide.0 2
-> Makes -device bus= work for all IDE buses. Breaks migration.
Workaround for migration from old to new: specify ide.1 rather than
ide.0 on the destination.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Andreas Faerber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-02-06 19:08:15 +04:00
|
|
|
char busname[] = "ide.0";
|
2011-12-16 01:09:51 +04:00
|
|
|
dev = isa_ide_init(isa_bus, ide_iobase[i], ide_iobase2[i],
|
|
|
|
ide_irq[i],
|
2010-06-24 21:58:20 +04:00
|
|
|
hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
|
qdev: Keep global allocation counter per bus
When we have 2 separate qdev devices that both create a qbus of the
same type without specifying a bus name or device name, we end up
with two buses of the same name, such as ide.0 on the Mac machines:
dev: macio-ide, id ""
bus: ide.0
type IDE
dev: macio-ide, id ""
bus: ide.0
type IDE
If we now spawn a device that connects to a ide.0 the last created
bus gets the device, with the first created bus inaccessible to the
command line.
After some discussion on IRC we concluded that the best quick fix way
forward for this is to make automated bus-class type based allocation
count a global counter. That's what this patch implements. With this
we instead get
dev: macio-ide, id ""
bus: ide.1
type IDE
dev: macio-ide, id ""
bus: ide.0
type IDE
on the example mentioned above.
This also means that if you did -device ...,bus=ide.0 you got a device
on the first bus (the last created one) before this patch and get that
device on the second one (the first created one) now. Breaks
migration unless you change bus=ide.0 to bus=ide.1 on the destination.
This is intended and makes the bus enumeration work as expected.
As per review request follows a list of otherwise affected boards and
the reasoning for the conclusion that they are ok:
target machine bus id times
------ ------- ------ -----
aarch64 n800 i2c-bus.0 2
aarch64 n810 i2c-bus.0 2
arm n800 i2c-bus.0 2
arm n810 i2c-bus.0 2
-> Devices are only created explicitly on one of the two buses, using
s->mpu->i2c[0], so no change to the guest.
aarch64 vexpress-a15 virtio-mmio-bus.0 4
aarch64 vexpress-a9 virtio-mmio-bus.0 4
aarch64 virt virtio-mmio-bus.0 32
arm vexpress-a15 virtio-mmio-bus.0 4
arm vexpress-a9 virtio-mmio-bus.0 4
arm virt virtio-mmio-bus.0 32
-> Makes -device bus= work for all virtio-mmio buses. Breaks
migration. Workaround for migration from old to new: specify
virtio-mmio-bus.4 or .32 respectively rather than .0 on the
destination.
aarch64 xilinx-zynq-a9 usb-bus.0 2
arm xilinx-zynq-a9 usb-bus.0 2
mips64el fulong2e usb-bus.0 2
-> Normal USB operation not affected. Migration driver needs command
line to use the other bus.
i386 isapc ide.0 2
x86_64 isapc ide.0 2
mips mips ide.0 2
mips64 mips ide.0 2
mips64el mips ide.0 2
mipsel mips ide.0 2
ppc g3beige ide.0 2
ppc mac99 ide.0 2
ppc prep ide.0 2
ppc64 g3beige ide.0 2
ppc64 mac99 ide.0 2
ppc64 prep ide.0 2
-> Makes -device bus= work for all IDE buses. Breaks migration.
Workaround for migration from old to new: specify ide.1 rather than
ide.0 on the destination.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Andreas Faerber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-02-06 19:08:15 +04:00
|
|
|
/*
|
|
|
|
* The ide bus name is ide.0 for the first bus and ide.1 for the
|
|
|
|
* second one.
|
|
|
|
*/
|
|
|
|
busname[4] = '0' + i;
|
2024-02-20 19:06:13 +03:00
|
|
|
pcms->idebus[i] = qdev_get_child_bus(DEVICE(dev), busname);
|
2010-05-14 11:29:15 +04:00
|
|
|
}
|
|
|
|
}
|
2019-07-05 17:35:54 +03:00
|
|
|
#endif
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2023-10-07 15:38:21 +03:00
|
|
|
if (piix4_pm) {
|
2015-05-26 04:46:05 +03:00
|
|
|
smi_irq = qemu_allocate_irq(pc_acpi_smi_interrupt, first_cpu, 0);
|
2022-05-28 12:02:11 +03:00
|
|
|
|
2022-05-28 12:02:11 +03:00
|
|
|
qdev_connect_gpio_out_named(DEVICE(piix4_pm), "smi-irq", 0, smi_irq);
|
2022-05-28 12:02:11 +03:00
|
|
|
pcms->smbus = I2C_BUS(qdev_get_child_bus(DEVICE(piix4_pm), "i2c"));
|
2010-05-14 11:29:15 +04:00
|
|
|
/* TODO: Populate SPD eeprom data. */
|
2016-05-13 04:43:45 +03:00
|
|
|
smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
|
2014-06-02 17:25:24 +04:00
|
|
|
|
|
|
|
object_property_add_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
|
|
|
|
TYPE_HOTPLUG_HANDLER,
|
2020-09-15 15:09:02 +03:00
|
|
|
(Object **)&x86ms->acpi_dev,
|
2014-06-02 17:25:24 +04:00
|
|
|
object_property_allow_set_link,
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
OBJ_PROP_LINK_STRONG);
|
qom: Put name parameter before value / visitor parameter
The object_property_set_FOO() setters take property name and value in
an unusual order:
void object_property_set_FOO(Object *obj, FOO_TYPE value,
const char *name, Error **errp)
Having to pass value before name feels grating. Swap them.
Same for object_property_set(), object_property_get(), and
object_property_parse().
Convert callers with this Coccinelle script:
@@
identifier fun = {
object_property_get, object_property_parse, object_property_set_str,
object_property_set_link, object_property_set_bool,
object_property_set_int, object_property_set_uint, object_property_set,
object_property_set_qobject
};
expression obj, v, name, errp;
@@
- fun(obj, v, name, errp)
+ fun(obj, name, v, errp)
Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error
message "no position information". Convert that one manually.
Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by
ARMSSE being used both as typedef and function-like macro there.
Convert manually.
Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused
by RXCPU being used both as typedef and function-like macro there.
Convert manually. The other files using RXCPU that way don't need
conversion.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200707160613.848843-27-armbru@redhat.com>
[Straightforwad conflict with commit 2336172d9b "audio: set default
value for pcspk.iobase property" resolved]
2020-07-07 19:05:54 +03:00
|
|
|
object_property_set_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
|
2023-10-07 15:38:21 +03:00
|
|
|
piix4_pm, &error_abort);
|
2010-05-14 11:29:15 +04:00
|
|
|
}
|
|
|
|
|
2019-03-08 21:20:53 +03:00
|
|
|
if (machine->nvdimms_state->is_enabled) {
|
|
|
|
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
|
2020-04-21 15:59:29 +03:00
|
|
|
x86_nvdimm_acpi_dsmio,
|
2019-10-22 10:39:50 +03:00
|
|
|
x86ms->fw_cfg, OBJECT(pcms));
|
2016-03-04 19:00:32 +03:00
|
|
|
}
|
2010-05-14 11:29:15 +04:00
|
|
|
}
|
|
|
|
|
2023-10-07 15:38:37 +03:00
|
|
|
typedef enum PCSouthBridgeOption {
|
|
|
|
PC_SOUTH_BRIDGE_OPTION_PIIX3,
|
|
|
|
PC_SOUTH_BRIDGE_OPTION_PIIX4,
|
|
|
|
PC_SOUTH_BRIDGE_OPTION_MAX,
|
|
|
|
} PCSouthBridgeOption;
|
|
|
|
|
|
|
|
static const QEnumLookup PCSouthBridgeOption_lookup = {
|
|
|
|
.array = (const char *const[]) {
|
|
|
|
[PC_SOUTH_BRIDGE_OPTION_PIIX3] = TYPE_PIIX3_DEVICE,
|
|
|
|
[PC_SOUTH_BRIDGE_OPTION_PIIX4] = TYPE_PIIX4_PCI_DEVICE,
|
|
|
|
},
|
|
|
|
.size = PC_SOUTH_BRIDGE_OPTION_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
static int pc_get_south_bridge(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
PCMachineState *pcms = PC_MACHINE(obj);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < PCSouthBridgeOption_lookup.size; i++) {
|
|
|
|
if (g_strcmp0(PCSouthBridgeOption_lookup.array[i],
|
|
|
|
pcms->south_bridge) == 0) {
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
error_setg(errp, "Invalid south bridge value set");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pc_set_south_bridge(Object *obj, int value, Error **errp)
|
|
|
|
{
|
|
|
|
PCMachineState *pcms = PC_MACHINE(obj);
|
|
|
|
|
|
|
|
if (value < 0) {
|
|
|
|
error_setg(errp, "Value can't be negative");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value >= PCSouthBridgeOption_lookup.size) {
|
|
|
|
error_setg(errp, "Value too big");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
pcms->south_bridge = PCSouthBridgeOption_lookup.array[value];
|
|
|
|
}
|
|
|
|
|
2022-01-07 19:07:13 +03:00
|
|
|
#ifdef CONFIG_ISAPC
|
2014-05-07 18:42:57 +04:00
|
|
|
static void pc_init_isa(MachineState *machine)
|
2010-05-14 11:29:15 +04:00
|
|
|
{
|
2024-02-28 11:17:40 +03:00
|
|
|
pc_init1(machine, NULL);
|
2010-05-14 11:29:15 +04:00
|
|
|
}
|
2022-01-07 19:07:13 +03:00
|
|
|
#endif
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2010-06-30 15:58:34 +04:00
|
|
|
#ifdef CONFIG_XEN
|
2015-07-15 08:37:49 +03:00
|
|
|
static void pc_xen_hvm_init_pci(MachineState *machine)
|
|
|
|
{
|
2020-06-03 19:04:42 +03:00
|
|
|
const char *pci_type = xen_igd_gfx_pt_enabled() ?
|
2015-07-15 08:37:49 +03:00
|
|
|
TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE;
|
|
|
|
|
2024-02-28 11:16:42 +03:00
|
|
|
pc_init1(machine, pci_type);
|
2015-07-15 08:37:49 +03:00
|
|
|
}
|
|
|
|
|
2014-05-07 18:42:57 +04:00
|
|
|
static void pc_xen_hvm_init(MachineState *machine)
|
2010-06-30 15:58:34 +04:00
|
|
|
{
|
2017-11-29 11:46:28 +03:00
|
|
|
PCMachineState *pcms = PC_MACHINE(machine);
|
2013-06-25 15:46:44 +04:00
|
|
|
|
2015-09-28 23:01:23 +03:00
|
|
|
if (!xen_enabled()) {
|
|
|
|
error_report("xenfv machine requires the xen accelerator");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2015-07-15 08:37:49 +03:00
|
|
|
pc_xen_hvm_init_pci(machine);
|
2024-02-24 16:58:47 +03:00
|
|
|
xen_igd_reserve_slot(pcms->pcibus);
|
|
|
|
pci_create_simple(pcms->pcibus, -1, "xen-platform");
|
2010-06-30 15:58:34 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_init(MachineState *machine)
|
|
|
|
{
|
|
|
|
pc_init1(machine, TYPE_I440FX_PCI_DEVICE);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define DEFINE_I440FX_MACHINE(major, minor) \
|
|
|
|
DEFINE_PC_VER_MACHINE(pc_i440fx, "pc-i440fx", pc_i440fx_init, major, minor);
|
2015-05-15 20:18:54 +03:00
|
|
|
|
2015-05-15 20:18:56 +03:00
|
|
|
static void pc_i440fx_machine_options(MachineClass *m)
|
2015-05-15 20:18:54 +03:00
|
|
|
{
|
2018-03-02 12:29:06 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2023-10-07 15:38:37 +03:00
|
|
|
ObjectClass *oc = OBJECT_CLASS(m);
|
|
|
|
pcmc->default_south_bridge = TYPE_PIIX3_DEVICE;
|
2021-03-01 22:59:18 +03:00
|
|
|
pcmc->pci_root_uid = 0;
|
2022-12-12 18:21:45 +03:00
|
|
|
pcmc->default_cpu_version = 1;
|
2018-03-02 12:29:06 +03:00
|
|
|
|
2015-05-15 20:18:54 +03:00
|
|
|
m->family = "pc_piix";
|
|
|
|
m->desc = "Standard PC (i440FX + PIIX, 1996)";
|
2015-09-11 23:14:24 +03:00
|
|
|
m->default_machine_opts = "firmware=bios-256k.bin";
|
|
|
|
m->default_display = "std";
|
2023-05-10 21:46:21 +03:00
|
|
|
m->default_nic = "e1000";
|
2024-04-25 21:43:15 +03:00
|
|
|
m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
|
2023-05-10 22:30:45 +03:00
|
|
|
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
|
2018-06-13 15:29:46 +03:00
|
|
|
machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
|
2020-04-24 15:34:42 +03:00
|
|
|
machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
|
2023-10-07 15:38:37 +03:00
|
|
|
|
|
|
|
object_class_property_add_enum(oc, "x-south-bridge", "PCSouthBridgeOption",
|
|
|
|
&PCSouthBridgeOption_lookup,
|
|
|
|
pc_get_south_bridge,
|
|
|
|
pc_set_south_bridge);
|
|
|
|
object_class_property_set_description(oc, "x-south-bridge",
|
|
|
|
"Use a different south bridge than PIIX3");
|
2015-05-15 20:18:54 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_9_1_options(MachineClass *m)
|
2015-05-15 20:18:54 +03:00
|
|
|
{
|
|
|
|
pc_i440fx_machine_options(m);
|
|
|
|
m->alias = "pc";
|
2020-02-07 19:19:47 +03:00
|
|
|
m->is_default = true;
|
2015-05-15 20:18:54 +03:00
|
|
|
}
|
2013-12-02 15:47:29 +04:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(9, 1);
|
2024-03-25 17:01:51 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_9_0_options(MachineClass *m)
|
2024-03-25 17:01:51 +03:00
|
|
|
{
|
hw/i386/pc_sysfw: Alias rather than copy isa-bios region
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case, but only
for new machine versions for migration compatibility. This establishes common
behavior and makes pflash commands work in the "isa-bios" region which some
real-world legacy bioses rely on.
Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.
When running `info mtree` before and after this commit with
`qemu-system-x86_64 -S -drive \
if=pflash,format=raw,readonly=on,file=/usr/share/qemu/bios-256k.bin` and running
`diff -u before.mtree after.mtree` results in the following changes in the
memory tree:
--- before.mtree
+++ after.mtree
@@ -71,7 +71,7 @@
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region @pci 00000000000a0000-00000000000bffff
00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 00000000000c0000-00000000000c3fff
00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 00000000000c4000-00000000000c7fff
@@ -108,7 +108,7 @@
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region @pci 00000000000a0000-00000000000bffff
00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 00000000000c0000-00000000000c3fff
00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 00000000000c4000-00000000000c7fff
@@ -131,11 +131,14 @@
memory-region: pc.ram
0000000000000000-0000000007ffffff (prio 0, ram): pc.ram
+memory-region: system.flash0
+ 00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0
+
memory-region: pci
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
memory-region: smram
00000000000a0000-00000000000bffff (prio 0, ram): alias smram-low @pc.ram 00000000000a0000-00000000000bffff
Note that in both cases the "system" memory region contains the entry
00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0
but the "system.flash0" memory region only appears standalone when "isa-bios" is
an alias.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20240508175507.22270-7-shentey@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-08 20:55:07 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_9_1_options(m);
|
2024-03-25 17:01:51 +03:00
|
|
|
m->alias = NULL;
|
|
|
|
m->is_default = false;
|
smbios: make memory device size configurable per Machine
Currently QEMU describes initial[1] RAM* in SMBIOS as a series of
virtual DIMMs (capped at 16Gb max) using type 17 structure entries.
Which is fine for the most cases. However when starting guest
with terabytes of RAM this leads to too many memory device
structures, which eventually upsets linux kernel as it reserves
only 64K for these entries and when that border is crossed out
it runs out of reserved memory.
Instead of partitioning initial RAM on 16Gb DIMMs, use maximum
possible chunk size that SMBIOS spec allows[2]. Which lets
encode RAM in lower 31 bits of 32bit field (which amounts upto
2047Tb per DIMM).
As result initial RAM will generate only one type 17 structure
until host/guest reach ability to use more RAM in the future.
Compat changes:
We can't unconditionally change chunk size as it will break
QEMU<->guest ABI (and migration). Thus introduce a new machine
class field that would let older versioned machines to use
legacy 16Gb chunks, while new(er) machine type[s] use maximum
possible chunk size.
PS:
While it might seem to be risky to rise max entry size this large
(much beyond of what current physical RAM modules support),
I'd not expect it causing much issues, modulo uncovering bugs
in software running within guest. And those should be fixed
on guest side to handle SMBIOS spec properly, especially if
guest is expected to support so huge RAM configs.
In worst case, QEMU can reduce chunk size later if we would
care enough about introducing a workaround for some 'unfixable'
guest OS, either by fixing up the next machine type or
giving users a CLI option to customize it.
1) Initial RAM - is RAM configured with help '-m SIZE' CLI option/
implicitly defined by machine. It doesn't include memory
configured with help of '-device' option[s] (pcdimm,nvdimm,...)
2) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size
PS:
* tested on 8Tb host with RHEL6 guest, which seems to parse
type 17 SMBIOS table entries correctly (according to 'dmidecode').
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20240715122417.4059293-1-imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-15 15:24:17 +03:00
|
|
|
m->smbios_memory_device_size = 16 * GiB;
|
2024-03-25 17:01:51 +03:00
|
|
|
|
|
|
|
compat_props_add(m->compat_props, hw_compat_9_0, hw_compat_9_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_9_0, pc_compat_9_0_len);
|
hw/i386/pc_sysfw: Alias rather than copy isa-bios region
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case, but only
for new machine versions for migration compatibility. This establishes common
behavior and makes pflash commands work in the "isa-bios" region which some
real-world legacy bioses rely on.
Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.
When running `info mtree` before and after this commit with
`qemu-system-x86_64 -S -drive \
if=pflash,format=raw,readonly=on,file=/usr/share/qemu/bios-256k.bin` and running
`diff -u before.mtree after.mtree` results in the following changes in the
memory tree:
--- before.mtree
+++ after.mtree
@@ -71,7 +71,7 @@
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region @pci 00000000000a0000-00000000000bffff
00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 00000000000c0000-00000000000c3fff
00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 00000000000c4000-00000000000c7fff
@@ -108,7 +108,7 @@
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
00000000000a0000-00000000000bffff (prio 1, i/o): alias smram-region @pci 00000000000a0000-00000000000bffff
00000000000c0000-00000000000c3fff (prio 1, i/o): alias pam-pci @pci 00000000000c0000-00000000000c3fff
00000000000c4000-00000000000c7fff (prio 1, i/o): alias pam-pci @pci 00000000000c4000-00000000000c7fff
@@ -131,11 +131,14 @@
memory-region: pc.ram
0000000000000000-0000000007ffffff (prio 0, ram): pc.ram
+memory-region: system.flash0
+ 00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0
+
memory-region: pci
0000000000000000-ffffffffffffffff (prio -1, i/o): pci
00000000000a0000-00000000000bffff (prio 1, i/o): vga-lowmem
00000000000c0000-00000000000dffff (prio 1, rom): pc.rom
- 00000000000e0000-00000000000fffff (prio 1, rom): isa-bios
+ 00000000000e0000-00000000000fffff (prio 1, romd): alias isa-bios @system.flash0 0000000000020000-000000000003ffff
memory-region: smram
00000000000a0000-00000000000bffff (prio 0, ram): alias smram-low @pc.ram 00000000000a0000-00000000000bffff
Note that in both cases the "system" memory region contains the entry
00000000fffc0000-00000000ffffffff (prio 0, romd): system.flash0
but the "system.flash0" memory region only appears standalone when "isa-bios" is
an alias.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Message-ID: <20240508175507.22270-7-shentey@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-05-08 20:55:07 +03:00
|
|
|
pcmc->isa_bios_alias = false;
|
2024-03-25 17:01:51 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(9, 0);
|
2023-11-20 12:42:59 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_8_2_options(MachineClass *m)
|
2023-11-20 12:42:59 +03:00
|
|
|
{
|
2024-03-14 18:23:00 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_9_0_options(m);
|
2023-11-20 12:42:59 +03:00
|
|
|
|
|
|
|
compat_props_add(m->compat_props, hw_compat_8_2, hw_compat_8_2_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_8_2, pc_compat_8_2_len);
|
2024-03-14 18:23:00 +03:00
|
|
|
/* For pc-i44fx-8.2 and 8.1, use SMBIOS 3.X by default */
|
|
|
|
pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64;
|
2023-11-20 12:42:59 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(8, 2);
|
2023-07-18 17:22:35 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_8_1_options(MachineClass *m)
|
2023-07-18 17:22:35 +03:00
|
|
|
{
|
hw/i386/pc: improve physical address space bound check for 32-bit x86 systems
32-bit x86 systems do not have a reserved memory for hole64. On those 32-bit
systems without PSE36 or PAE CPU features, hotplugging memory devices are not
supported by QEMU as QEMU always places hotplugged memory above 4 GiB boundary
which is beyond the physical address space of the processor. Linux guests also
does not support memory hotplug on those systems. Please see Linux
kernel commit b59d02ed08690 ("mm/memory_hotplug: disable the functionality
for 32b") for more details.
Therefore, the maximum limit of the guest physical address in the absence of
additional memory devices effectively coincides with the end of
"above 4G memory space" region for 32-bit x86 without PAE/PSE36. When users
configure additional memory devices, after properly accounting for the
additional device memory region to find the maximum value of the guest
physical address, the address will be outside the range of the processor's
physical address space.
This change adds improvements to take above into consideration.
For example, previously this was allowed:
$ ./qemu-system-x86_64 -cpu pentium -m size=10G
With this change now it is no longer allowed:
$ ./qemu-system-x86_64 -cpu pentium -m size=10G
qemu-system-x86_64: Address space limit 0xffffffff < 0x2bfffffff phys-bits too low (32)
However, the following are allowed since on both cases physical address
space of the processor is 36 bits:
$ ./qemu-system-x86_64 -cpu pentium2 -m size=10G
$ ./qemu-system-x86_64 -cpu pentium,pse36=on -m size=10G
For 32-bit, without PAE/PSE36, hotplugging additional memory is no longer allowed.
$ ./qemu-system-i386 -m size=1G,maxmem=3G,slots=2
qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32)
$ ./qemu-system-i386 -machine q35 -m size=1G,maxmem=3G,slots=2
qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32)
A new compatibility flag is introduced to make sure pc_max_used_gpa() keeps
returning the old value for machines 8.1 and older.
Therefore, the above is still allowed for older machine types in order to support
compatibility. Hence, the following still works:
$ ./qemu-system-i386 -machine pc-i440fx-8.1 -m size=1G,maxmem=3G,slots=2
$ ./qemu-system-i386 -machine pc-q35-8.1 -m size=1G,maxmem=3G,slots=2
Further, following is also allowed as with PSE36, the processor has 36-bit
address space:
$ ./qemu-system-i386 -cpu 486,pse36=on -m size=1G,maxmem=3G,slots=2
After calling CPUID with EAX=0x80000001, all AMD64 compliant processors
have the longmode-capable-bit turned on in the extended feature flags (bit 29)
in EDX. The absence of CPUID longmode can be used to differentiate between
32-bit and 64-bit processors and is the recommended approach. QEMU takes this
approach elsewhere (for example, please see x86_cpu_realizefn()), With
this change, pc_max_used_gpa() also uses the same method to detect 32-bit
processors.
Unit tests are modified to not run 32-bit x86 tests that use memory hotplug.
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230922160413.165702-1-anisinha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-09-22 19:04:13 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_8_2_options(m);
|
hw/i386/pc: improve physical address space bound check for 32-bit x86 systems
32-bit x86 systems do not have a reserved memory for hole64. On those 32-bit
systems without PSE36 or PAE CPU features, hotplugging memory devices are not
supported by QEMU as QEMU always places hotplugged memory above 4 GiB boundary
which is beyond the physical address space of the processor. Linux guests also
does not support memory hotplug on those systems. Please see Linux
kernel commit b59d02ed08690 ("mm/memory_hotplug: disable the functionality
for 32b") for more details.
Therefore, the maximum limit of the guest physical address in the absence of
additional memory devices effectively coincides with the end of
"above 4G memory space" region for 32-bit x86 without PAE/PSE36. When users
configure additional memory devices, after properly accounting for the
additional device memory region to find the maximum value of the guest
physical address, the address will be outside the range of the processor's
physical address space.
This change adds improvements to take above into consideration.
For example, previously this was allowed:
$ ./qemu-system-x86_64 -cpu pentium -m size=10G
With this change now it is no longer allowed:
$ ./qemu-system-x86_64 -cpu pentium -m size=10G
qemu-system-x86_64: Address space limit 0xffffffff < 0x2bfffffff phys-bits too low (32)
However, the following are allowed since on both cases physical address
space of the processor is 36 bits:
$ ./qemu-system-x86_64 -cpu pentium2 -m size=10G
$ ./qemu-system-x86_64 -cpu pentium,pse36=on -m size=10G
For 32-bit, without PAE/PSE36, hotplugging additional memory is no longer allowed.
$ ./qemu-system-i386 -m size=1G,maxmem=3G,slots=2
qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32)
$ ./qemu-system-i386 -machine q35 -m size=1G,maxmem=3G,slots=2
qemu-system-i386: Address space limit 0xffffffff < 0x1ffffffff phys-bits too low (32)
A new compatibility flag is introduced to make sure pc_max_used_gpa() keeps
returning the old value for machines 8.1 and older.
Therefore, the above is still allowed for older machine types in order to support
compatibility. Hence, the following still works:
$ ./qemu-system-i386 -machine pc-i440fx-8.1 -m size=1G,maxmem=3G,slots=2
$ ./qemu-system-i386 -machine pc-q35-8.1 -m size=1G,maxmem=3G,slots=2
Further, following is also allowed as with PSE36, the processor has 36-bit
address space:
$ ./qemu-system-i386 -cpu 486,pse36=on -m size=1G,maxmem=3G,slots=2
After calling CPUID with EAX=0x80000001, all AMD64 compliant processors
have the longmode-capable-bit turned on in the extended feature flags (bit 29)
in EDX. The absence of CPUID longmode can be used to differentiate between
32-bit and 64-bit processors and is the recommended approach. QEMU takes this
approach elsewhere (for example, please see x86_cpu_realizefn()), With
this change, pc_max_used_gpa() also uses the same method to detect 32-bit
processors.
Unit tests are modified to not run 32-bit x86 tests that use memory hotplug.
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20230922160413.165702-1-anisinha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-09-22 19:04:13 +03:00
|
|
|
pcmc->broken_32bit_mem_addr_check = true;
|
|
|
|
|
2023-07-18 17:22:35 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_8_1, hw_compat_8_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_8_1, pc_compat_8_1_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(8, 1);
|
2023-03-14 20:30:09 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_8_0_options(MachineClass *m)
|
2023-03-14 20:30:09 +03:00
|
|
|
{
|
2023-06-07 23:57:16 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_8_1_options(m);
|
2023-03-14 20:30:09 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_8_0, hw_compat_8_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_8_0, pc_compat_8_0_len);
|
2023-06-07 23:57:16 +03:00
|
|
|
|
|
|
|
/* For pc-i44fx-8.0 and older, use SMBIOS 2.8 by default */
|
|
|
|
pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_32;
|
2023-03-14 20:30:09 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(8, 0);
|
2022-12-12 18:21:44 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_7_2_options(MachineClass *m)
|
2022-12-12 18:21:44 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_8_0_options(m);
|
2022-12-12 18:21:44 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_7_2, hw_compat_7_2_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_7_2, pc_compat_7_2_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(7, 2)
|
2022-07-27 15:17:55 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_7_1_options(MachineClass *m)
|
2022-07-27 15:17:55 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_7_2_options(m);
|
2022-07-27 15:17:55 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_7_1, hw_compat_7_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_7_1, pc_compat_7_1_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(7, 1);
|
2022-03-16 17:55:21 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_7_0_options(MachineClass *m)
|
2022-03-16 17:55:21 +03:00
|
|
|
{
|
2022-07-21 15:56:36 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_7_1_options(m);
|
2022-07-19 20:00:14 +03:00
|
|
|
pcmc->enforce_amd_1tb_hole = false;
|
2022-03-16 17:55:21 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(7, 0);
|
2021-12-17 17:39:48 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_6_2_options(MachineClass *m)
|
2021-12-17 17:39:48 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_7_0_options(m);
|
2021-12-17 17:39:48 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_6_2, hw_compat_6_2_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_6_2, pc_compat_6_2_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(6, 2);
|
2021-08-31 04:54:26 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_6_1_options(MachineClass *m)
|
2021-08-31 04:54:26 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_6_2_options(m);
|
2021-08-31 04:54:26 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_6_1, hw_compat_6_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_6_1, pc_compat_6_1_len);
|
2021-09-29 05:58:14 +03:00
|
|
|
m->smp_props.prefer_sockets = true;
|
2021-08-31 04:54:26 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(6, 1);
|
2021-03-31 14:19:00 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_6_0_options(MachineClass *m)
|
2021-03-31 14:19:00 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_6_1_options(m);
|
2021-03-31 14:19:00 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_6_0, hw_compat_6_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_6_0, pc_compat_6_0_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(6, 0);
|
2020-11-09 20:39:28 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_5_2_options(MachineClass *m)
|
2020-11-09 20:39:28 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_6_0_options(m);
|
2020-11-09 20:39:28 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_5_2, hw_compat_5_2_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_5_2, pc_compat_5_2_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(5, 2);
|
2020-08-19 17:40:16 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_5_1_options(MachineClass *m)
|
2020-08-19 17:40:16 +03:00
|
|
|
{
|
2020-09-22 18:19:34 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_5_2_options(m);
|
2020-08-19 17:40:16 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_5_1, hw_compat_5_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_5_1, pc_compat_5_1_len);
|
2020-09-22 18:19:34 +03:00
|
|
|
pcmc->kvmclock_create_always = false;
|
2021-03-01 22:59:18 +03:00
|
|
|
pcmc->pci_root_uid = 1;
|
2020-08-19 17:40:16 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(5, 1);
|
2020-04-29 17:46:05 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_5_0_options(MachineClass *m)
|
2020-04-29 17:46:05 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_5_1_options(m);
|
2020-06-09 16:56:35 +03:00
|
|
|
m->numa_mem_supported = true;
|
2020-04-29 17:46:05 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_5_0, hw_compat_5_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_5_0, pc_compat_5_0_len);
|
2020-06-26 10:22:48 +03:00
|
|
|
m->auto_enable_numa_with_memdev = false;
|
2020-04-29 17:46:05 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(5, 0);
|
2019-11-12 13:48:11 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_4_2_options(MachineClass *m)
|
2019-11-12 13:48:11 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_5_0_options(m);
|
2019-11-12 13:48:11 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_4_2, pc_compat_4_2_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(4, 2);
|
2019-07-24 13:35:24 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_4_1_options(MachineClass *m)
|
2019-07-24 13:35:24 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_4_2_options(m);
|
2019-07-24 13:35:24 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_4_1, hw_compat_4_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_4_1, pc_compat_4_1_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(4, 1);
|
2019-04-11 13:20:25 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_4_0_options(MachineClass *m)
|
2019-04-11 13:20:25 +03:00
|
|
|
{
|
2019-06-28 03:28:42 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_4_1_options(m);
|
2019-06-28 03:28:42 +03:00
|
|
|
pcmc->default_cpu_version = CPU_VERSION_LEGACY;
|
2019-04-11 13:20:25 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_4_0, hw_compat_4_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_4_0, pc_compat_4_0_len);
|
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(4, 0);
|
2018-12-04 19:27:16 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_3_1_options(MachineClass *m)
|
2018-12-04 19:27:16 +03:00
|
|
|
{
|
2019-01-22 15:10:48 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_4_0_options(m);
|
2018-11-14 23:41:01 +03:00
|
|
|
m->smbus_no_migration_support = true;
|
2019-01-22 15:10:48 +03:00
|
|
|
pcmc->pvh_enabled = false;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_3_1, hw_compat_3_1_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_3_1, pc_compat_3_1_len);
|
2018-12-04 19:27:16 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(3, 1);
|
2018-11-20 16:26:04 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_3_0_options(MachineClass *m)
|
2018-11-20 16:26:04 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_3_1_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_3_0, hw_compat_3_0_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_3_0, pc_compat_3_0_len);
|
2018-11-20 16:26:04 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(3, 0);
|
2018-05-14 19:41:50 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_12_options(MachineClass *m)
|
2018-05-14 19:41:50 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_3_0_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
|
2018-05-14 19:41:50 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 12);
|
2017-12-19 06:37:29 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_11_options(MachineClass *m)
|
2017-12-19 06:37:29 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_12_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_11, hw_compat_2_11_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_11, pc_compat_2_11_len);
|
2017-12-19 06:37:29 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 11);
|
2017-09-06 17:26:57 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_10_options(MachineClass *m)
|
2017-09-06 17:26:57 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_11_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_10, hw_compat_2_10_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_10, pc_compat_2_10_len);
|
2017-11-14 05:34:01 +03:00
|
|
|
m->auto_enable_numa_with_memhp = false;
|
2017-09-06 17:26:57 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 10);
|
2017-04-25 12:49:13 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_9_options(MachineClass *m)
|
2017-04-25 12:49:13 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_10_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_9, hw_compat_2_9_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_9, pc_compat_2_9_len);
|
2017-04-25 12:49:13 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 9);
|
2017-01-12 21:24:16 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_8_options(MachineClass *m)
|
2017-01-12 21:24:16 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_9_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_8, hw_compat_2_8_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_8, pc_compat_2_8_len);
|
2017-01-12 21:24:16 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 8);
|
2016-09-07 08:21:12 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_7_options(MachineClass *m)
|
2016-09-07 08:21:12 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_8_options(m);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_7, hw_compat_2_7_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_7, pc_compat_2_7_len);
|
2016-09-07 08:21:12 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 7);
|
2016-05-17 17:43:10 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_6_options(MachineClass *m)
|
2016-05-17 17:43:10 +03:00
|
|
|
{
|
2021-10-20 15:48:10 +03:00
|
|
|
X86MachineClass *x86mc = X86_MACHINE_CLASS(m);
|
2016-06-15 12:25:23 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2018-12-12 17:01:23 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_7_options(m);
|
2016-06-15 12:25:23 +03:00
|
|
|
pcmc->legacy_cpu_hotplug = true;
|
2021-10-20 15:48:10 +03:00
|
|
|
x86mc->fwcfg_dma_enabled = false;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_6, hw_compat_2_6_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_6, pc_compat_2_6_len);
|
2016-05-17 17:43:10 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 6);
|
2015-11-30 17:56:36 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_5_options(MachineClass *m)
|
2015-11-30 17:56:36 +03:00
|
|
|
{
|
2019-11-18 14:13:25 +03:00
|
|
|
X86MachineClass *x86mc = X86_MACHINE_CLASS(m);
|
2018-12-12 17:01:23 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_6_options(m);
|
2019-11-18 14:13:25 +03:00
|
|
|
x86mc->save_tsc_khz = false;
|
2016-04-07 17:12:58 +03:00
|
|
|
m->legacy_fw_cfg_order = 1;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_5, hw_compat_2_5_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_5, pc_compat_2_5_len);
|
2015-11-30 17:56:36 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 5);
|
2015-09-11 23:14:25 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void pc_i440fx_machine_2_4_options(MachineClass *m)
|
2015-09-11 23:14:25 +03:00
|
|
|
{
|
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2018-12-12 17:01:23 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_2_5_options(m);
|
2015-10-30 22:36:07 +03:00
|
|
|
m->hw_version = "2.4.0";
|
2015-09-11 23:14:25 +03:00
|
|
|
pcmc->broken_reserved_end = true;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(m->compat_props, hw_compat_2_4, hw_compat_2_4_len);
|
|
|
|
compat_props_add(m->compat_props, pc_compat_2_4, pc_compat_2_4_len);
|
2015-09-11 23:14:25 +03:00
|
|
|
}
|
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
DEFINE_I440FX_MACHINE(2, 4);
|
2015-04-23 09:21:35 +03:00
|
|
|
|
2022-01-07 19:07:13 +03:00
|
|
|
#ifdef CONFIG_ISAPC
|
2015-05-15 20:18:56 +03:00
|
|
|
static void isapc_machine_options(MachineClass *m)
|
2015-05-15 20:18:54 +03:00
|
|
|
{
|
2015-12-02 01:58:03 +03:00
|
|
|
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
|
2015-05-15 20:18:54 +03:00
|
|
|
m->desc = "ISA-only PC";
|
|
|
|
m->max_cpus = 1;
|
2015-12-02 01:58:08 +03:00
|
|
|
m->option_rom_has_mr = true;
|
|
|
|
m->rom_file_has_mr = false;
|
2015-12-02 01:58:03 +03:00
|
|
|
pcmc->pci_enabled = false;
|
|
|
|
pcmc->has_acpi_build = false;
|
|
|
|
pcmc->smbios_defaults = false;
|
|
|
|
pcmc->gigabyte_align = false;
|
|
|
|
pcmc->smbios_legacy_mode = true;
|
|
|
|
pcmc->has_reserved_memory = false;
|
2023-05-10 21:46:21 +03:00
|
|
|
m->default_nic = "ne2k_isa";
|
2017-09-13 19:04:56 +03:00
|
|
|
m->default_cpu_type = X86_CPU_TYPE_NAME("486");
|
2024-04-25 21:43:15 +03:00
|
|
|
m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
|
2023-05-10 22:30:45 +03:00
|
|
|
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
|
2015-05-15 20:18:54 +03:00
|
|
|
}
|
pc: Define MACHINE_OPTIONS macros consistently for all machines
Define a MACHINE_OPTIONS macro for each PC machine, and move every field
inside the QEMUMachine structs to the macros, except for name, init, and
compat_props.
This also ensures that all MACHINE_OPTIONS inherit the fields from the
next version, so their definitions carry only the changes that exist
between one version and the next one.
Comments about specific cases:
pc-*-2.1:
Existing PC_*_2_1_MACHINE_OPTIONS macros were defined as:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin"
PC_*_2_2_MACHINE_OPTIONS is:
PC_*_2_3_MACHINE_OPTIONS
which is expanded to:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin",
.default_display = "std"
The only difference between 2_1 and 2_2 is .default_display, that's why
we didn't reuse PC_*_2_2_MACHINE_OPTIONS. The good news is that having
multiple initializers for a field is allowed by C99, and the last
initializer overrides the previous ones.
So we can reuse the 2_2 macro in 2_1 and define PC_*_2_1_MACHINE_OPTIONS
as:
PC_*_2_2_MACHINE_OPTIONS,
.default_display = NULL
pc-*-1.7:
PC_*_1_7_MACHINE_OPTIONS was defined as:
PC_*_MACHINE_OPTIONS
PC_*_2_0_MACHINE_OPTIONS is defined as:
PC_*_2_1_MACHINE_OPTIONS
which is expanded to:
PC_*_2_2_MACHINE_OPTIONS,
.default_display = NULL
which is expanded to:
PC_*_2_3_MACHINE_OPTIONS,
.default_display = NULL
which is expanded to:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin",
.default_display = "std",
.default_display = NULL /* overrides the previous line */
So, the only difference between PC_*_1_7_MACHINE_OPTIONS and
PC_*_2_0_MACHINE_OPTIONS is .default_machine_opts (as .default_display
is not explicitly set by PC_*_MACHINE_OPTIONS so it is NULL).
So we can keep the macro reuse pattern and define
PC_*_2_0_MACHINE_OPTIONS as:
PC_*_2_0_MACHINE_OPTIONS,
.default_machine_opts = NULL
pc-*-2.4 (alias and is_default fields):
Set alias and is_default fields inside the 2.4 MACHINE_OPTIONS macro,
and clear it in the 2.3 macro (that reuses the 2.4 macro).
hw_machine:
As all the machines older than v1.0 set hw_version explicitly, we can
safely move the field to the MACHINE_OPTIONS macros without affecting
the other versions that reuse them.
init function:
Some machines had the init function set inside the MACHINE_OPTIONS
macro. Move it to the QEMUMachine declaration, to keep it consistent
with the other machines.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-15 20:18:52 +03:00
|
|
|
|
2015-05-15 20:18:53 +03:00
|
|
|
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
|
2015-05-15 20:18:55 +03:00
|
|
|
isapc_machine_options);
|
2022-01-07 19:07:13 +03:00
|
|
|
#endif
|
2010-05-14 11:29:15 +04:00
|
|
|
|
2010-06-30 15:58:34 +04:00
|
|
|
#ifdef CONFIG_XEN
|
2024-06-20 19:57:34 +03:00
|
|
|
static void xenfv_machine_4_2_options(MachineClass *m)
|
2015-05-15 20:18:54 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_4_2_options(m);
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
m->desc = "Xen Fully-virtualized PC";
|
|
|
|
m->max_cpus = HVM_MAX_VCPUS;
|
2020-10-13 22:05:06 +03:00
|
|
|
m->default_machine_opts = "accel=xen,suppress-vmdesc=on";
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_PC_MACHINE(xenfv_4_2, "xenfv-4.2", pc_xen_hvm_init,
|
2024-06-20 19:57:34 +03:00
|
|
|
xenfv_machine_4_2_options);
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
|
2024-06-20 19:57:34 +03:00
|
|
|
static void xenfv_machine_3_1_options(MachineClass *m)
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
{
|
2024-06-20 19:57:34 +03:00
|
|
|
pc_i440fx_machine_3_1_options(m);
|
2015-05-15 20:18:54 +03:00
|
|
|
m->desc = "Xen Fully-virtualized PC";
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
m->alias = "xenfv";
|
2015-05-15 20:18:54 +03:00
|
|
|
m->max_cpus = HVM_MAX_VCPUS;
|
2020-10-13 22:05:06 +03:00
|
|
|
m->default_machine_opts = "accel=xen,suppress-vmdesc=on";
|
2015-05-15 20:18:54 +03:00
|
|
|
}
|
pc: Define MACHINE_OPTIONS macros consistently for all machines
Define a MACHINE_OPTIONS macro for each PC machine, and move every field
inside the QEMUMachine structs to the macros, except for name, init, and
compat_props.
This also ensures that all MACHINE_OPTIONS inherit the fields from the
next version, so their definitions carry only the changes that exist
between one version and the next one.
Comments about specific cases:
pc-*-2.1:
Existing PC_*_2_1_MACHINE_OPTIONS macros were defined as:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin"
PC_*_2_2_MACHINE_OPTIONS is:
PC_*_2_3_MACHINE_OPTIONS
which is expanded to:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin",
.default_display = "std"
The only difference between 2_1 and 2_2 is .default_display, that's why
we didn't reuse PC_*_2_2_MACHINE_OPTIONS. The good news is that having
multiple initializers for a field is allowed by C99, and the last
initializer overrides the previous ones.
So we can reuse the 2_2 macro in 2_1 and define PC_*_2_1_MACHINE_OPTIONS
as:
PC_*_2_2_MACHINE_OPTIONS,
.default_display = NULL
pc-*-1.7:
PC_*_1_7_MACHINE_OPTIONS was defined as:
PC_*_MACHINE_OPTIONS
PC_*_2_0_MACHINE_OPTIONS is defined as:
PC_*_2_1_MACHINE_OPTIONS
which is expanded to:
PC_*_2_2_MACHINE_OPTIONS,
.default_display = NULL
which is expanded to:
PC_*_2_3_MACHINE_OPTIONS,
.default_display = NULL
which is expanded to:
PC_*_MACHINE_OPTIONS,
.default_machine_opts = "firmware=bios-256k.bin",
.default_display = "std",
.default_display = NULL /* overrides the previous line */
So, the only difference between PC_*_1_7_MACHINE_OPTIONS and
PC_*_2_0_MACHINE_OPTIONS is .default_machine_opts (as .default_display
is not explicitly set by PC_*_MACHINE_OPTIONS so it is NULL).
So we can keep the macro reuse pattern and define
PC_*_2_0_MACHINE_OPTIONS as:
PC_*_2_0_MACHINE_OPTIONS,
.default_machine_opts = NULL
pc-*-2.4 (alias and is_default fields):
Set alias and is_default fields inside the 2.4 MACHINE_OPTIONS macro,
and clear it in the 2.3 macro (that reuses the 2.4 macro).
hw_machine:
As all the machines older than v1.0 set hw_version explicitly, we can
safely move the field to the MACHINE_OPTIONS macros without affecting
the other versions that reuse them.
init function:
Some machines had the init function set inside the MACHINE_OPTIONS
macro. Move it to the QEMUMachine declaration, to keep it consistent
with the other machines.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-05-15 20:18:52 +03:00
|
|
|
|
piix: fix xenfv regression, add compat machine xenfv-4.2
With QEMU 4.0 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-4.2' must be added
which targets domUs started with qemu 4.2. The existing 'xenfv' restores
compatibility of QEMU 5.x with qemu 3.1.
Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2)
have to use a wrapper script which appends '-machine xenfv-4.2' to
the device-model command line. This is only required if there is no
maintenance window which allows to temporary shutdown the domU and
restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the <emulator> element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
<emulator> element to point it to the wrapper script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20200327151841.13877-1-olaf@aepfle.de>
[Adjust tests for blacklisted machine types, simplifying the one in
qom-test. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-27 18:18:40 +03:00
|
|
|
DEFINE_PC_MACHINE(xenfv, "xenfv-3.1", pc_xen_hvm_init,
|
2024-06-20 19:57:34 +03:00
|
|
|
xenfv_machine_3_1_options);
|
2010-06-30 15:58:34 +04:00
|
|
|
#endif
|