aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-05-11acpi: update expected files for memory unplugMichael S. Tsirkin6-0/+0
commit c06b2ffb02bfcc642c67300d2c4dffd5aa54932b acpi: add hardware implementation for memory hot unplug Changed both the DSDT and the SSDT. Update the expected files accordingly. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-04-28virtio-scsi: Move DEFINE_VIRTIO_SCSI_FEATURES to virtio-scsiShannon Zhao5-3/+6
So far virtio-scsi-device can't expose host features to guest while using virtio-mmio because it doesn't set DEFINE_VIRTIO_SCSI_FEATURES on backend or transport. The host features belong to the backends while virtio-scsi-pci, virtio-scsi-s390 and virtio-scsi-ccw set the DEFINE_VIRTIO_SCSI_FEATURES on transports. But they already have the ability to forward property accesses to the backend child. So if we move the host features to backends, it doesn't break the backwards compatibility for them and make host features work while using virtio-mmio. Move DEFINE_VIRTIO_SCSI_FEATURES to the backend virtio-scsi. The transports just sync the host features from backends. 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> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-28virtio-net: Move DEFINE_VIRTIO_NET_FEATURES to virtio-netShannon Zhao5-8/+7
So far virtio-net-device can't expose host features to guest while using virtio-mmio because it doesn't set DEFINE_VIRTIO_NET_FEATURES on backend or transport. So the performance is low. The host features belong to the backend while virtio-net-pci, virtio-net-s390 and virtio-net-ccw set the DEFINE_VIRTIO_NET_FEATURES on transports. But they already have the ability to forward property accesses to the backend child. So if we move the host features to backends, it doesn't break the backwards compatibility for them and make host features work while using virtio-mmio. Here we move DEFINE_VIRTIO_NET_FEATURES to the backend virtio-net. The transports just sync the host features from backend. Meanwhile move virtio_net_set_config_size to virtio-net to make sure the config size is correct and don't expose it. 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> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-28pci: Merge pci_nic_init() into pci_nic_init_nofail()Thomas Huth1-29/+14
The error reporting in pci_nic_init() is quite erratic: Some errors are printed directly with error_report(), and some are passed back to the caller pci_nic_init_nofail() via an Error pointer. Since pci_nic_init() is only used by pci_nic_init_nofail(), the functions can be simply merged to clean up this inconsistency. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2015-04-28acpi: add a missing backslash to the \_SB scope.Gal Hammer2-2/+2
A predefined scope in the ACPI specs is precede with a backslash. Signed-off-by: Gal Hammer <ghammer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2015-04-27qmp-event: add event notification for memory hot unplug errorZhu Guihua4-1/+41
When memory hot unplug fails, this patch adds support to send QMP event to notify mgmt about this failure. 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-27acpi: add hardware implementation for memory hot unplugZhu Guihua8-5/+61
- implements QEMU hardware part of memory hot unplug protocol described at "docs/spec/acpi_mem_hotplug.txt" - handles memory remove notification event - handles device eject notification 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-27acpi: fix "Memory device control fields" registerZhu Guihua2-2/+5
0 bit in Memory device control fields must be cleared before writing to register. But now this field isn't cleared when other fields are written. To solve this bug, This patch fixes UpdateRule to WriteAsZeros in "Memory device control fields" register. 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-27acpi: extend aml_field() to support UpdateRuleZhu Guihua3-8/+19
The flags field is declared with default update rule 'Preserve', this patch extends aml_field() to support UpdateRule so that we can specify different values per field. 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-27acpi, mem-hotplug: add unplug cb for memory deviceTang Chen5-6/+64
This patch adds unplug cb for memory device. It resets memory status "is_enabled" in acpi_memory_unplug_cb(), removes the corresponding memory region, unregisters vmstate, and unparents the object. 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 unplug request cb for memory deviceTang Chen5-5/+68
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 Chen1-6/+28
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 Guihua2-4/+61
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. Tsirkin1-1/+1
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 Wang1-11/+19
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 Wang1-19/+21
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 Wang4-2/+46
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 Wang1-1/+1
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 Wang1-4/+4
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 Wang1-7/+10
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 Wang1-2/+29
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 Wang1-0/+23
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 Wang2-7/+48
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 Wang1-1/+1
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 Gorrie1-0/+7
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 Zhao3-77/+87
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 Zhao3-2/+2
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. Tsirkin1-1/+1
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 Maydell5-21/+31
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 Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-24qmp: Give saner messages related to qmp_capabilities misuseEric Blake1-4/+19
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 Bonzini1-2/+2
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 Blake1-13/+9
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 Capitulino2-2/+1
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 Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20Update version for v2.3.0-rc4 releasev2.3.0-rc4Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20vhost: fix log base addressMichael S. Tsirkin1-2/+5
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 Garcia1-1/+2
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 Maydell1-2/+2
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 Maydell1-0/+205
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 Bonzini1-2/+2
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-Ayland1-2/+2
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. Somlo1-0/+205
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 Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-13Revert seccomp tests that allow it to be used on non-x86 architecturesPeter Maydell1-7/+2
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 Huth1-1/+3
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ärber1-1/+1
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üller1-3/+2
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üller1-3/+2
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üller2-9/+6
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>
generated by cgit v1.1 at 2025-01-28 13:51:38 +0000