qemu/hw/i386/pc_q35.c

563 lines
19 KiB
C
Raw Normal View History

/*
* Q35 chipset based pc system emulator
*
* Copyright (c) 2003-2004 Fabrice Bellard
* Copyright (c) 2009, 2010
* Isaku Yamahata <yamahata at valinux co jp>
* VA Linux Systems Japan K.K.
* Copyright (C) 2012 Jason Baron <jbaron@redhat.com>
*
* This is based on pc.c, but heavily modified.
*
* 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.
*/
#include "qemu/osdep.h"
#include "qemu/units.h"
#include "hw/loader.h"
#include "sysemu/arch_init.h"
#include "hw/i2c/smbus_eeprom.h"
#include "hw/rtc/mc146818rtc.h"
#include "hw/xen/xen.h"
#include "sysemu/kvm.h"
#include "hw/kvm/clock.h"
#include "hw/pci-host/q35.h"
#include "hw/qdev-properties.h"
#include "exec/address-spaces.h"
#include "hw/i386/x86.h"
#include "hw/i386/pc.h"
#include "hw/i386/ich9.h"
#include "hw/i386/amd_iommu.h"
#include "hw/i386/intel_iommu.h"
#include "hw/display/ramfb.h"
#include "hw/firmware/smbios.h"
#include "hw/ide/pci.h"
#include "hw/ide/ahci.h"
#include "hw/usb.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
numa: equally distribute memory on nodes When there are more nodes than available memory to put the minimum allowed memory by node, all the memory is put on the last node. This is because we put (ram_size / nb_numa_nodes) & ~((1 << mc->numa_mem_align_shift) - 1); on each node, and in this case the value is 0. This is particularly true with pseries, as the memory must be aligned to 256MB. To avoid this problem, this patch uses an error diffusion algorithm [1] to distribute equally the memory on nodes. We introduce numa_auto_assign_ram() function in MachineClass to keep compatibility between machine type versions. The legacy function is used with pseries-2.9, pc-q35-2.9 and pc-i440fx-2.9 (and previous), the new one with all others. Example: qemu-system-ppc64 -S -nographic -nodefaults -monitor stdio -m 1G -smp 8 \ -numa node -numa node -numa node \ -numa node -numa node -numa node Before: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 0 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 0 MB node 4 cpus: 4 node 4 size: 0 MB node 5 cpus: 5 node 5 size: 1024 MB After: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 256 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 256 MB node 4 cpus: 4 node 4 size: 256 MB node 5 cpus: 5 node 5 size: 256 MB [1] https://en.wikipedia.org/wiki/Error_diffusion Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20170502162955.1610-2-lvivier@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> [ehabkost: s/ram_size/size/ at numa_default_auto_assign_ram()] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-02 19:29:55 +03:00
#include "sysemu/numa.h"
#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"
#include "hw/i386/acpi-build.h"
/* ICH9 AHCI has 6 ports */
#define MAX_SATA_PORTS 6
struct ehci_companions {
const char *name;
int func;
int port;
};
static const struct ehci_companions ich9_1d[] = {
{ .name = "ich9-usb-uhci1", .func = 0, .port = 0 },
{ .name = "ich9-usb-uhci2", .func = 1, .port = 2 },
{ .name = "ich9-usb-uhci3", .func = 2, .port = 4 },
};
static const struct ehci_companions ich9_1a[] = {
{ .name = "ich9-usb-uhci4", .func = 0, .port = 0 },
{ .name = "ich9-usb-uhci5", .func = 1, .port = 2 },
{ .name = "ich9-usb-uhci6", .func = 2, .port = 4 },
};
static int ehci_create_ich9_with_companions(PCIBus *bus, int slot)
{
const struct ehci_companions *comp;
PCIDevice *ehci, *uhci;
BusState *usbbus;
const char *name;
int i;
switch (slot) {
case 0x1d:
name = "ich9-usb-ehci1";
comp = ich9_1d;
break;
case 0x1a:
name = "ich9-usb-ehci2";
comp = ich9_1a;
break;
default:
return -1;
}
ehci = pci_create_multifunction(bus, PCI_DEVFN(slot, 7), true, name);
qdev_init_nofail(&ehci->qdev);
usbbus = QLIST_FIRST(&ehci->qdev.child_bus);
for (i = 0; i < 3; i++) {
uhci = pci_create_multifunction(bus, PCI_DEVFN(slot, comp[i].func),
true, comp[i].name);
qdev_prop_set_string(&uhci->qdev, "masterbus", usbbus->name);
qdev_prop_set_uint32(&uhci->qdev, "firstport", comp[i].port);
qdev_init_nofail(&uhci->qdev);
}
return 0;
}
/* PC hardware initialisation */
static void pc_q35_init(MachineState *machine)
{
PCMachineState *pcms = PC_MACHINE(machine);
PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
X86MachineState *x86ms = X86_MACHINE(machine);
Q35PCIHost *q35_host;
PCIHostState *phb;
PCIBus *host_bus;
PCIDevice *lpc;
DeviceState *lpc_dev;
BusState *idebus[MAX_SATA_PORTS];
ISADevice *rtc_state;
MemoryRegion *system_io = get_system_io();
MemoryRegion *pci_memory;
MemoryRegion *rom_memory;
MemoryRegion *ram_memory;
GSIState *gsi_state;
ISABus *isa_bus;
int i;
ICH9LPCState *ich9_lpc;
PCIDevice *ahci;
ram_addr_t lowmem;
DriveInfo *hd[MAX_SATA_PORTS];
MachineClass *mc = MACHINE_GET_CLASS(machine);
/* Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory
* and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping
* also known as MMCFG).
* If it doesn't, we need to split it in chunks below and above 4G.
* In any case, try to make sure that guest addresses aligned at
* 1G boundaries get mapped to host addresses aligned at 1G boundaries.
*/
if (machine->ram_size >= 0xb0000000) {
lowmem = 0x80000000;
} else {
lowmem = 0xb0000000;
}
/* Handle the machine opt max-ram-below-4g. It is basically doing
* min(qemu limit, user limit).
*/
if (!x86ms->max_ram_below_4g) {
x86ms->max_ram_below_4g = 4 * GiB;
}
if (lowmem > x86ms->max_ram_below_4g) {
lowmem = x86ms->max_ram_below_4g;
if (machine->ram_size - lowmem > lowmem &&
lowmem & (1 * GiB - 1)) {
warn_report("There is possibly poor performance as the ram size "
" (0x%" PRIx64 ") is more then twice the size of"
" max-ram-below-4g (%"PRIu64") and"
" max-ram-below-4g is not a multiple of 1G.",
(uint64_t)machine->ram_size, x86ms->max_ram_below_4g);
}
}
if (machine->ram_size >= lowmem) {
x86ms->above_4g_mem_size = machine->ram_size - lowmem;
x86ms->below_4g_mem_size = lowmem;
} else {
x86ms->above_4g_mem_size = 0;
x86ms->below_4g_mem_size = machine->ram_size;
}
if (xen_enabled()) {
xen_hvm_init(pcms, &ram_memory);
}
x86_cpus_init(x86ms, pcmc->default_cpu_version);
kvmclock_create();
/* pci enabled */
if (pcmc->pci_enabled) {
pci_memory = g_new(MemoryRegion, 1);
memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
rom_memory = pci_memory;
} else {
pci_memory = NULL;
rom_memory = get_system_memory();
}
pc_guest_info_init(pcms);
pc: hack for migration compatibility from QEMU 2.0 Changing the ACPI table size causes migration to break, and the memory hotplug work opened our eyes on how horribly we were breaking things in 2.0 already. The ACPI table size is rounded to the next 4k, which one would think gives some headroom. In practice this is not the case, because the user can control the ACPI table size (each CPU adds 97 bytes to the SSDT and 8 to the MADT) and so some "-smp" values will break the 4k boundary and fail to migrate. Similarly, PCI bridges add ~1870 bytes to the SSDT. This patch concerns itself with fixing migration from QEMU 2.0. It computes the payload size of QEMU 2.0 and always uses that one. The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size should always be enough; non-AML tables can change depending on the configuration (especially MADT, SRAT, HPET) but they remain the same between QEMU 2.0 and 2.1, so we only compute our padding based on the sizes of the SSDT and DSDT. Migration from QEMU 1.7 should work for guests that have a number of CPUs other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140. It was already broken from QEMU 1.7 to QEMU 2.0 in the same way, though. Even with this patch, QEMU 1.7 and 2.0 have two different ideas of "-M pc-i440fx-2.0" when there are PCI bridges. Igor sent a patch to adopt the QEMU 1.7 definition. I think distributions should apply it if they move directly from QEMU 1.7 to 2.1+ without ever packaging version 2.0. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2014-07-28 19:34:15 +04:00
if (pcmc->smbios_defaults) {
/* These values are guest ABI, do not change */
smbios_set_defaults("QEMU", "Standard PC (Q35 + ICH9, 2009)",
mc->name, pcmc->smbios_legacy_mode,
pcmc->smbios_uuid_encoded,
SMBIOS_ENTRY_POINT_21);
}
/* allocate ram and load rom/bios */
if (!xen_enabled()) {
pc_memory_init(pcms, get_system_memory(),
rom_memory, &ram_memory);
}
/* create pci host bus */
q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
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
object_property_add_child(qdev_get_machine(), "q35", OBJECT(q35_host));
object_property_set_link(OBJECT(q35_host), OBJECT(ram_memory),
MCH_HOST_PROP_RAM_MEM, NULL);
object_property_set_link(OBJECT(q35_host), OBJECT(pci_memory),
MCH_HOST_PROP_PCI_MEM, NULL);
object_property_set_link(OBJECT(q35_host), OBJECT(get_system_memory()),
MCH_HOST_PROP_SYSTEM_MEM, NULL);
object_property_set_link(OBJECT(q35_host), OBJECT(system_io),
MCH_HOST_PROP_IO_MEM, NULL);
object_property_set_int(OBJECT(q35_host), x86ms->below_4g_mem_size,
PCI_HOST_BELOW_4G_MEM_SIZE, NULL);
object_property_set_int(OBJECT(q35_host), x86ms->above_4g_mem_size,
PCI_HOST_ABOVE_4G_MEM_SIZE, NULL);
/* pci */
qdev_init_nofail(DEVICE(q35_host));
phb = PCI_HOST_BRIDGE(q35_host);
host_bus = phb->bus;
/* create ISA bus */
lpc = pci_create_simple_multifunction(host_bus, PCI_DEVFN(ICH9_LPC_DEV,
ICH9_LPC_FUNC), true,
TYPE_ICH9_LPC_DEVICE);
object_property_add_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
TYPE_HOTPLUG_HANDLER,
(Object **)&pcms->acpi_dev,
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);
object_property_set_link(OBJECT(machine), OBJECT(lpc),
PC_MACHINE_ACPI_DEVICE_PROP, &error_abort);
/* irq lines */
gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
ich9_lpc = ICH9_LPC_DEVICE(lpc);
lpc_dev = DEVICE(lpc);
for (i = 0; i < GSI_NUM_PINS; i++) {
qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, x86ms->gsi[i]);
}
pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
ICH9_LPC_NB_PIRQS);
pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
isa_bus = ich9_lpc->isa_bus;
pc_i8259_create(isa_bus, gsi_state->i8259_irq);
if (pcmc->pci_enabled) {
ioapic_init_gsi(gsi_state, "q35");
}
if (tcg_enabled()) {
x86_register_ferr_irq(x86ms->gsi[13]);
}
assert(pcms->vmport != ON_OFF_AUTO__MAX);
if (pcms->vmport == ON_OFF_AUTO_AUTO) {
pcms->vmport = xen_enabled() ? ON_OFF_AUTO_OFF : ON_OFF_AUTO_ON;
}
/* init basic PC hardware */
pc_basic_device_init(isa_bus, x86ms->gsi, &rtc_state, !mc->no_floppy,
(pcms->vmport != ON_OFF_AUTO_ON), pcms->pit_enabled,
0xff0104);
/* connect pm stuff to lpc */
ich9_lpc_pm_init(lpc, x86_machine_is_smm_enabled(x86ms));
if (pcms->sata_enabled) {
/* ahci and SATA device, for q35 1 ahci controller is built-in */
ahci = pci_create_simple_multifunction(host_bus,
PCI_DEVFN(ICH9_SATA1_DEV,
ICH9_SATA1_FUNC),
true, "ich9-ahci");
idebus[0] = qdev_get_child_bus(&ahci->qdev, "ide.0");
idebus[1] = qdev_get_child_bus(&ahci->qdev, "ide.1");
g_assert(MAX_SATA_PORTS == ahci_get_num_ports(ahci));
ide_drive_get(hd, ahci_get_num_ports(ahci));
ahci_ide_create_devs(ahci, hd);
} else {
idebus[0] = idebus[1] = NULL;
}
if (machine_usb(machine)) {
/* Should we create 6 UHCI according to ich9 spec? */
ehci_create_ich9_with_companions(host_bus, 0x1d);
}
if (pcms->smbus_enabled) {
/* TODO: Populate SPD eeprom data. */
pcms->smbus = ich9_smb_init(host_bus,
PCI_DEVFN(ICH9_SMB_DEV, ICH9_SMB_FUNC),
0xb100);
smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
}
pc_cmos_init(pcms, idebus[0], idebus[1], rtc_state);
/* the rest devices to which pci devfn is automatically assigned */
pc_vga_init(isa_bus, host_bus);
pc_nic_init(pcmc, isa_bus, host_bus);
if (machine->nvdimms_state->is_enabled) {
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
x86_nvdimm_acpi_dsmio,
x86ms->fw_cfg, OBJECT(pcms));
}
}
#define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
static void pc_init_##suffix(MachineState *machine) \
{ \
void (*compat)(MachineState *m) = (compatfn); \
if (compat) { \
compat(machine); \
} \
pc_q35_init(machine); \
} \
DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn)
pc: Kill the "use flash device for BIOS unless KVM" misfeature Use of a flash memory device for the BIOS was added in series "[PATCH v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1. Flash vs. ROM is a guest-visible difference. Thus, flash use had to be suppressed for machine types pc-1.0 and older. This was accomplished by adding a dummy device "pc-sysfw" with property "rom_only": * Non-zero rom_only means "use ROM". Default for pc-1.0 and older. * Zero rom_only means "maybe use flash". Default for newer machines. Not only is the dummy device ugly, it was also retroactively added to the older machine types! Fortunately, it's not guest-visible (thus no immediate guest ABI breakage), and has no vmstate (thus no immediate migration breakage). Breakage occurs only if the user unwisely enables flash by setting rom_only to zero. Patch review FAIL #1. Why "maybe use flash"? Flash didn't (and still doesn't) work with KVM. Therefore, rom_only=0 really means "use flash, except when KVM is enabled, use ROM". This is a Bad Idea, because it makes enabling/ disabling KVM guest-visible. Patch review FAIL #2. Aside: it also precludes migrating between KVM on and off, but that's not possible for other reasons anyway. Fix as follows: 1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts, or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything for older machines (to remain bug-compatible). 2. Change the default value from 0 to 1 for these machines. Necessary, because 0 doesn't work with KVM. Once it does, we can flip the default back to 0. 3. Don't revert the retroactive addition of device "pc-sysfw" to older machine types. Seems not worth the trouble. 4. Add a TODO comment asking for device "pc-sysfw" to be dropped once flash works with KVM. Net effect is that you get a BIOS ROM again even when KVM is disabled, just like for machines predating the introduction of flash. To get flash instead, use "--global pc-sysfw.rom_only=0". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-12 19:25:03 +04:00
static void pc_q35_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pcmc->default_nic_model = "e1000e";
m->family = "pc_q35";
m->desc = "Standard PC (Q35 + ICH9, 2009)";
m->units_per_default_bus = 1;
m->default_machine_opts = "firmware=bios-256k.bin";
m->default_display = "std";
m->default_kernel_irqchip_split = false;
m->no_floppy = 1;
machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
m->max_cpus = 288;
}
static void pc_q35_5_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_machine_options(m);
m->alias = "q35";
pcmc->default_cpu_version = 1;
}
DEFINE_Q35_MACHINE(v5_1, "pc-q35-5.1", NULL,
pc_q35_5_1_machine_options);
static void pc_q35_5_0_machine_options(MachineClass *m)
{
pc_q35_5_1_machine_options(m);
m->alias = NULL;
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);
}
DEFINE_Q35_MACHINE(v5_0, "pc-q35-5.0", NULL,
pc_q35_5_0_machine_options);
static void pc_q35_4_2_machine_options(MachineClass *m)
{
pc_q35_5_0_machine_options(m);
m->alias = NULL;
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);
}
DEFINE_Q35_MACHINE(v4_2, "pc-q35-4.2", NULL,
pc_q35_4_2_machine_options);
static void pc_q35_4_1_machine_options(MachineClass *m)
{
pc_q35_4_2_machine_options(m);
m->alias = NULL;
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);
}
DEFINE_Q35_MACHINE(v4_1, "pc-q35-4.1", NULL,
pc_q35_4_1_machine_options);
static void pc_q35_4_0_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_4_1_machine_options(m);
m->alias = NULL;
pcmc->default_cpu_version = CPU_VERSION_LEGACY;
hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1 Commit c87759ce876a fixed a regression affecting pc-q35 machines by introducing a new pc-q35-4.0.1 machine version to be used instead of pc-q35-4.0. The only purpose was to revert the default behaviour of not using split irqchip, but the change also introduced the usual hw_compat and pc_compat bits, and wired them for pc-q35 only. This raises questions when it comes to add new compat properties for 4.0* machine versions of any architecture. Where to add them ? In 4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach all other architectures about 4.0.1. This solution isn't satisfying, especially since this is a pc-q35 specific issue. It turns out that the split irqchip default is handled in the machine option function and doesn't involve compat lists at all. Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1 machine option function. Move the compat props that were added to the 4.0.1 since c87759ce876a to 4.0. Even if only hw_compat_4_0_1 had an impact on other architectures, drop pc_compat_4_0_1 as well for consistency. Fixes: c87759ce876a "q35: Revert to kernel irqchip" Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <156051774276.244890.8660277280145466396.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-14 16:09:02 +03:00
/*
* This is the default machine for the 4.0-stable branch. It is basically
* a 4.0 that doesn't use split irqchip by default. It MUST hence apply the
* 4.0 compat props.
*/
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);
}
DEFINE_Q35_MACHINE(v4_0_1, "pc-q35-4.0.1", NULL,
pc_q35_4_0_1_machine_options);
static void pc_q35_4_0_machine_options(MachineClass *m)
{
pc_q35_4_0_1_machine_options(m);
m->default_kernel_irqchip_split = true;
m->alias = NULL;
hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1 Commit c87759ce876a fixed a regression affecting pc-q35 machines by introducing a new pc-q35-4.0.1 machine version to be used instead of pc-q35-4.0. The only purpose was to revert the default behaviour of not using split irqchip, but the change also introduced the usual hw_compat and pc_compat bits, and wired them for pc-q35 only. This raises questions when it comes to add new compat properties for 4.0* machine versions of any architecture. Where to add them ? In 4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach all other architectures about 4.0.1. This solution isn't satisfying, especially since this is a pc-q35 specific issue. It turns out that the split irqchip default is handled in the machine option function and doesn't involve compat lists at all. Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1 machine option function. Move the compat props that were added to the 4.0.1 since c87759ce876a to 4.0. Even if only hw_compat_4_0_1 had an impact on other architectures, drop pc_compat_4_0_1 as well for consistency. Fixes: c87759ce876a "q35: Revert to kernel irqchip" Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <156051774276.244890.8660277280145466396.stgit@bahia.lan> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-06-14 16:09:02 +03:00
/* Compat props are applied by the 4.0.1 machine */
}
DEFINE_Q35_MACHINE(v4_0, "pc-q35-4.0", NULL,
pc_q35_4_0_machine_options);
static void pc_q35_3_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_4_0_machine_options(m);
m->default_kernel_irqchip_split = false;
pcmc->do_not_add_smb_acpi = true;
m->smbus_no_migration_support = true;
m->alias = NULL;
pcmc->pvh_enabled = false;
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);
}
DEFINE_Q35_MACHINE(v3_1, "pc-q35-3.1", NULL,
pc_q35_3_1_machine_options);
static void pc_q35_3_0_machine_options(MachineClass *m)
{
pc_q35_3_1_machine_options(m);
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);
}
DEFINE_Q35_MACHINE(v3_0, "pc-q35-3.0", NULL,
pc_q35_3_0_machine_options);
static void pc_q35_2_12_machine_options(MachineClass *m)
{
pc_q35_3_0_machine_options(m);
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);
}
DEFINE_Q35_MACHINE(v2_12, "pc-q35-2.12", NULL,
pc_q35_2_12_machine_options);
static void pc_q35_2_11_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_2_12_machine_options(m);
pcmc->default_nic_model = "e1000";
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);
}
DEFINE_Q35_MACHINE(v2_11, "pc-q35-2.11", NULL,
pc_q35_2_11_machine_options);
static void pc_q35_2_10_machine_options(MachineClass *m)
{
pc_q35_2_11_machine_options(m);
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);
numa: equally distribute memory on nodes When there are more nodes than available memory to put the minimum allowed memory by node, all the memory is put on the last node. This is because we put (ram_size / nb_numa_nodes) & ~((1 << mc->numa_mem_align_shift) - 1); on each node, and in this case the value is 0. This is particularly true with pseries, as the memory must be aligned to 256MB. To avoid this problem, this patch uses an error diffusion algorithm [1] to distribute equally the memory on nodes. We introduce numa_auto_assign_ram() function in MachineClass to keep compatibility between machine type versions. The legacy function is used with pseries-2.9, pc-q35-2.9 and pc-i440fx-2.9 (and previous), the new one with all others. Example: qemu-system-ppc64 -S -nographic -nodefaults -monitor stdio -m 1G -smp 8 \ -numa node -numa node -numa node \ -numa node -numa node -numa node Before: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 0 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 0 MB node 4 cpus: 4 node 4 size: 0 MB node 5 cpus: 5 node 5 size: 1024 MB After: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 256 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 256 MB node 4 cpus: 4 node 4 size: 256 MB node 5 cpus: 5 node 5 size: 256 MB [1] https://en.wikipedia.org/wiki/Error_diffusion Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20170502162955.1610-2-lvivier@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> [ehabkost: s/ram_size/size/ at numa_default_auto_assign_ram()] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-02 19:29:55 +03:00
m->numa_auto_assign_ram = numa_legacy_auto_assign_ram;
NUMA: Enable adding NUMA node implicitly Linux and Windows need ACPI SRAT table to make memory hotplug work properly, however currently QEMU doesn't create SRAT table if numa options aren't present on CLI. Which breaks both linux and windows guests in certain conditions: * Windows: won't enable memory hotplug without SRAT table at all * Linux: if QEMU is started with initial memory all below 4Gb and no SRAT table present, guest kernel will use nommu DMA ops, which breaks 32bit hw drivers when memory is hotplugged and guest tries to use it with that drivers. Fix above issues by automatically creating a numa node when QEMU is started with memory hotplug enabled but without '-numa' options on CLI. (PS: auto-create numa node only for new machine types so not to break migration). Which would provide SRAT table to guests without explicit -numa options on CLI and would allow: * Windows: to enable memory hotplug * Linux: switch to SWIOTLB DMA ops, to bounce DMA transfers to 32bit allocated buffers that legacy drivers/hw can handle. [Rewritten by Igor] Reported-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Alistair Francis <alistair23@gmail.com> Cc: Takao Indoh <indou.takao@jp.fujitsu.com> Cc: Izumi Taku <izumi.taku@jp.fujitsu.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-11-14 05:34:01 +03:00
m->auto_enable_numa_with_memhp = false;
}
DEFINE_Q35_MACHINE(v2_10, "pc-q35-2.10", NULL,
pc_q35_2_10_machine_options);
static void pc_q35_2_9_machine_options(MachineClass *m)
{
pc_q35_2_10_machine_options(m);
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);
}
DEFINE_Q35_MACHINE(v2_9, "pc-q35-2.9", NULL,
pc_q35_2_9_machine_options);
static void pc_q35_2_8_machine_options(MachineClass *m)
{
pc_q35_2_9_machine_options(m);
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);
}
DEFINE_Q35_MACHINE(v2_8, "pc-q35-2.8", NULL,
pc_q35_2_8_machine_options);
static void pc_q35_2_7_machine_options(MachineClass *m)
{
pc_q35_2_8_machine_options(m);
m->max_cpus = 255;
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);
}
DEFINE_Q35_MACHINE(v2_7, "pc-q35-2.7", NULL,
pc_q35_2_7_machine_options);
static void pc_q35_2_6_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_2_7_machine_options(m);
pcmc->legacy_cpu_hotplug = true;
pcmc->linuxboot_dma_enabled = false;
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);
}
DEFINE_Q35_MACHINE(v2_6, "pc-q35-2.6", NULL,
pc_q35_2_6_machine_options);
static void pc_q35_2_5_machine_options(MachineClass *m)
{
X86MachineClass *x86mc = X86_MACHINE_CLASS(m);
pc_q35_2_6_machine_options(m);
x86mc->save_tsc_khz = false;
m->legacy_fw_cfg_order = 1;
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);
}
DEFINE_Q35_MACHINE(v2_5, "pc-q35-2.5", NULL,
pc_q35_2_5_machine_options);
static void pc_q35_2_4_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_q35_2_5_machine_options(m);
m->hw_version = "2.4.0";
pcmc->broken_reserved_end = true;
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);
}
DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
pc_q35_2_4_machine_options);