aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-04-27acpi, mem-hotplug: add unplug request cb for memory deviceTang Chen
This patch adds unplug request cb for memory device, and adds the is_removing boolean field to MemStatus. This field is used to indicate whether the memory device in slot has been requested to be ejected. This field is set to true in acpi_memory_unplug_request_cb(). Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27acpi, mem-hotplug: add acpi_memory_slot_status() to get MemStatusTang Chen
Add a new API named acpi_memory_slot_status() to obtain a single memory slot status. Doing this is because this procedure will be used by other functions in the next coming patches. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27docs: update documentation for memory hot unplugZhu Guihua
Add specification about how to use memory hot unplug, and add a flow diagram to explain memory hot unplug process. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27virtio: coding style tweakMichael S. Tsirkin
no space needed after *. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27pci: remove hard-coded bar size in msix_init_exclusive_bar()Jason Wang
This patch lets msix_init_exclusive_bar() can calculate the bar and pba size based on the number of MSI-X vectors other than using a hard-coded limit 4096. This is needed to allow device to have more than 128 MSI_X vectors. To keep migration compatibility, keep using 4096 as bar size and 2048 for pba offset. Notes: We don't care about the case that using vectors > 128 for legacy machine type. Since we limit the queue max to 64, so vectors >= 65 is meaningless. Virtio device will be the first user for this. Cc: Keith Busch <keith.busch@intel.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27virtio-pci: speedup MSI-X masking and unmaskingJason Wang
This patch tries to speed up the MSI-X masking and unmasking through the mapping between vector and queues. With this patch it will there's no need to go through all possible virtqueues, which may help to reduce the time spent when doing MSI-X masking/unmasking a single vector when more than hundreds or even thousands of virtqueues were supported. Tested with 80 queue pairs virito-net-pci by changing the smp affinity in the background and doing netperf in the same time: Before the patch: 5711.70 Gbits/sec After the patch: 6830.98 Gbits/sec About 19.6% improvements in throughput. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27virtio: introduce vector to virtqueues mappingJason Wang
Currently we will try to traverse all virtqueues to find a subset that using a specific vector. This is sub optimal when we will support hundreds or even thousands of virtqueues. So this patch introduces a method which could be used by transport to get all virtqueues that using a same vector. This is done through QLISTs and the number of QLISTs was queried through a transport specific method. When guest setting vectors, the virtqueue will be linked and helpers for traverse the list was also introduced. The first user will be virtio pci which will use this to speed up MSI-X masking and unmasking handling. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueueJason Wang
It's a bad idea to need to use vector 0 for invalid virtqueue. So this patch changes to using VIRTIO_NO_VECTOR instead. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> CC: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Alexander Graf <agraf@suse.de> Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27monitor: check return value of qemu_find_net_clients_except()Jason Wang
qemu_find_net_clients_except() may return a value which is greater than the size of array we provided. So we should check this value before using it, otherwise this may cause unexpected memory access. This patch fixes the net related command completion when we have a virtio-net nic with more than 255 queues. Cc: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27monitor: replace the magic number 255 with MAX_QUEUE_NUMJason Wang
This patch replace the magic number 255, and increase it to MAX_QUEUE_NUM which is maximum number of queues supported by a nic. Cc: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27ppc: spapr: add 2.4 machine typeJason Wang
The following patches will limit the following things to legacy machine type: - maximum number of virtqueues for virtio-pci were limited to 64 Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alexander Graf <agraf@suse.de>
2015-04-27spapr: add machine type specific instance init functionJason Wang
This patches adds machine type specific instance initialization functions. Those functions will be used by following patches to compat class properties for legacy machine types. Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27pc: add 2.4 machine typesJason Wang
The following patches will limit the following things to legacy machine type: - maximum number of virtqueues for virtio-pci were limited to 64 - auto msix bar size for virtio-net-pci were disabled by default Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27virtio-net: fix the upper bound when trying to delete queuesJason Wang
Virtqueue were indexed from zero, so don't delete virtqueue whose index is n->max_queues * 2 + 1. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27vhost-user: Send VHOST_RESET_OWNER on vhost stopLuke Gorrie
Ensure that the vhost-user slave knows when the vrings are valid and when they are invalid, for example during a guest reboot. The vhost-user protocol says this of VHOST_RESET_OWNER: Issued when a new connection is about to be closed. The Master will no longer own this connection (and will usually close it). Send this message to tell the vhost-user slave that the vhost session has ended and that session state (e.g. vrings) is no longer valid. Signed-off-by: Luke Gorrie <luke@snabb.co> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27hw/i386/acpi-build: move generic acpi building helpers into dedictated fileShannon Zhao
Move generic acpi building helpers into dedictated file and this can be shared with other machines. Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27hw/i386: Move ACPI header definitions in an arch-independent locationShannon Zhao
The ACPI related header file acpi-defs.h, includes definitions that apply on other architectures as well. Move it in `include/hw/acpi/` to sanely include it from other architectures. Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27acpi-build: close } in commentMichael S. Tsirkin
missing } confuses editors Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-27Merge remote-tracking branch 'remotes/qmp-unstable/tags/for-upstream' into ↵Peter Maydell
staging Four little fixes # gpg: Signature made Fri Apr 24 19:56:51 2015 BST using RSA key ID E24ED5A7 # gpg: Good signature from "Luiz Capitulino <lcapitulino@gmail.com>" * remotes/qmp-unstable/tags/for-upstream: qmp: Give saner messages related to qmp_capabilities misuse qmp-commands: fix incorrect uses of ":O" specifier qapi: Drop dead genlist parameter balloon: improve error msg when adding second device Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-25Open 2.4 development treePeter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-24qmp: Give saner messages related to qmp_capabilities misuseEric Blake
Pretending that QMP doesn't understand a command merely because we are not in the right mode doesn't help first-time users figure out what to do to correct things. Although the documentation for QMP calls out capabilities negotiation, we should also make it clear in our error messages what we were expecting. With this patch, I now get the following transcript: $ ./x86_64-softmmu/qemu-system-x86_64 -qmp stdio -nodefaults {"QMP": {"version": {"qemu": {"micro": 93, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}} {"execute":"huh"} {"error": {"class": "CommandNotFound", "desc": "The command huh has not been found"}} {"execute":"quit"} {"error": {"class": "CommandNotFound", "desc": "Expecting capabilities negotiation with 'qmp_capabilities' before command 'quit'"}} {"execute":"qmp_capabilities"} {"return": {}} {"execute":"qmp_capabilities"} {"error": {"class": "CommandNotFound", "desc": "Capabilities negotiation is already complete, command 'qmp_capabilities' ignored"}} {"execute":"quit"} {"return": {}} {"timestamp": {"seconds": 1429110729, "microseconds": 181935}, "event": "SHUTDOWN"} Signed-off-by: Eric Blake <eblake@redhat.com> Tested-By: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Paulo Vital <paulo.vital@profitbricks.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2015-04-24qmp-commands: fix incorrect uses of ":O" specifierPaolo Bonzini
As far as the QMP parser is concerned, neither the 'O' nor the 'q' format specifiers put any constraint on the command. However, there are two differences: 1) from a documentation point of view 'O' says that this command takes a dictionary. The dictionary will be converted to QemuOpts in the handler to match the corresponding HMP command. 2) 'O' sets QMP_ACCEPT_UNKNOWNS, resulting in the command accepting invalid extra arguments. For example the following is accepted: { "execute": "send-key", "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" }, { "type": "qcode", "data": "alt" }, { "type": "qcode", "data": "delete" } ], "foo": "bar" } } Neither send-key nor migrate-set-capabilities take a QemuOpts-like dictionary; they take an array of dictionaries. And neither command really wants to have extra unknown arguments. Thus, the right specifier to use in this case is 'q'; with this patch the above command fails with {"error": {"class": "GenericError", "desc": "Invalid parameter 'foo'"}} as intended. Reported-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2015-04-24qapi: Drop dead genlist parameterEric Blake
Defaulting a parameter to True, then having all callers omit or pass an explicit True for that parameter, is pointless. Looks like it has been dead since introduction in commit 06d64c6, more than 4 years ago. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2015-04-24balloon: improve error msg when adding second deviceLuiz Capitulino
A VM supports only one balloon device, but due to several changes in infrastructure the error message got messed up when trying to add a second device. Fix it. Before this fix Command-line: qemu-qmp: -device virtio-balloon-pci,id=balloon0: Another balloon device already registered qemu-qmp: -device virtio-balloon-pci,id=balloon0: Adding balloon handler failed qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized HMP: Another balloon device already registered Adding balloon handler failed Device 'virtio-balloon-pci' could not be initialized QMP: { "execute": "device_add", "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } } { "error": { "class": "GenericError", "desc": "Adding balloon handler failed" } } After this fix Command-line: qemu-qmp: -device virtio-balloon-pci,id=balloon0: Only one balloon device is supported qemu-qmp: -device virtio-balloon-pci,id=balloon0: Device 'virtio-balloon-pci' could not be initialized HMP: (qemu) device_add virtio-balloon-pci,id=balloon0 Only one balloon device is supported Device 'virtio-balloon-pci' could not be initialized (qemu) QMP: { "execute": "device_add", "arguments": { "driver": "virtio-balloon-pci", "id": "balloon0" } } { "error": { "class": "GenericError", "desc": "Only one balloon device is supported" } } Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-04-24Update version for v2.3.0 releasev2.3.0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20Update version for v2.3.0-rc4 releasev2.3.0-rc4Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20vhost: fix log base addressMichael S. Tsirkin
VHOST_SET_LOG_BASE got an incorrect address, causing migration errors and potentially even memory corruption. Reported-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amos Kong <akong@redhat.com> Message-id: 1429283565-32265-1-git-send-email-mst@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17hmp: fix crash in 'info block -n -v'Alberto Garcia
The image field in BlockDeviceInfo should never be null, however bdrv_block_device_info() is not filling it in. This makes the 'info block -n -v' command crash QEMU. The proper solution is probably to move the relevant code from bdrv_query_info() to bdrv_block_device_info(), but since we're too close to the release for that this simpler workaround solves the crash. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-id: 1429274688-8115-1-git-send-email-berto@igalia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150417-2' into stagingPeter Maydell
MIPS patches 2015-04-17 Changes: * fix broken fulong2e # gpg: Signature made Fri Apr 17 12:14:37 2015 BST using RSA key ID 0B29DA6B # gpg: Can't check signature: public key not found * remotes/lalrae/tags/mips-20150417-2: mips: fix broken fulong2e machine Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17Merge remote-tracking branch 'remotes/kraxel/tags/pull-fwcfg-20150414-1' ↵Peter Maydell
into staging fw_cfg: add documentation file (docs/specs/fw_cfg.txt) # gpg: Signature made Tue Apr 14 12:22:20 2015 BST using RSA key ID D3E87138 # 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>" * remotes/kraxel/tags/pull-fwcfg-20150414-1: fw_cfg: add documentation file (docs/specs/fw_cfg.txt) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17mips: fix broken fulong2e machinePaolo Bonzini
After commit 5312bd8 the bonito_readl() and bonito_writel() have been accessing incorrect addresses. Consequently QEMU is crashing when trying to boot Linux kernel on fulong2e machine. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
2015-04-17target-ppc: don't invalidate msr MSR_HVB bit in cpu_post_loadMark Cave-Ayland
The invalidation code introduced in commit 2360b works by inverting most bits of env->msr to ensure that hreg_store_msr() will forcibly update the CPU env state to reflect the new msr value post-migration. Unfortunately hreg_store_msr() is called with alter_hv set to 0 which preserves the MSR_HVB state from the CPU env which is now the opposite value to what it should be. Ensure that we don't invalidate the msr MSR_HVB bit during cpu_post_load so that the correct value is restored. This fixes suspend/resume for PPC64. Reported-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Alexander Graf <agraf@suse.de> Message-id: 1429255009-12751-1-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-14fw_cfg: add documentation file (docs/specs/fw_cfg.txt)Gabriel L. Somlo
This document covers the guest-side hardware interface, as well as the host-side programming API of QEMU's firmware configuration (fw_cfg) device. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-04-13Update version for v2.3.0-rc3 releasev2.3.0-rc3Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-13Revert seccomp tests that allow it to be used on non-x86 architecturesPeter Maydell
Unfortunately it turns out that libseccomp 2.2 still does not work correctly on non-x86 architectures; return to the previous configure setup of insisting on libseccomp 2.1 or better and i386/x86_64 and disabling seccomp support in all other situations. This reverts the two commits: * "seccomp: libseccomp version varying according to arch" (commit 896848f0d3e2393905845ef2b244bb2601f9df0c) * "seccomp: update libseccomp version and remove arch restriction" (commit 8e27fc200457e3f2473d0069263774d4ba17bd85) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org
2015-04-13pci: Fix crash with illegal "-net nic, model=xxx" optionThomas Huth
Current QEMU crashes when specifying an illegal model with the "-net nic,model=xxx" option, e.g.: $ qemu-system-x86_64 -net nic,model=n/a qemu-system-x86_64: Unsupported NIC model: n/a Program received signal SIGSEGV, Segmentation fault. The gdb backtrace looks like this: 0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152 152 return err->msg; (gdb) bt 0 0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152 1 0x0000555555965ffd in error_report_err (err=0x0) at util/error.c:157 2 0x0000555555809c90 in pci_nic_init_nofail (nd=0x555555e49860 <nd_table>, rootbus=0x5555564409b0, default_model=0x55555598c37b "e1000", default_devaddr=0x0) at hw/pci/pci.c:1663 3 0x0000555555691e42 in pc_nic_init (isa_bus=0x555556f71900, pci_bus=0x5555564409b0) at hw/i386/pc.c:1506 4 0x000055555569396b in pc_init1 (machine=0x5555562abbf0, pci_enabled=1, kvmclock_enabled=1) at hw/i386/pc_piix.c:248 5 0x0000555555693d27 in pc_init_pci (machine=0x5555562abbf0) at hw/i386/pc_piix.c:310 6 0x000055555572ddf5 in main (argc=3, argv=0x7fffffffe018, envp=0x7fffffffe038) at vl.c:4226 The problem is that pci_nic_init_nofail() does not check whether the err parameter from pci_nic_init has been set up and thus passes a NULL pointer to error_report_err(). Fix it by correctly checking the err parameter. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-13stm32f205: Fix SoC type nameAndreas Färber
The type name for the SoC device, unlike those of its sub-devices, did not follow the QOM naming conventions. While the usage is internal only, this is exposed through QMP and HMP, so fix it before release. Cc: Alistair Francis <alistair.francis@xilinx.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alistair Francis <alistair@alistair23.me> Message-id: 1428676676-23056-1-git-send-email-afaerber@suse.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-11cris: memory: Replace memory_region_init_ram with ↵Dirk Müller
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com> Signed-off-by: Dirk Mueller <dmueller@suse.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2015-04-10alpha: memory: Replace memory_region_init_ram with ↵Dirk Müller
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Dirk Mueller <dmueller@suse.com> Acked-by: Richard Henderson <rth@twiddle.net> Message-id: CAL5wTH64_ykF17cw2T1Axq8P3vCWm=6WbUJ3qJrLF-u+-MmzUw@mail.gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-10lm32: memory: Replace memory_region_init_ram with ↵Dirk Müller
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Cc: Michael Walle <michael@walle.cc> Signed-off-by: Dirk Mueller <dmueller@suse.com> Acked-by: Michael Walle <michael@walle.cc> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09xen: limit guest control of PCI command registerJan Beulich
Otherwise the guest can abuse that control to cause e.g. PCIe Unsupported Request responses (by disabling memory and/or I/O decoding and subsequently causing [CPU side] accesses to the respective address ranges), which (depending on system configuration) may be fatal to the host. This is CVE-2015-2756 / XSA-126. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Message-id: alpine.DEB.2.02.1503311510300.7690@kaball.uk.xensource.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09configure: disable Archipelago by default and warn about libxseg GPLv3 licenseStefan Hajnoczi
libxseg has changed license to GPLv3. QEMU includes GPL "v2 only" code which is not compatible with GPLv3. This means the resulting binaries may not be redistributable! Disable Archipelago (libxseg) by default to prevent accidental license violations. Also warn if linking against libxseg is enabled to remind the user. Note that this commit does not constitute any advice about software licensing. If you have doubts you should consult a lawyer. Cc: Chrysostomos Nanakos <cnanakos@grnet.gr> Suggested-by: Kevin Wolf <kwolf@redhat.com> Reported-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Message-id: 1428587538-8765-1-git-send-email-stefanha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell
staging # gpg: Signature made Thu Apr 9 10:55:11 2015 BST using RSA key ID 81AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" * remotes/stefanha/tags/block-pull-request: block/iscsi: handle zero events from iscsi_which_events aio: strengthen memory barriers for bottom half scheduling virtio-blk: correctly dirty guest memory qcow2: Fix header update with overridden backing file Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09tcg/tcg-op.c: Fix ld/st of 64 bit values on 32-bit bigendian hostsPeter Maydell
Commit 951c6300f7 out-of-lined the 32-bit-host versions of tcg_gen_{ld,st}_i64, but in the process it inadvertently changed an #ifdef HOST_WORDS_BIGENDIAN to #ifdef TCG_TARGET_WORDS_BIGENDIAN. Since the latter doesn't get defined anywhere this meant we always took the "LE host" codepath, and stored the two halves of the value in the wrong order on BE hosts. This typically breaks any 64-bit guest on a 32-bit BE host completely, and will have possibly more subtle effects even for 32-bit guests. Switch the ifdef back to HOST_WORDS_BIGENDIAN. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Tested-by: Andreas Färber <afaerber@suse.de> Message-id: 1428523029-13620-1-git-send-email-peter.maydell@linaro.org
2015-04-09block/iscsi: handle zero events from iscsi_which_eventsPeter Lieven
newer libiscsi versions may return zero events from iscsi_which_events. In this case iscsi_service will return immediately without any progress. To avoid busy waiting for iscsi_which_events to change we deregister all read and write handlers in this case and schedule a timer to periodically check iscsi_which_events for changed events. Next libiscsi version will introduce async reconnects and zero events are returned while libiscsi is waiting for a reconnect retry. Signed-off-by: Peter Lieven <pl@kamp.de> Message-id: 1428437295-29577-1-git-send-email-pl@kamp.de Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-09aio: strengthen memory barriers for bottom half schedulingPaolo Bonzini
There are two problems with memory barriers in async.c. The fix is to use atomic_xchg in order to achieve sequential consistency between the scheduling of a bottom half and the corresponding execution. First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does not execute a memory barrier to order any writes needed by the callback before the read of bh->scheduled. If the other side sees req->state as THREAD_ACTIVE, the callback is not invoked and you get deadlock. Second, the memory barrier in aio_bh_poll is too weak. Without this patch, it is possible that bh->scheduled = 0 is not "published" until after the callback has returned. Another thread wants to schedule the bottom half, but it sees bh->scheduled = 1 and does nothing. This causes a lost wakeup. The memory barrier should have been changed to smp_mb() in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition, 2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed that patch? Both of these involve a store and a load, so they are reproducible on x86_64 as well. It is however much easier on aarch64, where the libguestfs test suite triggers the bug fairly easily. Even there the failure can go away or appear depending on compiler optimization level, tracing options, or even kernel debugging options. Paul Leveille however reported how to trigger the problem within 15 minutes on x86_64 as well. His (untested) recipe, reproduced here for reference, is the following: 1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem. 2) Use “cache=directsync” rather than the default of “cache=none” to make it happen easier. 3) Use a server with a write-back RAID controller to allow for rapid IO rates. 4) Run a random-access load that (mostly) writes chunks to various files on the virtual block device. a. I use ‘diskload.exe c:25’, a Microsoft HCT load generator, on Windows VMs. b. Iometer can probably be configured to generate a similar load. 5) Run multiple VMs in parallel, against the same storage device, to shake the failure out sooner. 6) IvyBridge and Haswell processors for certain; not sure about others. A similar patch survived over 12 hours of testing, where an unpatched QEMU would fail within 15 minutes. This bug is, most likely, also the cause of failures in the libguestfs testsuite on AArch64. Thanks to Laszlo Ersek for initially reporting this bug, to Stefan Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to Paul for providing test input and a prototype patch. Reported-by: Laszlo Ersek <lersek@redhat.com> Reported-by: Paul Leveille <Paul.Leveille@stratus.com> Reported-by: John Snow <jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com Suggested-by: Paul Leveille <Paul.Leveille@stratus.com> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-08arm: memory: Replace memory_region_init_ram with ↵Dirk Müller
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Dirk Mueller <dmueller@suse.com> Message-id: CAL5wTH4UHYKpJF=dLJfFzxpufjY189chnCow47-ySuLf8GLbug@mail.gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-08virtio-blk: correctly dirty guest memoryPaolo Bonzini
After qemu_iovec_destroy, the QEMUIOVector's size is zeroed and the zero size ultimately is used to compute virtqueue_push's len argument. Therefore, reads from virtio-blk devices did not migrate their results correctly. (Writes were okay). Save the size in virtio_blk_handle_request, and use it when the request is completed. Based on a patch by Wen Congyang. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Li Zhijian <lizhijian@cn.fujitsu.com> Message-id: 1427997044-392-1-git-send-email-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-08qcow2: Fix header update with overridden backing fileKevin Wolf
In recent qemu versions, it is possible to override the backing file name and format that is stored in the image file with values given at runtime. In such cases, the temporary override could end up in the image header if the qcow2 header was updated, while obviously correct behaviour would be to leave the on-disk backing file path/format unchanged. Fix this and add a test case for it. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1428411796-2852-1-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07Merge remote-tracking branch ↵Peter Maydell
'remotes/mjt/tags/pull-trivial-patches-2015-04-04' into staging trivial patches for 2015-04-04 # gpg: Signature made Sat Apr 4 08:07:49 2015 BST using RSA key ID A4C3D7DB # gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>" # gpg: aka "Michael Tokarev <mjt@corpit.ru>" # gpg: aka "Michael Tokarev <mjt@debian.org>" * remotes/mjt/tags/pull-trivial-patches-2015-04-04: vhost: fix typo in vq_index description gitignore: Ignore more .pod files. target-tricore: Fix check which was always false target-i386: remove superfluous TARGET_HAS_SMC macro pcspk: Fix I/O port name Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-25 08:17:12 +0000