aboutsummaryrefslogtreecommitdiff
path: root/include/hw/compat.h
AgeCommit message (Collapse)Author
2018-04-27spapr: Introduce pseries-2.13 machine typeDavid Gibson
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-04-10e1000: Old machine types, turn new subsection offDr. David Alan Gilbert
Turn the newly added subsection off for old machine types Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2018-02-08virtio-blk: enable multiple vectors when using multiple I/O queuesChangpeng Liu
Currently virtio-pci driver hardcoded 2 vectors for virtio-blk device, for multiple I/O queues scenario, all the I/O queues will share one interrupt vector, while here, enable multiple vectors according to the number of I/O queues. Signed-off-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-01-12hpet: recover timer offset correctlyPavel Dovgalyuk
HPET saves its state by calculating the current time and recovers timer offset using this calculated value. But these calculations include divisions and multiplications. Therefore the timer state cannot be recovered precise enough. This patch introduces saving of the original value of the offset to preserve the determinism of the timer. Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Signed-off-by: Maria Klimushenkova <maria.klimushenkova@ispras.ru> Reviewed-by: Juan Quintela <quintela@redhat.com> -- v3: Added compat property for correct migration. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-14s390x: introduce 2.12 compat machineCornelia Huck
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-11-20Revert "Add new PCI ID for i82559a"Jason Wang
This reverts commit 5e89dc01133f8f5e621f6b66b356c6f37d31dafb since: - we should use ID in the spec instead the one used by OEM - in the future, we should allow changing id through either property or EEPROM file. Cc: Stefan Weil <sw@weilnetz.de> Cc: Michael Nawrocki <michael.nawrocki@gtri.gatech.edu> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Jason Wang <jasowang@redhat.com>
2017-11-13Add new PCI ID for i82559aMike Nawrocki
Adds a new PCI ID for the i82559a (0x8086 0x1030) interface. The "x-use-alt-device-id" property controls whether this new ID is to be used, and is true by default, and set to false in a compat entry. Signed-off-by: Mike Nawrocki <michael.nawrocki@gtri.gatech.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2017-09-29virtio-input: send rel-wheel events for wheel buttonsGerd Hoffmann
qemu uses wheel-up/down button events for mouse wheel input, however linux applications typically want REL_WHEEL events. This fixes wheel with linux guests. Tested with X11/wayland, and windows virtio-input driver. Based on a patch from Marc. Added property to enable/disable wheel axis. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20170926113243.26081-1-kraxel@redhat.com
2017-09-08vmgenid: replace x-write-pointer-available hackMarc-André Lureau
This compat property sole function is to prevent the device from being instantiated. Instead of requiring an extra compat property, check if fw_cfg has DMA enabled. fw_cfg is a built-in device that is initialized very early by the machine init code. We have at least one other device that also assumes fw_cfg_find() can be safely used on realize: pvpanic. This has the additional benefit of handling other cases properly, like: $ qemu-system-x86_64 -device vmgenid -machine none qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write support in fw_cfg, which this machine type does not provide $ qemu-system-x86_64 -device vmgenid -machine pc-i440fx-2.9 -global fw_cfg.dma_enabled=off qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write support in fw_cfg, which this machine type does not provide $ qemu-system-x86_64 -device vmgenid -machine pc-i440fx-2.6 -global fw_cfg.dma_enabled=on [boots normally] Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Ben Warren <ben@skyportsystems.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-08-30s390x: introduce 2.11 compat machineCornelia Huck
Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2017-06-28migration: move skip_section_footersPeter Xu
Move it into MigrationState, revert its meaning and renaming it to send_section_footer, with a property bound to it. Same trick is played like previous patches. Removing savevm_skip_section_footers(). Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-9-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28migration: move skip_configuration outPeter Xu
It was in SaveState but now moved to MigrationState altogether, reverted its meaning, then renamed to "send_configuration". Again, using HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for xen_init(). Removing savevm_skip_configuration(). Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-8-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28migration: move global_state.optional outPeter Xu
Put it into MigrationState then we can use the properties to specify whether to enable storing global state. Removing global_state_set_optional() since now we can use HW_COMPAT_2_3 for x86/power, and AccelClass.global_props for Xen. Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-6-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-08hw/pcie: fix the generic pcie root port to support migrationMarcel Apfelbaum
Add msix state to pcie-root-ports's vmstate in order to support migration. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-25virtio_net: Bypass backends for MTU feature negotiationMaxime Coquelin
This patch adds a new internal "x-mtu-bypass-backend" property to bypass backends for MTU feature negotiation. When this property is set, the MTU feature is negotiated as soon as supported by the guest and a MTU value is set via the host_mtu parameter. In case the backend advertises the feature (e.g. DPDK's vhost-user backend), the feature negotiation is propagated down to the backend. When this property is not set, the backend has to support the MTU feature for its negotiation to succeed. For compatibility purpose, this property is disabled for machine types v2.9 and older. Cc: Aaron Conole <aconole@redhat.com> Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Vlad Yasevich <vyasevic@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-25intel_iommu: turn off pt before 2.9Peter Xu
This is for compatibility. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com>
2017-05-18Revert "hw/pci: disable pci-bridge's shpc by default"Marcel Apfelbaum
This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de. Disabling the shpc controller has an undesired side effect. The PCI bridge remains with no attached devices at boot time, and the guest operating systems do not allocate any resources for it, leaving the bridge unusable. Note that the behaviour is dictated by the pci bridge specification. Revert the commit and leave the shpc controller even if is not actually used by any architecture. Slot 0 remains unusable at boot time. Keep shpc off for QEMU 2.9 machines. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-04-21s390x: introduce 2.10 compat machineCornelia Huck
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-03-22hw/acpi/vmgenid: prevent device realization on pre-2.5 machine typesLaszlo Ersek
The WRITE_POINTER linker/loader command that underlies VMGENID depends on commit baf2d5bfbac0 ("fw-cfg: support writeable blobs", 2017-01-12), which in turn depends on fw_cfg DMA. DMA for fw_cfg is enabled in 2.5+ machine types only (see commit e6915b5f3a87, "fw_cfg: unbreak migration compatibility for 2.4 and earlier machines", 2016-02-18). Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Ben Warren <ben@skyportsystems.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Ben Warren <ben@skyportsystems.com <mailto:ben@skyportsystems.com>> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2017-03-16Merge remote-tracking branch 'remotes/kraxel/tags/pull-cirrus-20170316-1' ↵Peter Maydell
into staging cirrus: blitter fixes. # gpg: Signature made Thu 16 Mar 2017 09:05:22 GMT # gpg: using RSA key 0x4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/pull-cirrus-20170316-1: cirrus: stop passing around src pointers in the blitter cirrus: stop passing around dst pointers in the blitter cirrus: fix cirrus_invalidate_region cirrus: add option to disable blitter cirrus: switch to 4 MB video memory by default cirrus/vnc: zap bitblit support from console code. fix :cirrus_vga fix OOB read case qemu Segmentation fault # Conflicts: # include/hw/compat.h Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-03-16cirrus: switch to 4 MB video memory by defaultGerd Hoffmann
Quoting cirrus source code: Follow real hardware, cirrus card emulated has 4 MB video memory. Also accept 8 MB/16 MB for backward compatibility. So just use 4MB by default. We decided to leave that at 8MB by default a while ago, for live migration compatibility reasons. But we have compat properties to handle that, so that isn't a compeling reason. This also removes some sanity check inconsistencies in the cirrus code. Some places check against the allocated video memory, some places check against the 4MB physical hardware has. Guest code can trigger asserts because of that. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 1489494514-15606-1-git-send-email-kraxel@redhat.com
2017-03-16hw/virtio: fix Power Management Control Register for PCI Express virtio devicesMarcel Apfelbaum
Make Power Management State flag writable to conform with the PCI Express spec. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-03-16hw/virtio: fix Link Control Register for PCI Express virtio devicesMarcel Apfelbaum
Make several Link Control Register flags writable to conform with the PCI Express spec. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-03-16hw/virtio: fix error enabling flags in Device Control registerMarcel Apfelbaum
When the virtio devices are PCI Express, make error-enabling flags writable to respect the PCIe spec. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-03-16hw/pcie: fix Extended Configuration Space for devices with no Extended ↵Marcel Apfelbaum
Capabilities Absence of any Extended Capabilities is required to be indicated by an Extended Capability header with a Capability ID of 0000h, a Capability Version of 0h, and a Next Capability Offset of 000h. Instead of inserting a 'NULL' capability is simpler to mark the start of the Extended Configuration Space as read-only to achieve the same behaviour. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-02-01hw/pci: disable pci-bridge's shpc by defaultMarcel Apfelbaum
The shpc component is optional while ACPI hotplug is used for hot-plugging PCI devices into a PCI-PCI bridge. Disabling the shpc by default will make slot 0 usable at boot time and not only for hot-plug, without loosing any functionality. Older machines will have shpc enabled for compatibility reasons. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-01-27pflash_cfi01: fix per-device sector length in CFI tablePeter Maydell
For configurations of the pflash_cfi01 device which set it up with a device-width not equal to the width (ie where we are emulating multiple narrow flash devices wired up in parallel), we were giving incorrect values in the CFI data table: (1) the sector length entry should specify the sector length for a single device, not the length for the overall collection of devices (2) the number of blocks per device must not be divided by the number of devices because the resulting device size would not match the overall size (3) this then means that the overall write block size must be modified depending on the number of devices because the entry is per device and when the guest writes into the flash it calculates the write size by using the CFI entry (write size per device) multiplied by the number of chips. (It would alternatively be possible to modify the write block size in the CFI table (currently hardcoded at 2048) and leave the overall write block size alone.) This commit corrects these bugs, and adds a hw-compat property to retain the old behaviour on 2.8 and earlier versions. (The only board we have which uses this sort of flash config and has machine versioning is the "virt" board -- the PC uses a single flash device and so behaviour is unaffected whether using old-multiple-chip-handling or not.) Here is a configuration example from the vexpress board: VEXPRESS_FLASH_SIZE = 64M VEXPRESS_FLASH_SECT_SIZE 256K num-blocks = VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE = 256 sector-length = 256K width = 4 device-width = 2 The code will fill the CFI entry with the following entries: num-blocks = 256 sector-length = 128K writeblock_size = 2048 This results in two chips, each with 256 * 128K = 32M device size and a write block size of 2048. A sector erase will be sent to both chips, thus 256K must be erased. When the guest sends a block write command, it will write 4096 bytes data at once (2048 per device). Signed-off-by: David Engraf <david.engraf@sysgo.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: cleaned up and expanded commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-01-18fw-cfg: bump "x-file-slots" to 0x20 for 2.9+ machine typesLaszlo Ersek
More precisely, the "x-file-slots" count is bumped for all machine types that: (a) use fw_cfg, and (b) are not versioned (hence migration is not expected to work for them across QEMU releases anyway), or have version 2.9. This affects machine types implemented in the following source files: - "hw/arm/virt.c". The "virt-*" machine type is versioned, and the <= 2.8 versions already depend on HW_COMPAT_2_8 (see commit e353aac51b944). Therefore adding the "x-file-slots" compat values to HW_COMPAT_2_8 suffices. - "hw/i386/pc.c". The "pc-i440fx-*" (including "pc-*") and "pc-q35-*" machine types are versioned. Modifying HW_COMPAT_2_8 is sufficient here too (see commit "pc: Add 2.9 machine-types"). The "isapc" machtype is not versioned. The "xenfv" machine type, which uses fw_cfg for direct kernel booting, is also not versioned. - "hw/ppc/mac_newworld.c". The "mac99" machine type is not versioned. - "hw/ppc/mac_oldworld.c". The "g3beige" machine type is not versioned. - "hw/sparc/sun4m.c". None of the 9 machine types defined in this file appear versioned. - "hw/sparc64/sun4u.c". None of the 3 machine types defined in this file appear versioned. Cc: "Gabriel L. Somlo" <somlo@cmu.edu> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alexander Graf <agraf@suse.de> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Artyom Tarasenko <atar4qemu@gmail.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2016-12-27hw/arm/virt: add 2.9 machine typePeter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com>
2016-12-15virtio-pci: Fix cross-version migration with older machinesMaxime Coquelin
This patch fixes a cross-version migration regression introduced by commit d1b4259f ("virtio-bus: Plug devices after features are negotiated"). The problem is encountered when host's vhost backend does not support VIRTIO_F_VERSION_1, and migration is initiated from a v2.7 or prior machine with virtio-pci modern capabilities enabled to a v2.8 machine. In this case, modern capabilities get exposed to the guest by the source, whereas the target will detect version 1 is not supported so will only expose legacy capabilities. The problem is fixed by introducing a new "x-ignore-backend-features" property, which is set in v2.7 and prior compatibility modes. Doing this, v2.7 machine keeps its broken behaviour (enabling modern while version is not supported), and newer machines will behave correctly. Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-id: 20161214163035.3297-1-maxime.coquelin@redhat.com Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-17intel_iommu: reject broken EIMRadim Krčmář
Cluster x2APIC cannot work without KVM's x2apic API when the maximal APIC ID is greater than 8 and only KVM's LAPIC can support x2APIC, so we forbid other APICs and also the old KVM case with less than 9, to simplify the code. There is no point in enabling EIM in forbidden APICs, so we keep it enabled only for the KVM APIC; unconditionally, because making the option depend on KVM version would be a maintanance burden. Old QEMUs would enable eim whenever intremap was on, which would trick guests into thinking that they can enable cluster x2APIC even if any interrupt destination would get clamped to 8 bits. Depending on your configuration, QEMU could notice that the destination LAPIC is not present and report it with a very non-obvious: KVM: injection failed, MSI lost (Operation not permitted) Or the guest could say something about unexpected interrupts, because clamping leads to aliasing so interrupts were being delivered to incorrect VCPUs. KVM_X2APIC_API is the feature that allows us to enable EIM for KVM. QEMU 2.7 allowed EIM whenever interrupt remapping was enabled. In order to keep backward compatibility, we again allow guests to misbehave in non-obvious ways, and make it the default for old machine types. A user can enable the buggy mode it with "x-buggy-eim=on". Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-10-10virtio-serial: enable virtio console emergency write featureSascha Silbe
Add support for enabling the virtio 1.0 "emergency write" (VIRTIO_CONSOLE_F_EMERG_WRITE) feature. The previous patch introduced the plumbing required for this; now we expose the virtio feature to the guest. The feature is disabled for compatibility machines to avoid exposing a new feature to existing guests. As required by the virtio 1.0 spec, the emergency write functionality is available to the guest even if the guest doesn't negotatiate the feature, as well as before feature negotation. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-09-27x86: ioapic: boost default version to 0x20Peter Xu
It's 2.8 now, and maybe it's time to switch IOAPIC default version to 0x20. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1474608795-23058-1-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-09virtio-pci: reduce modern_mem_bar sizeMarcel Apfelbaum
Currently each VQ Notification Virtio Capability is allocated on a different page. The idea is to enable split drivers within guests, however there are no known plans to do that. The allocation will result in a 8MB BAR, more than various guest firmwares pre-allocates for PCI Bridges hotplug process. Reserve 4 bytes per VQ by default and add a new parameter "page-per-vq" to be used with split drivers. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-09-05s390x: add compat machine for 2.8Cornelia Huck
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-29hw/virtio-pci: fix virtio behaviourMarcel Apfelbaum
Enable transitional virtio devices by default. Enable virtio-1.0 for devices plugged into PCIe ports (Root ports or Downstream ports). Using the virtio-1 mode will remove the limitation of the number of devices that can be attached to a machine by removing the need for the IO BAR. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-07-29pcie: fix link active status bit migrationMichael S. Tsirkin
We changed link status register in pci express endpoint capability over time. Specifically, commit b2101eae63ea57b571cee4a9075a4287d24ba4a4 ("pcie: Set the "link active" in the link status register") set data link layer link active bit in this register without adding compatibility to old machine types. When migrating from qemu 2.3 and older this affects xhci devices which under machine type 2.0 and older have a pci express endpoint capability even if they are on a pci bus. Add compatibility flags to make this bit value match what it was under 2.3. Additionally, to avoid breaking migration from qemu 2.3 and up, suppress checking link status during migration: this seems sane since hardware can change link status at any time. https://bugzilla.redhat.com/show_bug.cgi?id=1352860 Reported-by: Gerd Hoffmann <kraxel@redhat.com> Fixes: b2101eae63ea57b571cee4a9075a4287d24ba4a4 ("pcie: Set the "link active" in the link status register") Cc: qemu-stable@nongnu.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-14virtio-mmio: format transport base address in BusClass.get_dev_pathLaszlo Ersek
At the moment the following QEMU command line triggers an assertion failure (minimal reproducer by Cole): qemu-system-aarch64 \ -machine virt-2.6,accel=tcg \ -nodefaults \ -no-user-config \ -nographic -monitor stdio \ -device virtio-scsi-device,id=scsi0 \ -device virtio-scsi-device,id=scsi1 \ -drive file=foo.img,format=raw,if=none,id=d0 \ -device scsi-hd,bus=scsi0.0,drive=d0 \ -drive file=foo.img,format=raw,if=none,id=d1 \ -device scsi-hd,bus=scsi1.0,drive=d1 qemu-system-aarch64: migration/savevm.c:615: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed. The reason is that the vmstate sections for the two scsi-hd devices are not uniquely identifiable by name. The direct parent buses of the scsi-hd devices -- scsi0.0 and scsi1.0 -- support the BusClass.get_dev_path member function. scsibus_get_dev_path() formats a device path prefix with the help of its topologically parent bus, and then appends the chan:id:lun triplet to it. For both scsi-hd devices, this triplet is 0:0:0. (Here we use "device path" in the QEMU migration sense, for vmstate section identification, not in the OFW or UEFI device path senses.) The virtio-scsi HBA is plugged into the virtio-mmio bus (implemented by the internal VirtIOMMIOProxy device). This bus class (TYPE_VIRTIO_MMIO_BUS) inherits, as its get_dev_path() member function, the virtio_bus_get_dev_path() method from its parent class (TYPE_VIRTIO_BUS). virtio_bus_get_dev_path() does not format any kind of device address on its own; "virtio addresses" are transport-specific. Therefore virtio_bus_get_dev_path() asks the topologically parent bus of the proxy object (implementing the specific virtio transport) to format the address of the proxy object. (For virtio-pci devices (where the proxy is an instance of VirtIOPCIProxy, plugged into a PCI bus), this ends up in pcibus_get_dev_path().) However, VirtIOMMIOProxy is usually (in practice: always) plugged into "main-system-bus", the singleton TYPE_SYSTEM_BUS object. This BusClass does not support formatting QEMU vmstate device paths at all (as SysBusDevice objects can have zero or more IO ports and zero or more MMIO regions). Hence the formatting request delegated from virtio_bus_get_dev_path() gets answered with NULL. The end result is that the two scsi-hd devices end up with the same device path "0:0:0", which triggers the assert. We can solve this by recognizing that virtio-mmio transports are distinguished from each other by their base addresses in MMIO address space. Implement virtio_mmio_bus_get_dev_path() as follows: (1) The virtio device whose devpath is to be formatted resides on a virtio-mmio bus that is implemented by a VirtIOMMIOProxy object. Ask the parent bus of VirtIOMMIOProxy to format the device path of VirtIOMMIOProxy, as a path prefix. (This is identical to what virtio_bus_get_dev_path() does.) (2) Append the base address of VirtIOMMIOProxy to the device path, such as: - virtio-mmio@000000000a003e00, - virtio-mmio@000000000a003c00. Given that these device paths are placed in the migration stream, step (2) above, if done unconditionally, would break migration. So make that step conditional on a new VirtIOMMIOProxy property, which is enabled for 2.7 machine types and later. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Cole Robinson <crobinso@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Kevin Zhao <kevin.zhao@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Tom Hanson <thomas.hanson@linaro.org> Reported-by: Kevin Zhao <kevin.zhao@linaro.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1467739394-28357-1-git-send-email-lersek@redhat.com Fixes: https://bugs.launchpad.net/qemu/+bug/1594239 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-05-17s390x: add compat machine for 2.7Cornelia Huck
Also add some of the option cascading we were missing. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-02-26fw_cfg: unbreak migration compatibility for 2.4 and earlier machinesLaszlo Ersek
When I reviewed Marc's fw_cfg DMA patches, I completely missed that the way we set dma_enabled would break migration. Gerd explained the right way (see reference below): dma_enabled should be set to true by default, and only true->false transitions should be possible: - when the user requests that with -global fw_cfg_mem.dma_enabled=off or -global fw_cfg_io.dma_enabled=off as appropriate for the platform, - when HW_COMPAT_2_4 dictates it, - when board code initializes fw_cfg without requesting DMA support. Cc: Marc Marí <markmb@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Alexandre DERUMIER <aderumier@odiso.com> Cc: qemu-stable@nongnu.org Ref: http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042 Ref: https://bugs.launchpad.net/qemu/+bug/1536487 Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1455823860-22268-1-git-send-email-lersek@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-01-25fdc: change auto fallback drive for ISA FDC to 288John Snow
The 2.88 drive is more suitable as a default because it can still read 1.44 images correctly, but the reverse is not true. Since there exist virtio-win drivers that are shipped on 2.88 floppy images, this patch will allow VMs booted without a floppy disk inserted to later insert a 2.88MB floppy and have that work. This patch has been tested with msdos, freedos, fedora, windows 8 and windows 10 without issue: if problems do arise for certain guests being unable to cope with 2.88MB drives as the default, they are in the minority and can use type=144 as needed (or insert a proper boot medium and omit type=144/288 or use type=auto) to obtain different drive types. As icing, the default will remain auto/144 for any pre-2.6 machine types, hopefully minimizing the impact of this change in legacy hw to basically zero. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 1453495865-9649-13-git-send-email-jsnow@redhat.com
2016-01-15vmw_pvscsi: x-disable-pcie, x-old-pci-configuration back-compat props are ↵Shmulik Ladkani
2.5 specific pvscsi's x-disable-pcie and x-old-pci-configuration backward compat properties were introduced in 952970b and d5da3ef: vmw_pvscsi: Introduce 'x-old-pci-configuration' backword compatability property vmw_pvscsi: Introduce 'x-disable-pcie' backword compatability property and were placed into HW_COMPAT_2_4. However since these commits were pulled post v2.5, move them to HW_COMPAT_2_5. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> Message-Id: <1450900558-20113-1-git-send-email-shmulik.ladkani@ravellosystems.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-11vmxnet3: Introduce 'x-disable-pcie' back-compat propertyShmulik Ladkani
Following the previous patch which changed vmxnet3 to be a pci express device, this patch introduces a boolean property 'x-disable-pcie' whose default is false. Setting 'x-disable-pcie' to 'on' preserves the old 'pci device' (non express) behavior. This allows migration to older versions. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2016-01-11vmxnet3: Introduce 'x-old-msi-offsets' back-compat propertyShmulik Ladkani
Following the previous patches, where vmxnet3's pci's msi/msix capability offsets and msix's PBA table offsets have been changed, this patch introduces a boolean property 'x-old-msi-offsets' to vmxnet3, whose default is false. Setting 'x-old-msi-offsets' to 'on' preserves the old offsets behavior, which allows migration to older versions. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2015-12-22hw/compat.h: Change indentation of HW_COMPAT_* to 4 spacesEduardo Habkost
Cosmetic change only. 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> Reviewed-by: Thomas Huth <thuth@redhat.com>
2015-12-22pc: Add pc-*-2.6 machine classesEduardo Habkost
Add pc-i440fx-2.6 and pc-q35-2.6 machine classes. 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> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2015-12-17vmw_pvscsi: Introduce 'x-disable-pcie' backword compatability propertyShmulik Ladkani
Following the previous patch which changed pvscsi to be a pci express device, this patch introduces a boolean property 'x-disable-pcie'. Its default value is false, exposing pvscsi as a pcie device. Setting 'x-disable-pcie' to 'on' preserves the old 'pci device' (non express) behavior. This allows migration to older versions. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> Message-Id: <1449994112-7054-7-git-send-email-shmulik.ladkani@ravellosystems.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17vmw_pvscsi: Introduce 'x-old-pci-configuration' backword compatability propertyShmulik Ladkani
Following the previous patches, which introduced various changes in pvscsi's pci configuration space (device subsystem id and revision, msi offset), this patch introduces a boolean property 'x-old-pci-configuration' to pvscsi. Its default value is false, exposing the above changes in the pci config space. Setting 'x-old-pci-configuration' to 'on' preserves the old behavior, which allows migration to older versions. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com> Message-Id: <1449994112-7054-4-git-send-email-shmulik.ladkani@ravellosystems.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-11-12Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio, vhost: fixes for 2.5 This fixes a performance regression with virtio 1, and makes device stop/start more robust for vhost-user. virtio devices on pcie bus now have pcie and pm capability, as required by the PCI Express spec. migration now works better with virtio 9p. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Thu 12 Nov 2015 14:40:42 GMT using RSA key ID D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" * remotes/mst/tags/for_upstream: virtio-9p: add savem handlers hw/virtio: Add PCIe capability to virtio devices vhost: send SET_VRING_ENABLE at start/stop vhost: rename RESET_DEVICE backto RESET_OWNER vhost-user: modify SET_LOG_BASE to pass mmap size and offset virtio-pci: unbreak queue_enable read virtio-pci: introduce pio notification capability for modern device virtio-pci: use zero length mmio eventfd for 1.0 notification cap when possible KVM: add support for any length io eventfd memory: don't try to adjust endianness for zero length eventfd virtio-pci: fix 1.0 virtqueue migration Conflicts: include/hw/compat.h [Fixed a trivial merge conflict in compat.h] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-11-12hw/virtio: Add PCIe capability to virtio devicesMarcel Apfelbaum
The virtio devices are converted to PCI-Express if they are plugged into a PCI-Express bus and the 'modern' protocol is enabled. Devices plugged directly into the Root Complex as Integrated Endpoints remain PCI. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-02 07:42:16 +0000