qemu/hw/i386/pc_piix.c

922 lines
31 KiB
C
Raw Normal View History

/*
* 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.
*/
#include "qemu/osdep.h"
#include CONFIG_DEVICES
#include "qemu/units.h"
#include "hw/char/parallel.h"
#include "hw/dma/i8257.h"
#include "hw/loader.h"
#include "hw/i386/x86.h"
#include "hw/i386/pc.h"
#include "hw/i386/apic.h"
#include "hw/pci-host/i440fx.h"
#include "hw/rtc/mc146818rtc.h"
#include "hw/southbridge/piix.h"
#include "hw/display/ramfb.h"
#include "hw/firmware/smbios.h"
#include "hw/pci/pci.h"
#include "hw/pci/pci_ids.h"
#include "hw/usb.h"
#include "net/net.h"
#include "hw/ide/isa.h"
#include "hw/ide/pci.h"
#include "hw/ide/piix.h"
#include "hw/irq.h"
#include "sysemu/kvm.h"
#include "hw/kvm/clock.h"
#include "hw/sysbus.h"
#include "hw/i2c/smbus_eeprom.h"
#include "exec/memory.h"
#include "hw/acpi/acpi.h"
#include "hw/acpi/piix4.h"
#include "hw/usb/hcd-uhci.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
#include "sysemu/xen.h"
#ifdef CONFIG_XEN
#include <xen/hvm/hvm_info_table.h>
#include "hw/xen/xen_pt.h"
#endif
#include "hw/xen/xen-x86.h"
#include "hw/xen/xen.h"
#include "migration/global_state.h"
#include "migration/misc.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"
#include "kvm/kvm-cpu.h"
#define MAX_IDE_BUS 2
#ifdef CONFIG_IDE_ISA
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 };
#endif
/*
* 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;
}
/* PC hardware initialisation */
static void pc_init1(MachineState *machine,
const char *host_type, const char *pci_type)
{
PCMachineState *pcms = PC_MACHINE(machine);
PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
X86MachineState *x86ms = X86_MACHINE(machine);
MemoryRegion *system_memory = get_system_memory();
MemoryRegion *system_io = get_system_io();
PCIBus *pci_bus;
ISABus *isa_bus;
int piix3_devfn = -1;
qemu_irq smi_irq;
GSIState *gsi_state;
BusState *idebus[MAX_IDE_BUS];
ISADevice *rtc_state;
MemoryRegion *ram_memory;
MemoryRegion *pci_memory;
MemoryRegion *rom_memory;
ram_addr_t lowmem;
uint64_t hole64_size;
DeviceState *i440fx_host;
/*
* 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.
*
* - Note that Xen has its own ram setup code in xen_ram_init(),
* called via xen_hvm_init_pc().
*
* 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)
*/
if (xen_enabled()) {
xen_hvm_init_pc(pcms, &ram_memory);
} else {
ram_memory = machine->ram;
if (!pcms->max_ram_below_4g) {
pcms->max_ram_below_4g = 0xe0000000; /* default: 3.5G */
}
lowmem = pcms->max_ram_below_4g;
if (machine->ram_size >= pcms->max_ram_below_4g) {
if (pcmc->gigabyte_align) {
if (lowmem > 0xc0000000) {
lowmem = 0xc0000000;
}
if (lowmem & (1 * GiB - 1)) {
Convert error_report() to warn_report() Convert all uses of error_report("warning:"... to use warn_report() instead. This helps standardise on a single method of printing warnings to the user. All of the warnings were changed using these two commands: find ./* -type f -exec sed -i \ 's|error_report(".*warning[,:] |warn_report("|Ig' {} + Indentation fixed up manually afterwards. The test-qdev-global-props test case was manually updated to ensure that this patch passes make check (as the test cases are case sensitive). Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Suggested-by: Thomas Huth <thuth@redhat.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Lieven <pl@kamp.de> Cc: Josh Durgin <jdurgin@redhat.com> Cc: "Richard W.M. Jones" <rjones@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Greg Kurz <groug@kaod.org> Cc: Rob Herring <robh@kernel.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Peter Chubb <peter.chubb@nicta.com.au> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Greg Kurz <groug@kaod.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed by: Peter Chubb <peter.chubb@data61.csiro.au> Acked-by: Max Reitz <mreitz@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <e1cfa2cd47087c248dd24caca9c33d9af0c499b0.1499866456.git.alistair.francis@xilinx.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
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.",
pcms->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;
}
}
pc_machine_init_sgx_epc(pcms);
x86_cpus_init(x86ms, pcmc->default_cpu_version);
if (pcmc->kvmclock_enabled) {
kvmclock_create(pcmc->kvmclock_create_always);
}
if (pcmc->pci_enabled) {
pci_memory = g_new(MemoryRegion, 1);
memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
rom_memory = pci_memory;
i440fx_host = qdev_new(host_type);
hole64_size = object_property_get_uint(OBJECT(i440fx_host),
PCI_HOST_PROP_PCI_HOLE64_SIZE,
&error_abort);
} else {
pci_memory = NULL;
rom_memory = system_memory;
i440fx_host = NULL;
hole64_size = 0;
}
pc_guest_info_init(pcms);
if (pcmc->smbios_defaults) {
MachineClass *mc = MACHINE_GET_CLASS(machine);
/* These values are guest ABI, do not change */
smbios_set_defaults("QEMU", mc->desc,
mc->name, pcmc->smbios_legacy_mode,
pcmc->smbios_uuid_encoded,
pcms->smbios_entry_point_type);
}
/* allocate ram and load rom/bios */
if (!xen_enabled()) {
pc_memory_init(pcms, system_memory, rom_memory, hole64_size);
} else {
pc_system_flash_cleanup_unused(pcms);
if (machine->kernel_filename != NULL) {
/* For xen HVM direct kernel boot, load linux here */
xen_load_linux(pcms);
}
}
gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
if (pcmc->pci_enabled) {
PIIX3State *piix3;
PCIDevice *pci_dev;
const char *type = xen_enabled() ? TYPE_PIIX3_XEN_DEVICE
: TYPE_PIIX3_DEVICE;
pci_bus = i440fx_init(pci_type,
i440fx_host,
system_memory, system_io, machine->ram_size,
x86ms->below_4g_mem_size,
x86ms->above_4g_mem_size,
pci_memory, ram_memory);
pci_bus_map_irqs(pci_bus,
xen_enabled() ? xen_pci_slot_get_pirq
: pc_pci_slot_get_pirq);
pcms->bus = pci_bus;
pci_dev = pci_create_simple_multifunction(pci_bus, -1, true, type);
piix3 = PIIX3_PCI_DEVICE(pci_dev);
piix3->pic = x86ms->gsi;
piix3_devfn = piix3->dev.devfn;
isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(piix3), "isa.0"));
rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(pci_dev),
"rtc"));
} else {
pci_bus = NULL;
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);
rtc_state = isa_new(TYPE_MC146818_RTC);
qdev_prop_set_int32(DEVICE(rtc_state), "base_year", 2000);
isa_realize_and_unref(rtc_state, isa_bus, &error_fatal);
i8257_dma_init(isa_bus, 0);
pcms->hpet_enabled = false;
}
isa_bus_register_input_irqs(isa_bus, x86ms->gsi);
if (x86ms->pic == ON_OFF_AUTO_ON || x86ms->pic == ON_OFF_AUTO_AUTO) {
pc_i8259_create(isa_bus, gsi_state->i8259_irq);
}
if (pcmc->pci_enabled) {
ioapic_init_gsi(gsi_state, "i440fx");
}
if (tcg_enabled()) {
x86_register_ferr_irq(x86ms->gsi[13]);
}
pc_vga_init(isa_bus, pcmc->pci_enabled ? pci_bus : NULL);
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(pcms, isa_bus, x86ms->gsi, rtc_state, true,
0x4);
pc_nic_init(pcmc, isa_bus, pci_bus);
if (pcmc->pci_enabled) {
PCIDevice *dev;
dev = pci_create_simple(pci_bus, piix3_devfn + 1, TYPE_PIIX3_IDE);
pci_ide_create_devs(dev);
idebus[0] = qdev_get_child_bus(&dev->qdev, "ide.0");
idebus[1] = qdev_get_child_bus(&dev->qdev, "ide.1");
pc_cmos_init(pcms, idebus[0], idebus[1], rtc_state);
}
#ifdef CONFIG_IDE_ISA
else {
DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
int i;
ide_drive_get(hd, ARRAY_SIZE(hd));
for (i = 0; i < MAX_IDE_BUS; i++) {
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";
dev = isa_ide_init(isa_bus, ide_iobase[i], ide_iobase2[i],
ide_irq[i],
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;
idebus[i] = qdev_get_child_bus(DEVICE(dev), busname);
}
pc_cmos_init(pcms, idebus[0], idebus[1], rtc_state);
}
#endif
if (pcmc->pci_enabled && machine_usb(machine)) {
pci_create_simple(pci_bus, piix3_devfn + 2, TYPE_PIIX3_USB_UHCI);
}
if (pcmc->pci_enabled && x86_machine_is_acpi_enabled(X86_MACHINE(pcms))) {
PCIDevice *piix4_pm;
smi_irq = qemu_allocate_irq(pc_acpi_smi_interrupt, first_cpu, 0);
piix4_pm = pci_new(piix3_devfn + 3, TYPE_PIIX4_PM);
qdev_prop_set_uint32(DEVICE(piix4_pm), "smb_io_base", 0xb100);
qdev_prop_set_bit(DEVICE(piix4_pm), "smm-enabled",
x86_machine_is_smm_enabled(x86ms));
pci_realize_and_unref(piix4_pm, pci_bus, &error_fatal);
qdev_connect_gpio_out(DEVICE(piix4_pm), 0, x86ms->gsi[9]);
qdev_connect_gpio_out_named(DEVICE(piix4_pm), "smi-irq", 0, smi_irq);
pcms->smbus = I2C_BUS(qdev_get_child_bus(DEVICE(piix4_pm), "i2c"));
/* TODO: Populate SPD eeprom data. */
smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
object_property_add_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
TYPE_HOTPLUG_HANDLER,
(Object **)&x86ms->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);
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,
OBJECT(piix4_pm), &error_abort);
}
if (machine->nvdimms_state->is_enabled) {
nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
x86_nvdimm_acpi_dsmio,
x86ms->fw_cfg, OBJECT(pcms));
}
}
/* Looking for a pc_compat_2_4() function? It doesn't exist.
* pc_compat_*() functions that run on machine-init time and
* change global QEMU state are deprecated. Please don't create
* one, and implement any pc-*-2.4 (and newer) compat code in
* hw_compat_*, pc_compat_*, or * pc_*_machine_options().
*/
static void pc_compat_2_3_fn(MachineState *machine)
{
X86MachineState *x86ms = X86_MACHINE(machine);
if (kvm_enabled()) {
x86ms->smm = ON_OFF_AUTO_OFF;
}
}
static void pc_compat_2_2_fn(MachineState *machine)
{
pc_compat_2_3_fn(machine);
}
static void pc_compat_2_1_fn(MachineState *machine)
{
pc_compat_2_2_fn(machine);
x86_cpu_change_kvm_default("svm", NULL);
}
static void pc_compat_2_0_fn(MachineState *machine)
{
pc_compat_2_1_fn(machine);
}
static void pc_compat_1_7_fn(MachineState *machine)
{
pc_compat_2_0_fn(machine);
x86_cpu_change_kvm_default("x2apic", NULL);
}
static void pc_compat_1_6_fn(MachineState *machine)
{
pc_compat_1_7_fn(machine);
}
static void pc_compat_1_5_fn(MachineState *machine)
{
pc_compat_1_6_fn(machine);
}
static void pc_compat_1_4_fn(MachineState *machine)
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
{
pc_compat_1_5_fn(machine);
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
}
#ifdef CONFIG_ISAPC
static void pc_init_isa(MachineState *machine)
{
pc_init1(machine, TYPE_I440FX_PCI_HOST_BRIDGE, TYPE_I440FX_PCI_DEVICE);
}
#endif
#ifdef CONFIG_XEN
static void pc_xen_hvm_init_pci(MachineState *machine)
{
const char *pci_type = xen_igd_gfx_pt_enabled() ?
TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE;
pc_init1(machine,
TYPE_I440FX_PCI_HOST_BRIDGE,
pci_type);
}
static void pc_xen_hvm_init(MachineState *machine)
{
PCMachineState *pcms = PC_MACHINE(machine);
if (!xen_enabled()) {
error_report("xenfv machine requires the xen accelerator");
exit(1);
}
pc_xen_hvm_init_pci(machine);
xen/pt: reserve PCI slot 2 for Intel igd-passthru Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus, as noted in docs/igd-assign.txt in the Qemu source code. Currently, when the xl toolstack is used to configure a Xen HVM guest with Intel IGD passthrough to the guest with the Qemu upstream device model, a Qemu emulated PCI device will occupy slot 2 and the Intel IGD will occupy a different slot. This problem often prevents the guest from booting. The only available workarounds are not good: Configure Xen HVM guests to use the old and no longer maintained Qemu traditional device model available from xenbits.xen.org which does reserve slot 2 for the Intel IGD or use the "pc" machine type instead of the "xenfv" machine type and add the xen platform device at slot 3 using a command line option instead of patching qemu to fix the "xenfv" machine type directly. The second workaround causes some degredation in startup performance such as a longer boot time and reduced resolution of the grub menu that is displayed on the monitor. This patch avoids that reduced startup performance when using the Qemu upstream device model for Xen HVM guests configured with the igd-passthru=on option. To implement this feature in the Qemu upstream device model for Xen HVM guests, introduce the following new functions, types, and macros: * XEN_PT_DEVICE_CLASS declaration, based on the existing TYPE_XEN_PT_DEVICE * XEN_PT_DEVICE_GET_CLASS macro helper function for XEN_PT_DEVICE_CLASS * typedef XenPTQdevRealize function pointer * XEN_PCI_IGD_SLOT_MASK, the value of slot_reserved_mask to reserve slot 2 * xen_igd_reserve_slot and xen_igd_clear_slot functions Michael Tsirkin: * Introduce XEN_PCI_IGD_DOMAIN, XEN_PCI_IGD_BUS, XEN_PCI_IGD_DEV, and XEN_PCI_IGD_FN - use them to compute the value of XEN_PCI_IGD_SLOT_MASK The new xen_igd_reserve_slot function uses the existing slot_reserved_mask member of PCIBus to reserve PCI slot 2 for Xen HVM guests configured using the xl toolstack with the gfx_passthru option enabled, which sets the igd-passthru=on option to Qemu for the Xen HVM machine type. The new xen_igd_reserve_slot function also needs to be implemented in hw/xen/xen_pt_stub.c to prevent FTBFS during the link stage for the case when Qemu is configured with --enable-xen and --disable-xen-pci-passthrough, in which case it does nothing. The new xen_igd_clear_slot function overrides qdev->realize of the parent PCI device class to enable the Intel IGD to occupy slot 2 on the PCI bus since slot 2 was reserved by xen_igd_reserve_slot when the PCI bus was created in hw/i386/pc_piix.c for the case when igd-passthru=on. Move the call to xen_host_pci_device_get, and the associated error handling, from xen_pt_realize to the new xen_igd_clear_slot function to initialize the device class and vendor values which enables the checks for the Intel IGD to succeed. The verification that the host device is an Intel IGD to be passed through is done by checking the domain, bus, slot, and function values as well as by checking that gfx_passthru is enabled, the device class is VGA, and the device vendor in Intel. Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <b1b4a21fe9a600b1322742dda55a40e9961daa57.1674346505.git.brchuckz@aol.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2023-01-22 03:57:02 +03:00
xen_igd_reserve_slot(pcms->bus);
pci_create_simple(pcms->bus, -1, "xen-platform");
}
#endif
#define DEFINE_I440FX_MACHINE(suffix, name, compatfn, optionfn) \
static void pc_init_##suffix(MachineState *machine) \
{ \
void (*compat)(MachineState *m) = (compatfn); \
if (compat) { \
compat(machine); \
} \
pc_init1(machine, TYPE_I440FX_PCI_HOST_BRIDGE, \
TYPE_I440FX_PCI_DEVICE); \
} \
DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn)
static void pc_i440fx_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pcmc->pci_root_uid = 0;
pcmc->default_cpu_version = 1;
m->family = "pc_piix";
m->desc = "Standard PC (i440FX + PIIX, 1996)";
m->default_machine_opts = "firmware=bios-256k.bin";
m->default_display = "std";
m->default_nic = "e1000";
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
}
static void pc_i440fx_8_1_machine_options(MachineClass *m)
{
pc_i440fx_machine_options(m);
m->alias = "pc";
m->is_default = true;
}
DEFINE_I440FX_MACHINE(v8_1, "pc-i440fx-8.1", NULL,
pc_i440fx_8_1_machine_options);
static void pc_i440fx_8_0_machine_options(MachineClass *m)
{
pc_i440fx_8_1_machine_options(m);
m->alias = NULL;
m->is_default = false;
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);
}
DEFINE_I440FX_MACHINE(v8_0, "pc-i440fx-8.0", NULL,
pc_i440fx_8_0_machine_options);
static void pc_i440fx_7_2_machine_options(MachineClass *m)
{
pc_i440fx_8_0_machine_options(m);
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);
}
DEFINE_I440FX_MACHINE(v7_2, "pc-i440fx-7.2", NULL,
pc_i440fx_7_2_machine_options);
static void pc_i440fx_7_1_machine_options(MachineClass *m)
{
pc_i440fx_7_2_machine_options(m);
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);
}
DEFINE_I440FX_MACHINE(v7_1, "pc-i440fx-7.1", NULL,
pc_i440fx_7_1_machine_options);
static void pc_i440fx_7_0_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_7_1_machine_options(m);
pcmc->enforce_amd_1tb_hole = false;
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);
}
DEFINE_I440FX_MACHINE(v7_0, "pc-i440fx-7.0", NULL,
pc_i440fx_7_0_machine_options);
static void pc_i440fx_6_2_machine_options(MachineClass *m)
{
pc_i440fx_7_0_machine_options(m);
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);
}
DEFINE_I440FX_MACHINE(v6_2, "pc-i440fx-6.2", NULL,
pc_i440fx_6_2_machine_options);
static void pc_i440fx_6_1_machine_options(MachineClass *m)
{
pc_i440fx_6_2_machine_options(m);
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);
m->smp_props.prefer_sockets = true;
}
DEFINE_I440FX_MACHINE(v6_1, "pc-i440fx-6.1", NULL,
pc_i440fx_6_1_machine_options);
static void pc_i440fx_6_0_machine_options(MachineClass *m)
{
pc_i440fx_6_1_machine_options(m);
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);
}
DEFINE_I440FX_MACHINE(v6_0, "pc-i440fx-6.0", NULL,
pc_i440fx_6_0_machine_options);
static void pc_i440fx_5_2_machine_options(MachineClass *m)
{
pc_i440fx_6_0_machine_options(m);
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);
}
DEFINE_I440FX_MACHINE(v5_2, "pc-i440fx-5.2", NULL,
pc_i440fx_5_2_machine_options);
static void pc_i440fx_5_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_5_2_machine_options(m);
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);
pcmc->kvmclock_create_always = false;
pcmc->pci_root_uid = 1;
}
DEFINE_I440FX_MACHINE(v5_1, "pc-i440fx-5.1", NULL,
pc_i440fx_5_1_machine_options);
static void pc_i440fx_5_0_machine_options(MachineClass *m)
{
pc_i440fx_5_1_machine_options(m);
m->numa_mem_supported = true;
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);
m->auto_enable_numa_with_memdev = false;
}
DEFINE_I440FX_MACHINE(v5_0, "pc-i440fx-5.0", NULL,
pc_i440fx_5_0_machine_options);
static void pc_i440fx_4_2_machine_options(MachineClass *m)
{
pc_i440fx_5_0_machine_options(m);
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_I440FX_MACHINE(v4_2, "pc-i440fx-4.2", NULL,
pc_i440fx_4_2_machine_options);
static void pc_i440fx_4_1_machine_options(MachineClass *m)
{
pc_i440fx_4_2_machine_options(m);
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_I440FX_MACHINE(v4_1, "pc-i440fx-4.1", NULL,
pc_i440fx_4_1_machine_options);
static void pc_i440fx_4_0_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_4_1_machine_options(m);
pcmc->default_cpu_version = CPU_VERSION_LEGACY;
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_I440FX_MACHINE(v4_0, "pc-i440fx-4.0", NULL,
pc_i440fx_4_0_machine_options);
static void pc_i440fx_3_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_4_0_machine_options(m);
m->smbus_no_migration_support = true;
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_I440FX_MACHINE(v3_1, "pc-i440fx-3.1", NULL,
pc_i440fx_3_1_machine_options);
static void pc_i440fx_3_0_machine_options(MachineClass *m)
{
pc_i440fx_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_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
pc_i440fx_3_0_machine_options);
static void pc_i440fx_2_12_machine_options(MachineClass *m)
{
pc_i440fx_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_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
pc_i440fx_2_12_machine_options);
static void pc_i440fx_2_11_machine_options(MachineClass *m)
{
pc_i440fx_2_12_machine_options(m);
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_I440FX_MACHINE(v2_11, "pc-i440fx-2.11", NULL,
pc_i440fx_2_11_machine_options);
static void pc_i440fx_2_10_machine_options(MachineClass *m)
{
pc_i440fx_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: 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_I440FX_MACHINE(v2_10, "pc-i440fx-2.10", NULL,
pc_i440fx_2_10_machine_options);
static void pc_i440fx_2_9_machine_options(MachineClass *m)
{
pc_i440fx_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_I440FX_MACHINE(v2_9, "pc-i440fx-2.9", NULL,
pc_i440fx_2_9_machine_options);
static void pc_i440fx_2_8_machine_options(MachineClass *m)
{
pc_i440fx_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_I440FX_MACHINE(v2_8, "pc-i440fx-2.8", NULL,
pc_i440fx_2_8_machine_options);
static void pc_i440fx_2_7_machine_options(MachineClass *m)
{
pc_i440fx_2_8_machine_options(m);
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_I440FX_MACHINE(v2_7, "pc-i440fx-2.7", NULL,
pc_i440fx_2_7_machine_options);
static void pc_i440fx_2_6_machine_options(MachineClass *m)
{
X86MachineClass *x86mc = X86_MACHINE_CLASS(m);
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_2_7_machine_options(m);
pcmc->legacy_cpu_hotplug = true;
x86mc->fwcfg_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_I440FX_MACHINE(v2_6, "pc-i440fx-2.6", NULL,
pc_i440fx_2_6_machine_options);
static void pc_i440fx_2_5_machine_options(MachineClass *m)
{
X86MachineClass *x86mc = X86_MACHINE_CLASS(m);
pc_i440fx_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_I440FX_MACHINE(v2_5, "pc-i440fx-2.5", NULL,
pc_i440fx_2_5_machine_options);
static void pc_i440fx_2_4_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_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_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
pc_i440fx_2_4_machine_options)
static void pc_i440fx_2_3_machine_options(MachineClass *m)
{
pc_i440fx_2_4_machine_options(m);
m->hw_version = "2.3.0";
compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
}
DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
pc_i440fx_2_3_machine_options);
static void pc_i440fx_2_2_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_2_3_machine_options(m);
m->hw_version = "2.2.0";
m->default_machine_opts = "firmware=bios-256k.bin,suppress-vmdesc=on";
compat_props_add(m->compat_props, hw_compat_2_2, hw_compat_2_2_len);
compat_props_add(m->compat_props, pc_compat_2_2, pc_compat_2_2_len);
pcmc->rsdp_in_ram = false;
pcmc->resizable_acpi_blob = false;
}
DEFINE_I440FX_MACHINE(v2_2, "pc-i440fx-2.2", pc_compat_2_2_fn,
pc_i440fx_2_2_machine_options);
static void pc_i440fx_2_1_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_2_2_machine_options(m);
m->hw_version = "2.1.0";
m->default_display = NULL;
compat_props_add(m->compat_props, hw_compat_2_1, hw_compat_2_1_len);
compat_props_add(m->compat_props, pc_compat_2_1, pc_compat_2_1_len);
pcmc->smbios_uuid_encoded = false;
pcmc->enforce_aligned_dimm = false;
}
DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
pc_i440fx_2_1_machine_options);
static void pc_i440fx_2_0_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_2_1_machine_options(m);
m->hw_version = "2.0.0";
compat_props_add(m->compat_props, pc_compat_2_0, pc_compat_2_0_len);
pcmc->smbios_legacy_mode = true;
pcmc->has_reserved_memory = false;
/* This value depends on the actual DSDT and SSDT compiled into
* the source QEMU; unfortunately it depends on the binary and
* not on the machine type, so we cannot make pc-i440fx-1.7 work on
* both QEMU 1.7 and QEMU 2.0.
*
* Large variations cause migration to fail for more than one
* consecutive value of the "-smp" maxcpus option.
*
* For small variations of the kind caused by different iasl versions,
* the 4k rounding usually leaves slack. However, there could be still
* one or two values that break. For QEMU 1.7 and QEMU 2.0 the
* slack is only ~10 bytes before one "-smp maxcpus" value breaks!
*
* 6652 is valid for QEMU 2.0, the right value for pc-i440fx-1.7 on
* QEMU 1.7 it is 6414. For RHEL/CentOS 7.0 it is 6418.
*/
pcmc->legacy_acpi_table_size = 6652;
pcmc->acpi_data_size = 0x10000;
}
DEFINE_I440FX_MACHINE(v2_0, "pc-i440fx-2.0", pc_compat_2_0_fn,
pc_i440fx_2_0_machine_options);
static void pc_i440fx_1_7_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_2_0_machine_options(m);
m->hw_version = "1.7.0";
m->default_machine_opts = NULL;
m->option_rom_has_mr = true;
m->deprecation_reason = "old and unattended - use a newer version instead";
compat_props_add(m->compat_props, pc_compat_1_7, pc_compat_1_7_len);
pcmc->smbios_defaults = false;
pcmc->gigabyte_align = false;
pcmc->legacy_acpi_table_size = 6414;
}
DEFINE_I440FX_MACHINE(v1_7, "pc-i440fx-1.7", pc_compat_1_7_fn,
pc_i440fx_1_7_machine_options);
static void pc_i440fx_1_6_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
pc_i440fx_1_7_machine_options(m);
m->hw_version = "1.6.0";
m->rom_file_has_mr = false;
compat_props_add(m->compat_props, pc_compat_1_6, pc_compat_1_6_len);
pcmc->has_acpi_build = false;
}
DEFINE_I440FX_MACHINE(v1_6, "pc-i440fx-1.6", pc_compat_1_6_fn,
pc_i440fx_1_6_machine_options);
static void pc_i440fx_1_5_machine_options(MachineClass *m)
{
pc_i440fx_1_6_machine_options(m);
m->hw_version = "1.5.0";
compat_props_add(m->compat_props, pc_compat_1_5, pc_compat_1_5_len);
}
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
DEFINE_I440FX_MACHINE(v1_5, "pc-i440fx-1.5", pc_compat_1_5_fn,
pc_i440fx_1_5_machine_options);
static void pc_i440fx_1_4_machine_options(MachineClass *m)
{
pc_i440fx_1_5_machine_options(m);
m->hw_version = "1.4.0";
compat_props_add(m->compat_props, pc_compat_1_4, pc_compat_1_4_len);
}
DEFINE_I440FX_MACHINE(v1_4, "pc-i440fx-1.4", pc_compat_1_4_fn,
pc_i440fx_1_4_machine_options);
#ifdef CONFIG_ISAPC
static void isapc_machine_options(MachineClass *m)
{
PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
m->desc = "ISA-only PC";
m->max_cpus = 1;
m->option_rom_has_mr = true;
m->rom_file_has_mr = false;
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;
m->default_nic = "ne2k_isa";
m->default_cpu_type = X86_CPU_TYPE_NAME("486");
m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
}
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
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
isapc_machine_options);
#endif
#ifdef CONFIG_XEN
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
static void xenfv_4_2_machine_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
pc_i440fx_4_2_machine_options(m);
m->desc = "Xen Fully-virtualized PC";
m->max_cpus = HVM_MAX_VCPUS;
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,
xenfv_4_2_machine_options);
static void xenfv_3_1_machine_options(MachineClass *m)
{
pc_i440fx_3_1_machine_options(m);
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";
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen,suppress-vmdesc=on";
}
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,
xenfv_3_1_machine_options);
#endif