qemu/include/hw/compat.h

217 lines
5.4 KiB
C
Raw Normal View History

#ifndef HW_COMPAT_H
#define HW_COMPAT_H
#define HW_COMPAT_2_9 \
{\
.driver = "pci-bridge",\
.property = "shpc",\
.value = "off",\
},{\
.driver = "intel-iommu",\
.property = "pt",\
.value = "off",\
},{\
.driver = "virtio-net-device",\
.property = "x-mtu-bypass-backend",\
.value = "off",\
},
#define HW_COMPAT_2_8 \
fw-cfg: bump "x-file-slots" to 0x20 for 2.9+ machine types 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>
2017-01-12 21:24:17 +03:00
{\
.driver = "fw_cfg_mem",\
.property = "x-file-slots",\
.value = stringify(0x10),\
},{\
.driver = "fw_cfg_io",\
.property = "x-file-slots",\
.value = stringify(0x10),\
pflash_cfi01: fix per-device sector length in CFI table 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-27 18:20:22 +03:00
},{\
.driver = "pflash_cfi01",\
.property = "old-multiple-chip-handling",\
.value = "on",\
},{\
.driver = "pci-bridge",\
.property = "shpc",\
.value = "on",\
},{\
.driver = TYPE_PCI_DEVICE,\
.property = "x-pcie-extcap-init",\
.value = "off",\
},{\
.driver = "virtio-pci",\
.property = "x-pcie-deverr-init",\
.value = "off",\
},{\
.driver = "virtio-pci",\
.property = "x-pcie-lnkctl-init",\
.value = "off",\
},{\
.driver = "virtio-pci",\
.property = "x-pcie-pm-init",\
.value = "off",\
},{\
.driver = "cirrus-vga",\
.property = "vgamem_mb",\
.value = "8",\
},{\
.driver = "isa-cirrus-vga",\
.property = "vgamem_mb",\
.value = "8",\
fw-cfg: bump "x-file-slots" to 0x20 for 2.9+ machine types 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>
2017-01-12 21:24:17 +03:00
},
#define HW_COMPAT_2_7 \
{\
.driver = "virtio-pci",\
.property = "page-per-vq",\
.value = "on",\
},{\
.driver = "virtio-serial-device",\
.property = "emergency-write",\
.value = "off",\
},{\
.driver = "ioapic",\
.property = "version",\
.value = "0x11",\
intel_iommu: reject broken EIM 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-10 18:28:47 +03:00
},{\
.driver = "intel-iommu",\
.property = "x-buggy-eim",\
.value = "true",\
virtio-pci: Fix cross-version migration with older machines 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-12-14 19:30:35 +03:00
},{\
.driver = "virtio-pci",\
.property = "x-ignore-backend-features",\
.value = "on",\
},
#define HW_COMPAT_2_6 \
virtio-mmio: format transport base address in BusClass.get_dev_path 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-07-14 18:51:36 +03:00
{\
.driver = "virtio-mmio",\
.property = "format_transport_address",\
.value = "off",\
},{\
.driver = "virtio-pci",\
.property = "disable-modern",\
.value = "on",\
},{\
.driver = "virtio-pci",\
.property = "disable-legacy",\
.value = "off",\
virtio-mmio: format transport base address in BusClass.get_dev_path 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-07-14 18:51:36 +03:00
},
#define HW_COMPAT_2_5 \
{\
.driver = "isa-fdc",\
.property = "fallback",\
.value = "144",\
},{\
.driver = "pvscsi",\
.property = "x-old-pci-configuration",\
.value = "on",\
},{\
.driver = "pvscsi",\
.property = "x-disable-pcie",\
.value = "on",\
},\
{\
.driver = "vmxnet3",\
.property = "x-old-msi-offsets",\
.value = "on",\
},{\
.driver = "vmxnet3",\
.property = "x-disable-pcie",\
.value = "on",\
},
#define HW_COMPAT_2_4 \
{\
.driver = "virtio-blk-device",\
.property = "scsi",\
.value = "true",\
},{\
.driver = "e1000",\
.property = "extra_mac_registers",\
.value = "off",\
},{\
.driver = "virtio-pci",\
.property = "x-disable-pcie",\
.value = "on",\
},{\
.driver = "virtio-pci",\
.property = "migrate-extra",\
.value = "off",\
},{\
.driver = "fw_cfg_mem",\
.property = "dma_enabled",\
.value = "off",\
},{\
.driver = "fw_cfg_io",\
.property = "dma_enabled",\
.value = "off",\
},{\
.driver = "vmgenid",\
.property = "x-write-pointer-available",\
.value = "off",\
},
#define HW_COMPAT_2_3 \
{\
.driver = "virtio-blk-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = "virtio-balloon-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = "virtio-serial-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = "virtio-9p-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = "virtio-rng-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = TYPE_PCI_DEVICE,\
.property = "x-pcie-lnksta-dllla",\
.value = "off",\
},
#define HW_COMPAT_2_2 \
/* empty */
#define HW_COMPAT_2_1 \
{\
.driver = "intel-hda",\
.property = "old_msi_addr",\
.value = "on",\
},{\
.driver = "VGA",\
.property = "qemu-extended-regs",\
.value = "off",\
},{\
.driver = "secondary-vga",\
.property = "qemu-extended-regs",\
.value = "off",\
},{\
.driver = "virtio-scsi-pci",\
.property = "any_layout",\
.value = "off",\
},{\
.driver = "usb-mouse",\
.property = "usb_version",\
.value = stringify(1),\
},{\
.driver = "usb-kbd",\
.property = "usb_version",\
.value = stringify(1),\
},{\
.driver = "virtio-pci",\
.property = "virtio-pci-bus-master-bug-migration",\
.value = "on",\
},
#endif /* HW_COMPAT_H */