aboutsummaryrefslogtreecommitdiff
path: root/hw/i386/pc_piix.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-08hw: add compat machines for 6.0Cornelia Huck1-1/+13
Add 6.0 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20201109173928.1001764-1-cohuck@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-10-30pc: Implement -no-hpet as sugar for -machine hpet=onEduardo Habkost1-1/+1
Get rid of yet another global variable. The default will be hpet=on only if CONFIG_HPET=y. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20201021144716.1536388-1-ehabkost@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-10-19hw/xen: Set suppress-vmdesc for Xen machinesJason Andryuk1-2/+2
xen-save-devices-state doesn't currently generate a vmdesc, so restore always triggers "Expected vmdescription section, but got 0". This is not a problem when restore comes from a file. However, when QEMU runs in a linux stubdom and comes over a console, EOF is not received. This causes a delay restoring - though it does restore. Setting suppress-vmdesc skips looking for the vmdesc during restore and avoids the wait. The other approach would be generate a vmdesc in qemu_save_device_state. Since COLO shared that function, and the vmdesc is just discarded on restore, we choose to skip it. Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20201013190506.3325-1-jandryuk@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2020-09-30target/i386: always create kvmclock deviceVitaly Kuznetsov1-2/+5
QEMU's kvmclock device is only created when KVM PV feature bits for kvmclock (KVM_FEATURE_CLOCKSOURCE/KVM_FEATURE_CLOCKSOURCE2) are exposed to the guest. With 'kvm=off' cpu flag the device is not created and we don't call KVM_GET_CLOCK/KVM_SET_CLOCK upon migration. It was reported that without these call at least Hyper-V TSC page clocksouce (which can be enabled independently) gets broken after migration. Switch to creating kvmclock QEMU device unconditionally, it seems to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration. Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits. Reported-by: Antoine Damhet <antoine.damhet@blade-group.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200922151934.899555-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/xen: Split x86-specific declaration from generic hardware onesPhilippe Mathieu-Daudé1-1/+1
xen_hvm_init() is restricted to the X86 architecture. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200908155530.249806-6-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()Philippe Mathieu-Daudé1-3/+3
xen_hvm_init() is only meanful to initialize a X86/PC machine, rename it as xen_hvm_init_pc(). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200908155530.249806-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30numa: drop support for '-numa node' (without memory specified)Igor Mammedov1-1/+0
it was deprecated since 4.1 commit 4bb4a2732e (numa: deprecate implict memory distribution between nodes) Users of existing VMs, wishing to preserve the same RAM distribution, should configure it explicitly using ``-numa node,memdev`` options. Current RAM distribution can be retrieved using HMP command `info numa` and if separate memory devices (pc|nv-dimm) are present use `info memory-device` and subtract device memory from output of `info numa`. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200911084410.788171-2-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-29cphp: remove deprecated cpu-add command(s)Igor Mammedov1-1/+0
These were deprecated since 4.0, remove both HMP and QMP variants. Users should use device_add command instead. To get list of possible CPUs and options, use 'info hotpluggable-cpus' HMP or query-hotpluggable-cpus QMP command. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200915120403.1074579-1-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-17x86: move acpi_dev from pc/microvmGerd Hoffmann1-1/+1
Both pc and microvm machine types have a acpi_dev field. Move it to the common base type. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200915120909.20838-15-kraxel@redhat.com
2020-09-10hw/i386: make explicit clearing of pch_rev_idAlex Bennée1-1/+1
Some compilers (notably the Xenial gcc in Travis) fail to spot that this will always be set if pch_dev_id != 0xffff. Given this is setup code and using _Pragma to override is equally as ugly lets just remove the doubt from the compilers mind. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200909112742.25730-8-alex.bennee@linaro.org>
2020-08-22Merge remote-tracking branch ↵Peter Maydell1-1/+13
'remotes/ehabkost/tags/machine-next-pull-request' into staging Machine queue 2020-08-19 Regular post-release changes: * hw: add compat machines for 5.2 (Cornelia Huck) Features: * qmp: Expose MachineClass::default_ram_id (Michal Privoznik) Cleanups: * qdev: Document qdev_prop_set_drive_err() return value (Philippe Mathieu-Daudé) # gpg: Signature made Wed 19 Aug 2020 16:21:55 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/machine-next-pull-request: hw: add compat machines for 5.2 qmp: Expose MachineClass::default_ram_id qdev: Document qdev_prop_set_drive_err() return value Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-08-21meson: infrastructure for building emulatorsPaolo Bonzini1-1/+1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-19hw: add compat machines for 5.2Cornelia Huck1-1/+13
Add 5.2 machine types for arm/i440fx/q35/s390x/spapr. Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20200819144016.281156-1-cohuck@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-11Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20200710' into ↵Peter Maydell1-3/+6
staging xen patches Fixes following harden checks in qdev. # gpg: Signature made Fri 10 Jul 2020 14:05:46 BST # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20200710: xen: cleanup unrealized flash devices xen: Fix xen-legacy-backend qdev types Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-10qom: Put name parameter before value / visitor parameterMarkus Armbruster1-2/+2
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-10xen: cleanup unrealized flash devicesPaul Durrant1-3/+6
The generic pc_machine_initfn() calls pc_system_flash_create() which creates 'system.flash0' and 'system.flash1' devices. These devices are then realized by pc_system_flash_map() which is called from pc_system_firmware_init() which itself is called via pc_memory_init(). The latter however is not called when xen_enable() is true and hence the following assertion fails: qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: Assertion `dev->realized' failed These flash devices are unneeded when using Xen so this patch avoids the assertion by simply removing them using pc_system_flash_cleanup_unused(). Reported-by: Jason Andryuk <jandryuk@gmail.com> Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") Signed-off-by: Paul Durrant <pdurrant@amazon.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200624121841.17971-3-paul@xen.org> Fixes: dfe8c79c4468 ("qdev: Assert onboard devices all get realized properly") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2020-07-08Merge remote-tracking branch ↵Peter Maydell1-2/+1
'remotes/kraxel/tags/audio-20200706-pull-request' into staging audio: deprecate -soundhw # gpg: Signature made Mon 06 Jul 2020 20:29:07 BST # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/audio-20200706-pull-request: audio: set default value for pcspk.iobase property pcspk: update docs/system/target-i386-desc.rst.inc audio: add soundhw deprecation notice audio: deprecate -soundhw pcspk audio: create pcspk device early audio: rework pcspk_init() softmmu: initialize spice and audio earlier pc_basic_device_init: drop no_vmport arg pc_basic_device_init: drop has_pit arg pc_basic_device_init: pass PCMachineState audio: deprecate -soundhw hda audio: deprecate -soundhw sb16 audio: deprecate -soundhw gus audio: deprecate -soundhw cs4231a audio: deprecate -soundhw adlib audio: deprecate -soundhw es1370 audio: deprecate -soundhw ac97 audio: add deprecated_register_soundhw stubs: add pci_create_simple stubs: add isa_create_simple Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-06pc_basic_device_init: drop no_vmport argGerd Hoffmann1-1/+0
Now that we pass pcms anyway, we don't need the no_vmport arg any more. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-14-kraxel@redhat.com
2020-07-06pc_basic_device_init: drop has_pit argGerd Hoffmann1-1/+1
Now that we pass pcms anyway, we don't need the has_pit arg any more. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-13-kraxel@redhat.com
2020-07-06pc_basic_device_init: pass PCMachineStateGerd Hoffmann1-1/+1
Need access to pcms for pcspk initialization. Just preparation, no functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-12-kraxel@redhat.com
2020-07-03numa: Auto-enable NUMA when any memory devices are possibleDavid Hildenbrand1-0/+1
Let's auto-enable it also when maxmem is specified but no slots are defined. This will result in us properly creating ACPI srat tables, indicating the maximum possible PFN to the guest OS. Based on this, e.g., Linux will enable the swiotlb properly. This avoids having to manually force the switolb on (swiotlb=force) in Linux in case we're booting only using DMA memory (e.g., 2GB on x86-64), and virtio-mem adds memory later on that really needs the swiotlb to be used for DMA. Let's take care of backwards compatibility if somebody has a setup that specifies "maxram" without "slots". Reported-by: Alex Shi <alex.shi@linux.alibaba.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Sergio Lopez <slp@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: qemu-arm@nongnu.org <qemu-arm@nongnu.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-22-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-26numa: forbid '-numa node, mem' for 5.1 and newer machine typesIgor Mammedov1-0/+1
Deprecation period is run out and it's a time to flip the switch introduced by cd5ff8333a. Disable legacy option for new machine types (since 5.1) and amend documentation. '-numa node,memdev' shall be used instead of disabled option with new machine types. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20200609135635.761587-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-17x86: move max-ram-below-4g to pcGerd Hoffmann1-5/+5
Move from X86MachineClass to PCMachineClass so it disappears from microvm machine type property list. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Message-id: 20200529073957.8018-4-kraxel@redhat.com
2020-06-12xen: fix build without pci passthroughAnthony PERARD1-1/+1
Xen PCI passthrough support may not be available and thus the global variable "has_igd_gfx_passthru" might be compiled out. Common code should not access it in that case. Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in xen-common.c so this patch instead move access to the has_igd_gfx_passthru variable via function and those functions are also implemented as stubs. The stubs will be used when QEMU is built without passthrough support. Now, when one will want to enable igd-passthru via the -machine property, they will get an error message if QEMU is built without passthrough support. Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator property') Reported-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200603160442.3151170-1-anthony.perard@citrix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10accel: Move Xen accelerator code under accel/xen/Philippe Mathieu-Daudé1-0/+1
This code is not related to hardware emulation. Move it under accel/ with the other hypervisors. Reviewed-by: Paul Durrant <paul@xen.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200508100222.7112-1-philmd@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-10i386:pc: whitelist dynamic vmbus-bridgeJon Doron1-0/+2
As vmbus-bridge is derived from sysbus device, it has to be whitelisted to be allowed to be created with -device. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Signed-off-by: Jon Doron <arilou@gmail.com> Message-Id: <20200424123444.3481728-5-arilou@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster1-1/+1
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-06hw: add compat machines for 5.1Cornelia Huck1-1/+13
Add 5.1 machine types for arm/i440fx/q35/s390x/spapr. Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-id: 20200429144605.7262-1-cohuck@redhat.com
2020-05-04nvdimm: Use configurable ACPI IO base and sizeKwangwoo Lee1-0/+2
This patch makes IO base and size configurable to create NPIO AML for ACPI NFIT. Since a different architecture like AArch64 does not use port-mapped IO, a configurable IO base is required to create correct mapping of ACPI IO address and size. Signed-off-by: Kwangwoo Lee <kwangwoo.lee@sk.com> Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200421125934.14952-3-shameerali.kolothum.thodi@huawei.com> Acked-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-04-11piix: fix xenfv regression, add compat machine xenfv-4.2Olaf Hering1-3/+16
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-29acpi: add acpi=OnOffAuto machine property to x86 and arm virtGerd Hoffmann1-1/+1
Remove the global acpi_enabled bool and replace it with an acpi OnOffAuto machine property. qemu throws an error now if you use -no-acpi while the machine type you are using doesn't support acpi in the first place. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200320100136.11717-1-kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-03-17hw/ide: Remove unneeded inclusion of hw/ide.hBALATON Zoltan1-1/+0
After previous clean ups we can drop direct inclusion of hw/ide.h from several places. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: a3f72b663e537701c63cec5fc9cb8ed4f4249f28.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Do ide_drive_get() within pci_ide_create_devs()BALATON Zoltan1-4/+5
The pci_ide_create_devs() function takes a hd_table parameter but all callers just pass what ide_drive_get() returns so we can do it locally simplifying callers and removing hd_table parameter. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: e9713fdded4d212fa68ed03b844e531934226a6f.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-17hw/ide: Get rid of piix3_init functionsBALATON Zoltan1-5/+5
This removes pci_piix3_ide_init() and pci_piix3_xen_ide_init() functions similar to clean up done to other ide devices. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: adddfa21552783020d64e1314318cab6d24362c3.1584457537.git.balaton@eik.bme.hu Signed-off-by: John Snow <jsnow@redhat.com>
2020-03-09hw/i386: Include "hw/mem/nvdimm.h"Philippe Mathieu-Daudé1-0/+1
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-28hw: Make MachineClass::is_default a boolean typePhilippe Mathieu-Daudé1-5/+5
There's no good reason for it to be type int, change it to bool. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200207161948.15972-3-philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-01-05hw: fix using 4.2 compat in 5.0 machine types for i440fx/q35Denis Plotnikov1-1/+0
5.0 machine type uses 4.2 compats. This seems to be incorrect, since the latests machine type by now is 5.0 and it should use its own compat or shouldn't use any relying on the defaults. Seems, like this appeared because of some problems on merge/rebase. Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Message-Id: <20191223072856.5369-1-dplotnikov@virtuozzo.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-12-18hw/i386: Remove the deprecated machines 0.12 up to 0.15Thomas Huth1-83/+2
These machines can't be used reliably for migration anymore, quoting https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html : " due to the introduction of the memory API, the firmware is not migrated correctly from source to destination. On QEMU <1.3 the 0xf0000-0xfffff area is basically a copy of the higher 0xffff0000-0xffffffff area, while on more recent versions it is initialized with zeroes and the firmware copies from 0xffff0000 to 0xf0000. When you migrate from old to new QEMU, after reboot there's nothing at 0xf0000 and bugs ensue. " The pc-0.x machines have been marked as deprecated since QEMU v4.0, so it is time to remove them now. And while we're at it, mark the remaining pc-1.x machine types as deprecated now, too, so that we finally only have "pc-i440fx" and "pc-q35" machine types left (apart from the non-versioned "isapc" and "microvm") once we remove them in a couple of releases. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191209125248.5849-2-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-17x86: move SMM property to X86MachineStatePaolo Bonzini1-3/+3
Add it to microvm as well, it is a generic property of the x86 architecture. Suggested-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-14hw: add compat machines for 5.0Cornelia Huck1-1/+13
Add 5.0 machine types for arm/i440fx/q35/s390x/spapr. For i440fx and q35, unversioned cpu models are still translated to -v1; I'll leave changing this (if desired) to the respective maintainers. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20191112104811.30323-1-cohuck@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2019-12-13virtio-blk: advertise F_WCE (F_FLUSH) if F_CONFIG_WCE is advertisedEvgeny Yakovlev1-0/+1
Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device Initialization: "Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if they offer VIRTIO_BLK_F_CONFIG_WCE" Currently F_CONFIG_WCE and F_WCE are not connected to each other. Qemu will advertise F_CONFIG_WCE if config-wce argument is set for virtio-blk device. And F_WCE is advertised only if underlying block backend actually has it's caching enabled. Fix this by advertising F_WCE if F_CONFIG_WCE is also advertised. To preserve backwards compatibility with newer machine types make this behaviour governed by "x-enable-wce-if-config-wce" virtio-blk-device property and introduce hw_compat_4_2 with new property being off by default for all machine types <= 4.2 (but don't introduce 4.3 machine type itself yet). Signed-off-by: Evgeny Yakovlev <wrfsh@yandex-team.ru> Message-Id: <1572978137-189218-1-git-send-email-wrfsh@yandex-team.ru> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-11-19hw/i386: Move save_tsc_khz from PCMachineClass to X86MachineClassLiam Merwick1-2/+2
Attempting to migrate a VM using the microvm machine class results in the source QEMU aborting with the following message/backtrace: target/i386/machine.c:955:tsc_khz_needed: Object 0x555556608fa0 is not an instance of type generic-pc-machine abort() object_class_dynamic_cast_assert() vmstate_save_state_v() vmstate_save_state() vmstate_save() qemu_savevm_state_complete_precopy() migration_thread() migration_thread() migration_thread() qemu_thread_start() start_thread() clone() The access to the machine class returned by MACHINE_GET_CLASS() in tsc_khz_needed() is crashing as it is trying to dereference a different type of machine class object (TYPE_PC_MACHINE) to that of this microVM. This can be resolved by extending the changes in the following commit f0bb276bf8d5 ("hw/i386: split PCMachineState deriving X86MachineState from it") and moving the save_tsc_khz field in PCMachineClass to X86MachineClass. Fixes: f0bb276bf8d5 ("hw/i386: split PCMachineState deriving X86MachineState from it") Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <1574075605-25215-1-git-send-email-liam.merwick@oracle.com> Reviewed-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-19hw/i386: Fix compiler warning when CONFIG_IDE_ISA is disabledThomas Huth1-2/+2
When CONFIG_IDE_ISA is disabled, compilation currently fails: hw/i386/pc_piix.c: In function ‘pc_init1’: hw/i386/pc_piix.c:81:9: error: unused variable ‘i’ [-Werror=unused-variable] Move the variable declaration to the right code block to avoid this problem. Fixes: 4501d317b50e ("hw/i386/pc: Extract pc_i8259_create()") Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191115145049.26868-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-11-05hw/pci-host/i440fx: Remove the last PIIX3 tracesPhilippe Mathieu-Daudé1-1/+7
The PIIX3 is not tied to the i440FX and can even be used without it. Move its creation to the machine code (pc_piix.c). We have now removed the last trace of southbridge code in the i440FX northbridge. Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-11-05hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.hPhilippe Mathieu-Daudé1-0/+1
The hw/pci-host/piix.c contains a mix of PIIX3 and i440FX chipsets functions. To be able to split it, we need to export some declarations first. Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-11-05piix4: Add a MC146818 RTC Controller as specified in datasheetPhilippe Mathieu-Daudé1-0/+1
Remove mc146818rtc instanciated in malta board, to not have it twice. Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Message-Id: <20171216090228.28505-13-hpoussin@reactos.org> [PMD: rebased, set RTC base_year to 2000] Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-26target/i386: move FERR handling to target/i386Paolo Bonzini1-1/+3
Move it out of pc.c since it is strictly tied to TCG. This is almost exclusively code movement, the next patch will implement IGNNE. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-24hw/i386/pc: Remove kvm_i386.h includePhilippe Mathieu-Daudé1-1/+0
By extracting pc_gsi_create() and pc_i8259_create() we removed the access to "kvm_i386.h" from the machine code. We can now remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191015162705.28087-25-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-24hw/i386/pc: Extract pc_i8259_create()Philippe Mathieu-Daudé1-12/+1
The i8259 creation code is common to all PC machines, extract the common code. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191018135910.24286-5-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-24hw/i386/pc: Extract pc_gsi_create()Philippe Mathieu-Daudé1-8/+1
The GSI creation code is common to all PC machines, extract the common code. Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191018135910.24286-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2024-09-12 10:49:47 +0000