Petr Matousek [Thu, 18 Sep 2014 06:35:37 +0000 (08:35 +0200)]
slirp: udp: fix NULL pointer dereference because of uninitialized socket
When guest sends udp packet with source port and source addr 0,
uninitialized socket is picked up when looking for matching and already
created udp sockets, and later passed to sosendto() where NULL pointer
dereference is hit during so->slirp->vnetwork_mask.s_addr access.
Fix this by checking that the socket is not just a socket stub.
This is CVE-2014-3640.
Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reported-by: Xavier Mehrenberger <xavier.mehrenberger@airbus.com> Reported-by: Stephane Duverger <stephane.duverger@eads.net> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 20140918063537.GX9321@dhcp-25-225.brq.redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 01f7cecf0037997cb0e58ec0d56bf9b5a6f7cb2a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Since QEMU 2.1, we are allocating more space for ACPI tables, so no
space is left after initrd for the BIOS to allocate memory.
Besides ACPI tables, there are a few other uses of high memory in
SeaBIOS: SMBIOS tables and USB drivers use it in particular. These uses
allocate a very small amount of memory. Malloc metadata also lives
there. So we need _some_ extra padding there to avoid initrd breakage,
but not much.
John Snow found a case where RHEL5 was broken by the recent change to
ACPI_TABLE_SIZE; in his case 4KB of extra padding are fine, but just to
be safe I am adding 32KB, which is roughly the same amount of padding
that was left by QEMU 2.0 and earlier.
Move initrd to leave some space for the BIOS.
Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reported-by: John Snow <jsnow@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 438f92ee9f6a4f78f8adcc399809e252b6da72a2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This reverts commit a1bc7b827e422e1ff065640d8ec5347c4aadfcd8.
virtio: don't call device on !vm_running
It turns out that virtio net assumes that vm_running
is updated before device status callback in many places,
so this change leads to asserts.
Previous commit fixes the root issue that motivated a1bc7b827e422e1ff065640d8ec5347c4aadfcd8 differently,
so there's no longer a need for this change.
In the future, we might be able to drop checking vm_running
completely, and check vm state directly.
Reported-by: Dietmar Maurer <dietmar@proxmox.com> Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9e8e8c48653471fa5fed447e388fdef57d4f6998) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On vm stop, vm_running state set to stopped
before device is notified, so callbacks can get envoked with
vm_running = false; and this is not an error.
Cc: qemu-stable@nongnu.org Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 131c5221fe25a9547c4a388a3d26ff7fd14843e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit abb4d5f2e2830b7a6dc4ddcc612dfab15e3a320d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Wed, 6 Aug 2014 18:18:21 +0000 (15:18 -0300)]
hw/machine: Free old values of string properties
Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amos Kong <akong@redhat.com> Cc: qemu-stable@nongnu.org
(cherry picked from commit 556068eed04b7f11187aabd89b981552d8d0c30e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Wed, 20 Aug 2014 20:30:12 +0000 (17:30 -0300)]
target-i386: Support migratable=no properly
When the "migratable" property was implemented, the behavior was tested
by changing the default on the code, but actually using the option on
the command-line (e.g. "-cpu host,migratable=false") doesn't work as
expected. This is a regression for a common use case of "-cpu host",
which is to enable features that are supported by the host CPU + kernel
before feature-specific code is added to QEMU.
Fix this by initializing the feature words for "-cpu host" on
x86_cpu_parse_featurestr(), right after parsing the CPU options.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 4d1b279b0675a8b483a5f101212d1dedfb1a3cec) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Pavel Dovgaluk [Thu, 31 Jul 2014 05:41:17 +0000 (09:41 +0400)]
exec: Save CPUState::exception_index field
This patch adds a subsection with exception_index field to the VMState for
correct saving the CPU state.
Without this patch, simulator could miss the pending exception in the saved
virtual machine state.
Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Cc: qemu-stable@nongnu.org Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 6c3bff0ed8a40921464b9a07aa0fe079e860c978) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Sebastian Tanase [Mon, 28 Jul 2014 11:39:14 +0000 (13:39 +0200)]
pty: Fix byte loss bug when connecting to pty
When trying to print data to the pty, we first check if it is connected.
If not, we try to reconnect, but we drop the pending data even if we
have successfully reconnected; this makes us lose the first byte of the very
first transmission.
This small fix addresses the issue by checking once more if the pty is connected
after having tried to reconnect.
Signed-off-by: Sebastian Tanase <sebastian.tanase@openwide.fr> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit cf7330c759345de2efe9c0df7921189ac5ff11d3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Related spice-only bug. We have a fixed 16 MB buffer here, being
presented to the spice-server as qxl video memory in case spice is
used with a non-qxl card. It's also used with qxl in vga mode.
When using display resolutions requiring more than 16 MB of memory we
are going to overflow that buffer. In theory the guest can write,
indirectly via spice-server. The spice-server clears the memory after
setting a new video mode though, triggering a segfault in the overflow
case, so qemu crashes before the guest has a chance to do something
evil.
Fix that by switching to dynamic allocation for the buffer.
Gerd Hoffmann [Tue, 26 Aug 2014 13:35:23 +0000 (15:35 +0200)]
vbe: rework sanity checks
Plug a bunch of holes in the bochs dispi interface parameter checking.
Add a function doing verification on all registers. Call that
unconditionally on every register write. That way we should catch
everything, even changing one register affecting the valid range of
another register.
Some of the holes have been added by commit e9c6149f6ae6873f14a12eea554925b6aa4c4dec. Before that commit the
maximum possible framebuffer (VBE_DISPI_MAX_XRES * VBE_DISPI_MAX_YRES *
32 bpp) has been smaller than the qemu vga memory (8MB) and the checking
for VBE_DISPI_MAX_XRES + VBE_DISPI_MAX_YRES + VBE_DISPI_MAX_BPP was ok.
Some of the holes have been there forever, such as
VBE_DISPI_INDEX_X_OFFSET and VBE_DISPI_INDEX_Y_OFFSET register writes
lacking any verification.
Security impact:
(1) Guest can make the ui (gtk/vnc/...) use memory rages outside the vga
frame buffer as source -> host memory leak. Memory isn't leaked to
the guest but to the vnc client though.
(2) Qemu will segfault in case the memory range happens to include
unmapped areas -> Guest can DoS itself.
The guest can not modify host memory, so I don't think this can be used
by the guest to escape.
Gerd Hoffmann [Tue, 26 Aug 2014 12:16:30 +0000 (14:16 +0200)]
vbe: make bochs dispi interface return the correct memory size with qxl
VgaState->vram_size is the size of the pci bar. In case of qxl not the
whole pci bar can be used as vga framebuffer. Add a new variable
vbe_size to handle that case. By default (if unset) it equals
vram_size, but qxl can set vbe_size to something else.
This makes sure VBE_DISPI_INDEX_VIDEO_MEMORY_64K returns correct results
and sanity checks are done with the correct size too.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 54a85d462447c1cb8a1638578a7fd086350b4d2d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-net: purge outstanding packets when starting vhost
whenever we start vhost, virtio could have outstanding packets
queued, when they complete later we'll modify the ring
while vhost is processing it.
To prevent this, purge outstanding packets on vhost start.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 086abc1ccd0fa5103345adda819e6c6436949579) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This completes all packets, ensuring that callbacks
will not run when VM is stopped.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit ca77d85e1dbf929ae677a0bac96e9b3edd1704da) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
devices rely on packet callbacks eventually running,
but we violate this rule whenever we purge the queue.
To fix, invoke callbacks on all packets on purge.
Set length to 0, this way callers can detect that
this happened and re-queue if necessary.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 07d8084624b3f5cbde7777849147a6a3a862e90a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
On vm stop, virtio changes vm_running state
too soon, so callbacks can get envoked with
vm_running = false;
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 269bd822e7f5ab80048b05fb7076236ed66ffbce) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Tue, 26 Aug 2014 08:06:17 +0000 (16:06 +0800)]
net: Forbid dealing with packets when VM is not running
For all NICs(except virtio-net) emulated by qemu,
Such as e1000, rtl8139, pcnet and ne2k_pci,
Qemu can still receive packets when VM is not running.
If this happened in *migration's* last PAUSE VM stage, but
before the end of the migration, the new receiving packets will possibly dirty
parts of RAM which has been cached in *iovec*(will be sent asynchronously) and
dirty parts of new RAM which will be missed.
This will lead serious network fault in VM.
To avoid this, we forbid receiving packets in generic net code when
VM is not running.
Bug reproduction steps:
(1) Start a VM which configured at least one NIC
(2) In VM, open several Terminal and do *Ping IP -i 0.1*
(3) Migrate the VM repeatedly between two Hosts
And the *PING* command in VM will very likely fail with message:
'Destination HOST Unreachable', the NIC in VM will stay unavailable unless you
run 'service network restart'
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit e1d64c084b2cc7e907b4e64026d8c8dba59116f8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Fri, 29 Aug 2014 03:52:51 +0000 (11:52 +0800)]
acpi-build: Set FORCE_APIC_CLUSTER_MODEL bit for FADT flags
If we start Windows 2008 R2 DataCenter with number of cpu less than 8,
The system will use APIC Flat Logical destination mode as default configuration,
Which has an upper limit of 8 CPUs.
The fault is that VM can not show all processors within Task Manager if
we hot-add cpus when the number of cpus in VM extends the limit of 8.
If we use cluster destination model, the problem will be solved.
Note:
This flag was introduced later than ACPI v1.0 specification while QEMU
generates v1.0 tables only, but...
linux kernel ignores this flag, so patch has no influence on it.
Tested with Win[XPsp3|Srv2003EE|Srv2008DC|Srv2008R2|Srv2012R2], there
isn't BSODs and guests boot just fine. In cases guest doesn't support
cpu-hotplug, cpu becomes visible after reboot and in case the guest
supports cpu-hotplug, it works as expected with this patch.
Cc: qemu-stable@nongnu.org Signed-off-by: huangzhichao <huangzhichao@huawei.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.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>
(cherry picked from commit 07b81ed937b37e4c1974626c38e2f192ce08f8f5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
As vhost core can use backend_features during init, clear it earlier to
avoid using uninitialized memory.
This use would be harmless since vhost scsi ignores the result
anyway, but initializing earlier will help prevent valgrind errors,
and make scsi and net behave similarly.
Cc: qemu-stable@nongnu.org Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 3a1655fc53a2d0375dc0b8cd358405c2cae288e3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 3 Sep 2014 06:25:30 +0000 (14:25 +0800)]
vhost_net: init acked_features to backend_features
commit 2e6d46d77ed328d34a94688da8371bcbe243479b (vhost: add
vhost_get_features and vhost_ack_features) removes the step that
initializes the acked_features to backend_features.
As this field is now uninitialized, vhost initialization will sometimes
fail.
To fix, initialize acked_features on each ack.
Tested-by: Andrey Korolyov <andrey@xdel.ru> Cc: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com> Cc: 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>
(cherry picked from commit b49ae9138d5cadb47fb868297fbcdac8292fb666) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Tue, 19 Aug 2014 04:56:29 +0000 (12:56 +0800)]
vhost_net: start/stop guest notifiers properly
commit a9f98bb5ebe6fb1869321dcc58e72041ae626ad8 "vhost: multiqueue
support" changed the order of stopping the device. Previously
vhost_dev_stop would disable backend and only afterwards, unset guest
notifiers. We now unset guest notifiers while vhost is still
active. This can lose interrupts causing guest networking to fail. In
particular, this has been observed during migration.
To fix this, several other changes are needed:
- remove the hdev->started assertion in vhost.c since we may want to
start the guest notifiers before vhost starts and stop the guest
notifiers after vhost is stopped.
- introduce the vhost_net_set_vq_index() and call it before setting
guest notifiers. This is to guarantee vhost_net has the correct
virtqueue index when setting guest notifiers.
MST: fix up error handling.
Cc: qemu-stable@nongnu.org Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Andrey Korolyov <andrey@xdel.ru> Reported-by: "Zhangjie (HZ)" <zhangjie14@huawei.com> Tested-by: William Dauchy <william@gandi.net> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cd7d1d26b0a333bf2fca715e332690bbd738c097) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
pci: avoid losing config updates to MSI/MSIX cap regs
Since
commit 95d658002401e2e47a5404298ebe9508846e8a39
msi: Invoke msi/msix_write_config from PCI core
msix config writes are lost, the value written is always 0.
Fix pci_default_write_config to avoid this.
Cc: qemu-stable@nongnu.org Signed-off-by: Knut Omang <knut.omang@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d7efb7e08e5edaac23b0dc824f72c3f353447c39) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
is incomplete: BH might execute within the same main loop iteration but
after vmstop, so in theory, we might trigger an assertion.
I was unable to reproduce this in practice,
but it seems clear enough that the potential is there, so worth fixing.
Cc: qemu-stable@nongnu.org Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit e8bcf842001739765b8dcc1996d86a0ffd2054d5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Fri, 29 Aug 2014 07:27:52 +0000 (09:27 +0200)]
qxl-render: add more sanity checks
Damn, the dirty rectangle values are signed integers. So the checks
added by commit 788fbf042fc6d5aaeab56757e6dad622ac5f0c21 are not good
enough, we also have to make sure they are not negative.
[ Note: There must be something broken in spice-server so we get
negative values in the first place. Bug opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1135372 ]
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 503b3b33feca818baa4459aba286e54a528e5567) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 29 Aug 2014 14:00:28 +0000 (15:00 +0100)]
target-arm: Correct Cortex-A57 ISAR5 and AA64ISAR0 ID register values
We implement the crypto extensions but were incorrectly reporting
ID register values for the Cortex-A57 which did not advertise
crypto. Use the correct values as described in the TRM.
With this fix Linux correctly detects presence of the crypto
features and advertises them in /proc/cpuinfo.
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1408718660-7295-1-git-send-email-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit c379621451e64cad166a60f42e1d67f0438b8d1b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 29 Aug 2014 14:00:28 +0000 (15:00 +0100)]
target-arm: Fix regression that disabled VFP for ARMv5 CPUs
Commit 2c7ffc414 added support for honouring the CPACR coprocessor
access control register bits which may disable access to VFP
and Neon instructions. However it failed to account for the
fact that the CPACR is only present starting from the ARMv6
architecture version, so it accidentally disabled VFP completely
for ARMv5 CPUs like the ARM926. Linux would detect this as
"no VFP present" and probably fall back to its own emulation,
but other guest OSes might crash or misbehave.
Reported-by: Jakub Jermar <jakub@jermar.eu> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1408714940-7192-1-git-send-email-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit ed1f13d607e2c64c66bea49d6f4edaf278d3d246) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:39 +0000 (15:39 -0600)]
x86: Clear MTRRs on vCPU reset
The SDM specifies (June 2014 Vol3 11.11.5):
On a hardware reset, the P6 and more recent processors clear the
valid flags in variable-range MTRRs and clear the E flag in the
IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
MTRRs are undefined.
We currently do none of that, so whatever MTRR settings you had prior
to reset is what you have after reset. Usually this doesn't matter
because KVM often ignores the guest mappings and uses write-back
anyway. However, if you have an assigned device and an IOMMU that
allows NoSnoop for that device, KVM defers to the guest memory
mappings which are now stale after reset. The result is that OVMF
rebooting on such a configuration takes a full minute to LZMA
decompress the firmware volume, a process that is nearly instant on
the initial boot.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 9db2efd95e13330075bff027cd682a063d725332) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:33 +0000 (15:39 -0600)]
x86: kvm: Add MTRR support for kvm_get|put_msrs()
The MTRR state in KVM currently runs completely independent of the
QEMU state in CPUX86State.mtrr_*. This means that on migration, the
target loses MTRR state from the source. Generally that's ok though
because KVM ignores it and maps everything as write-back anyway. The
exception to this rule is when we have an assigned device and an IOMMU
that doesn't promote NoSnoop transactions from that device to be cache
coherent. In that case KVM trusts the guest mapping of memory as
configured in the MTRR.
This patch updates kvm_get|put_msrs() so that we retrieve the actual
vCPU MTRR settings and therefore keep CPUX86State synchronized for
migration. kvm_put_msrs() is also used on vCPU reset and therefore
allows future modificaitons of MTRR state at reset to be realized.
Note that the entries array used by both functions was already
slightly undersized for holding every possible MSR, so this patch
increases it beyond the 28 new entries necessary for MTRR state.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d1ae67f626c5ed5729e1d8212834291b409d26df) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Thu, 14 Aug 2014 21:39:27 +0000 (15:39 -0600)]
x86: Use common variable range MTRR counts
We currently define the number of variable range MTRR registers as 8
in the CPUX86State structure and vmstate, but use MSR_MTRRcap_VCNT
(also 8) to report to guests the number available. Change this to
use MSR_MTRRcap_VCNT consistently.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d8b5c67b05420d966664664ff287af05b884bdd1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
William Grant [Sun, 24 Aug 2014 05:13:48 +0000 (15:13 +1000)]
target-i386: Don't forbid NX bit on PAE PDEs and PTEs
Commit e8f6d00c30ed88910d0d985f4b2bf41654172ceb ("target-i386: raise
page fault for reserved physical address bits") added a check that the
NX bit is not set on PAE PDPEs, but it also added it to rsvd_mask for
the rest of the function. This caused any PDEs or PTEs with NX set to be
erroneously rejected, making PAE guests with NX support unusable.
Signed-off-by: William Grant <wgrant@ubuntu.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1844e68ecabbdfdf0228774bcd5cf0f63ffc2e57) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Mon, 25 Aug 2014 11:47:00 +0000 (13:47 +0200)]
vl: process -object after other backend options
QOM backends can refer to chardevs, but not vice versa. So
process -chardev and -fsdev options before -object
This fixes the rng-egd backend to virtio-rng.
Reported-by: Amos Kong <akong@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 7b71758d79106a63a0b8aba02df752d9995ea50c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Greg Kurz [Wed, 27 Aug 2014 16:17:12 +0000 (18:17 +0200)]
spapr_pci: map the MSI window in each PHB
On sPAPR, virtio devices are connected to the PCI bus and use MSI-X.
Commit cc943c36faa192cd4b32af8fe5edb31894017d35 has modified MSI-X
so that writes are made using the bus master address space and follow
the IOMMU path.
Unfortunately, the IOMMU address space address space does not have an
MSI window: the notification is silently dropped in unassigned_mem_write
instead of reaching the guest... The most visible effect is that all
virtio devices are non-functional on sPAPR since then. :(
This patch does the following:
1) map the MSI window into the IOMMU address space for each PHB
- since each PHB instantiates its own IOMMU address space, we
can safely map the window at a fixed address (SPAPR_PCI_MSI_WINDOW)
- no real need to keep the MSI window setup in a separate function,
the spapr_pci_msi_init() code moves to spapr_phb_realize().
2) kill the global MSI window as it is not needed in the end
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit 8c46f7ec85a4dd9663489b2fa2b425cd7b3653e1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Tue, 15 Jul 2014 14:44:26 +0000 (16:44 +0200)]
thread-pool: avoid deadlock in nested aio_poll() calls
The thread pool has a race condition if two elements complete before
thread_pool_completion_bh() runs:
If element A's callback waits for element B using aio_poll() it will
deadlock since pool->completion_bh is not marked scheduled when the
nested aio_poll() runs.
Fix this by marking the BH scheduled while thread_pool_completion_bh()
is executing. This way any nested aio_poll() loops will enter
thread_pool_completion_bh() and complete the remaining elements.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 3c80ca158c96ff902a30883a8933e755988948b1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Tue, 15 Jul 2014 14:44:25 +0000 (16:44 +0200)]
thread-pool: avoid per-thread-pool EventNotifier
EventNotifier is implemented using an eventfd or pipe. It therefore
consumes file descriptors, which can be limited by rlimits and should
therefore be used sparingly.
Switch from EventNotifier to QEMUBH in thread-pool.c. Originally
EventNotifier was used because qemu_bh_schedule() was not thread-safe
yet.
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit c2e50e3d11a0bf4c973cc30478c1af0f2d5f8e81) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
pc: reserve more memory for ACPI for new machine types
commit 868270f23d8db2cce83e4f082fe75e8625a5fbf9
acpi-build: tweak acpi migration limits
broke kernel loading with -kernel/-initrd: it doubled
the size of ACPI tables but did not reserve
enough memory.
As a result, issues on boot and halt are observed.
Fix this up by doubling reserved memory for new machine types.
Cc: qemu-stable@nongnu.org Reported-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 927766c7d34275ecf586020cc5305e377cc4af10) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gonglei [Wed, 20 Aug 2014 05:52:30 +0000 (13:52 +0800)]
pcihp: fix possible array out of bounds
Prevent out-of-bounds array access on
acpi_pcihp_pci_status.
Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
(cherry picked from commit fa365d7cd11185237471823a5a33d36765454e16) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
When memory is allocated on a wrong node, MPOL_MF_STRICT
doesn't move it - it just fails the allocation.
A simple way to reproduce the failure is with mlock=on
realtime feature.
The code comment actually says: "ensure policy won't be ignored"
so setting MPOL_MF_MOVE seems like a better way to do this.
Cc: qemu-stable@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 288d3322022d6ad646407f3ca6f1a6a746565b9a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Ben Draper [Wed, 20 Aug 2014 12:27:14 +0000 (13:27 +0100)]
vmxnet3: Pad short frames to minimum size (60 bytes)
When running VMware ESXi under qemu-kvm the guest discards frames
that are too short. Short ARP Requests will be dropped, this prevents
guests on the same bridge as VMware ESXi from communicating. This patch
simply adds the padding on the network device itself.
Signed-off-by: Ben Draper <ben@xrsa.net> Reviewed-by: Dmitry Fleytman <dmitry@daynix.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 40a87c6c9b11ef9c14e0301f76abf0eb2582f08e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Fri, 22 Aug 2014 04:45:50 +0000 (12:45 +0800)]
blkdebug: Delete BH in bdrv_aio_cancel
Otherwise error_callback_bh will access the already released acb.
Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit cbf95a0b117461473f05ab3cce4d01ba2b29e60a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Thu, 21 Aug 2014 12:44:08 +0000 (13:44 +0100)]
qemu-iotests: add test case 101 for short file I/O
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 8d9eb33ca0bbb8bca0f1775623ed3cf5f39760cd)
Conflicts:
tests/qemu-iotests/group
*fix up context mismatches due to lack of 099 and 103 tests
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Thu, 21 Aug 2014 12:44:07 +0000 (13:44 +0100)]
raw-posix: fix O_DIRECT short reads
The following O_DIRECT read from a <512 byte file fails:
$ truncate -s 320 test.img
$ qemu-io -n -c 'read -P 0 0 512' test.img
qemu-io: can't open device test.img: Could not read image for determining its format: Invalid argument
Note that qemu-io completes successfully without the -n (O_DIRECT)
option.
This patch fixes qemu-iotests ./check -nocache -vmdk 059.
Cc: qemu-stable@nongnu.org Suggested-by: Kevin Wolf <kwolf@redhat.com> Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 61ed73cff427206b3a959b18a4877952f566279b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Lieven [Fri, 22 Aug 2014 08:08:49 +0000 (10:08 +0200)]
block/iscsi: fix memory corruption on iscsi resize
bs->total_sectors is not yet updated at this point. resulting
in memory corruption if the volume has grown and data is written
to the newly availble areas.
CC: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d832fb4d66ead62da4af7e44cce34cd939e865e1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Christoffer Dall [Tue, 19 Aug 2014 17:56:27 +0000 (18:56 +0100)]
arm/virt: Use PSCI v0.2 function IDs in the DT when KVM uses PSCI v0.2
The current code supplies the PSCI v0.1 function IDs in the DT even when
KVM uses PSCI v0.2.
This will break guest kernels that only support PSCI v0.1 as they will
use the IDs provided in the DT. Guest kernels with PSCI v0.2 support
are not affected by this patch, because they ignore the function IDs in
the device tree and rely on the architecture definition.
Define QEMU versions of the constants and check that they correspond to
the Linux defines on Linux build hosts. After this patch, both guest
kernels with PSCI v0.1 support and guest kernels with PSCI v0.2 should
work.
Tested on TC2 for 32-bit and APM Mustang for 64-bit (aarch64 guest
only). Both cases tested with 3.14 and linus/master and verified I
could bring up 2 cpus with both guest kernels. Also tested 32-bit with
a 3.14 host kernel with only PSCI v0.1 and both guests booted here as
well.
Cc: qemu-stable@nongnu.org Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 863714ba6cdc09d1a84069815dc67c8da66b0a29) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Christoffer Dall [Tue, 19 Aug 2014 17:56:27 +0000 (18:56 +0100)]
target-arm: Rename QEMU PSCI v0.1 definitions
The function IDs for PSCI v0.1 are exported by KVM and defined as
KVM_PSCI_FN_<something>. To build using these defines in non-KVM code,
QEMU defines these IDs locally and check their correctness against the
KVM headers when those are available.
However, the naming scheme used for QEMU (almost) clashes with the PSCI
v0.2 definitions from Linux so to avoid unfortunate naming when we
introduce local PSCI v0.2 defines, rename the current local defines with
QEMU_ prependend and clearly identify the PSCI version as v0.1 in the
defines.
Cc: qemu-stable@nongnu.org Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit a65c9c17cef16bcb98ec6cf4feb8676c1a2d1168) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Tue, 19 Aug 2014 17:56:24 +0000 (18:56 +0100)]
target-arm: Fix return address for A64 BRK instructions
When we take an exception resulting from a BRK instruction,
the architecture requires that the "preferred return address"
reported to the exception handler is the address of the BRK
itself, not the following instruction (like undefined
insns, and in contrast with SVC, HVC and SMC). Follow this,
rather than incorrectly reporting the address of the following
insn.
(We do get this correct for the A32/T32 BKPT insns.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-stable@nongnu.org
(cherry picked from commit 229a138d740142885dd4e7063e25147d7f71fdef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
zhanghailiang [Mon, 18 Aug 2014 07:42:50 +0000 (15:42 +0800)]
virtio-blk: fix reference a pointer which might be freed
In function virtio_blk_handle_request, it may freed memory pointed by req,
So do not access member of req after calling this function.
Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 1bdb176ac5add5dc9d54a230da7511b66851f1e7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
RSDP should be aligned at a 16-byte boundary.
This would by chance at the moment, fix up acpi build
to make it robust.
Cc: qemu-stable@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit d67aadccfa0bd3330a7b8e7e0a1726117ba75cf1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Hu Tao [Mon, 4 Aug 2014 08:16:09 +0000 (16:16 +0800)]
numa: show hex number in error message for consistency and prefix them with 0x
The error messages before and after patch are:
before:
qemu-system-x86_64: total memory for NUMA nodes (134217728) should equal RAM size (20000000)
after:
qemu-system-x86_64: total memory for NUMA nodes (0x8000000) should equal RAM size (0x20000000)
Cc: qemu-stable@nongnu.org Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit c68233aee8ef47861b65f0d079c5b0b3816447e5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
- int should be printed using %d
- print actual wrong value for property
Cc: qemu-stable@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 988eba0f681bd4f82e9e02998da8106f165ed82c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Hu Tao [Mon, 4 Aug 2014 08:16:08 +0000 (16:16 +0800)]
pc-dimm: validate node property
If user specifies a node number that exceeds the available numa nodes in
emulated system for pc-dimm device, the device will report an invalid _PXM
to OSPM. Fix this by checking the node property value.
Cc: qemu-stable@nongnu.org Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit cfe0ffd0272f1a6d34d27ac1a7072d1c42d33ad3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 41d2f71376fe401a1fdb7deda023769207511790) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Tokarev [Wed, 13 Aug 2014 07:23:31 +0000 (11:23 +0400)]
ide: only constrain read/write requests to drive size, not other types
Commit 58ac321135a introduced a check to ide dma processing which
constrains all requests to drive size. However, apparently, some
valid requests (like TRIM) does not fit in this constraint, and
fails in 2.1. So check the range only for reads and writes.
Cc: qemu-stable@nongnu.org Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit d66168ed687325aa6d338ce3a3cff18ce3098ed6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Tokarev [Fri, 1 Aug 2014 19:20:24 +0000 (23:20 +0400)]
l2tpv3 (configure): it is linux-specific
Some non-linux systems, for example a system with
FreeBSD kernel and glibc, may declare struct mmsghdr
(in glibc) but may not have linux-specific header
file linux/ip.h. The actual implementation in qemu
includes this linux-specific header file unconditionally,
so compilation fails if it is not present. Include
this header in the configure test too.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit bff6cb72961f1bd2c766efe85ff5850fd8d7e77d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Tue, 5 Aug 2014 19:05:52 +0000 (13:05 -0600)]
vfio: Fix MSI-X vector expansion
When new MSI-X vectors are enabled we need to disable MSI-X and
re-enable it with the correct number of vectors. That means we need
to reprogram the eventfd triggers for each vector. Prior to f4d45d47
vector->use tracked whether a vector was masked or unmasked and we
could always pick the KVM path when available for unmasked vectors.
Now vfio doesn't track mask state itself and vector->use and virq
remains configured even for masked vectors. Therefore we need to ask
the MSI-X code whether a vector is masked in order to select the
correct signaling path. As noted in the comment, MSI relies on
hardware to handle masking.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Cc: qemu-stable@nongnu.org # QEMU 2.1
(cherry picked from commit c048be5cc92ae201c339d46984476c4629275ed6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Wed, 9 Jul 2014 12:01:32 +0000 (14:01 +0200)]
qdev-monitor: include QOM properties in -device FOO, help output
Update -device FOO,help to include QOM properties in addition to qdev
properties. Devices are gradually adding more QOM properties that are
not reflected as qdev properties.
It is important to report all device properties since management tools
like libvirt use this information (and device-list-properties QMP) to
detect the presence of QEMU features.
This patch reuses the device-list-properties QMP machinery to avoid code
duplication.
Reported-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Cole Robinson <crobinso@redhat.com>
(cherry picked from commit ef523587da4f213ca17133a90402d0815ecf08ee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Stefan Hajnoczi [Wed, 9 Jul 2014 12:01:31 +0000 (14:01 +0200)]
qmp: hide "hotplugged" device property from device-list-properties
The "hotplugged" device property was not reported before commit f4eb32b590bf58c1c67570775eb78beb09964fad ("qmp: show QOM properties in
device-list-properties"). Fix this difference.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 4115dd6527fbdf49dbd1eba24ad68e0fae1e305a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Tue, 29 Jul 2014 11:04:01 +0000 (12:04 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc migration fixes
Last minute fixes for migration.
It seems that if we don't fix it now, fixing
it in the next version will be even more painful ...
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Tue 29 Jul 2014 11:45:18 BST 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:
piix: set legacy table size for 1.7
acpi-build: tweak acpi migration limits
pc: future-proof migration-compatibility of ACPI tables
acpi-build: minor code cleanup
pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled
bios-tables-test: fix ASL normalization false positive
pc: hack for migration compatibility from QEMU 2.0
acpi-dsdt: procedurally generate _PRT
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
- Tweak error message for legacy machine type:
Basically if table size exceeds the limits we set all
bets are off for migration: e.g. it can start failing even
within given qemu minor version simply because of a bugfix.
- Increase table size to 128k.
- Make sure we notice it long before we start getting close to the
128k limit: warn at 64k.
- Don't fail if we exceed the limit: most people don't care about
migration, even less people care about cross version miration.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 28 Jul 2014 15:34:16 +0000 (17:34 +0200)]
pc: future-proof migration-compatibility of ACPI tables
This patch avoids that similar changes break QEMU again in the future.
QEMU will now hard-code 64k as the maximum ACPI table size, which
(despite being an order of magnitude smaller than 640k) should be enough
for everyone.
Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Igor Mammedov [Mon, 28 Jul 2014 15:34:18 +0000 (17:34 +0200)]
pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled
Fixes migration regression from QEMU-1.7 to a newer QEMUs.
SSDT table size in QEMU-1.7 doesn't change regardless of
a number of PCI bridge devices present at startup.
However in QEMU-2.0 since addition of hotplug on PCI bridges,
each PCI bridge adds ~1875 bytes to SSDT table, including
pc-i440fx-1.7 machine type where PCI bridge hotplug disabled
via compat property.
It breaks migration from "QEMU-1.7" to "QEMU-2.[01] -M pc-i440fx-1.7"
since RAMBlock size of ACPI tables on target becomes larger
then on source and migration fails with:
"Length mismatch: /rom@etc/acpi/tables: 2000 in != 3000"
error.
Fix this by generating AML only for PCI0 bus if
hotplug on PCI bridges is disabled and preserves PCI brigde
description in AML as it was done in QEMU-1.7 for pc-i440fx-1.7.
It will help to maintain size of SSDT static regardless of
number of PCI bridges on startup for pc-i440fx-1.7 machine type.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Paolo Bonzini [Mon, 28 Jul 2014 15:34:17 +0000 (17:34 +0200)]
bios-tables-test: fix ASL normalization false positive
My version of IASL (from RHEL7) puts two newlines between the head comment
and the DefinitionBlock property. Kill all newlines after the comment,
so that normalize_asl works properly.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Paolo Bonzini [Mon, 28 Jul 2014 15:34:15 +0000 (17:34 +0200)]
pc: hack for migration compatibility from QEMU 2.0
Changing the ACPI table size causes migration to break, and the memory
hotplug work opened our eyes on how horribly we were breaking things in
2.0 already.
The ACPI table size is rounded to the next 4k, which one would think
gives some headroom. In practice this is not the case, because the user
can control the ACPI table size (each CPU adds 97 bytes to the SSDT and
8 to the MADT) and so some "-smp" values will break the 4k boundary and
fail to migrate. Similarly, PCI bridges add ~1870 bytes to the SSDT.
This patch concerns itself with fixing migration from QEMU 2.0. It
computes the payload size of QEMU 2.0 and always uses that one.
The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size
should always be enough; non-AML tables can change depending on the
configuration (especially MADT, SRAT, HPET) but they remain the same
between QEMU 2.0 and 2.1, so we only compute our padding based on the
sizes of the SSDT and DSDT.
Migration from QEMU 1.7 should work for guests that have a number of CPUs
other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140. It was already
broken from QEMU 1.7 to QEMU 2.0 in the same way, though.
Even with this patch, QEMU 1.7 and 2.0 have two different ideas of
"-M pc-i440fx-2.0" when there are PCI bridges. Igor sent a patch to
adopt the QEMU 1.7 definition. I think distributions should apply
it if they move directly from QEMU 1.7 to 2.1+ without ever packaging
version 2.0.
Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Paolo Bonzini [Mon, 28 Jul 2014 15:34:14 +0000 (17:34 +0200)]
acpi-dsdt: procedurally generate _PRT
This replaces the _PRT constant with a method that computes it.
The problem is that the DSDT+SSDT have grown from 2.0 to 2.1,
enough to cross the 8k barrier (we align the ACPI tables to 4k
before putting them in fw_cfg). This causes problems with
migration and the pc-i440fx-2.0 machine type.
The solution to the problem is to hardcode 64k as the limit,
but this doesn't solve the bug with pc-i440fx-2.0. The fix will be
for QEMU 2.1 to use exactly the same size as QEMU 2.0 for the
ACPI tables. First, however, we must make the actual AML
equal or smaller; to do this, rewrite _PRT in a way that saves
over 1k of bytecode.
Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Peter Maydell [Mon, 28 Jul 2014 10:05:14 +0000 (11:05 +0100)]
Merge remote-tracking branch 'remotes/mjt/tags/trivial-patches-2014-07-26' into staging
trivial patches for 2014-07-26
# gpg: Signature made Sat 26 Jul 2014 08:16:55 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>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5
# Subkey fingerprint: 6F67 E18E 7C91 C5B1 5514 66A7 BEE5 9D74 A4C3 D7DB
* remotes/mjt/tags/trivial-patches-2014-07-26:
qemu-options: fix another allows-to for -net l2tpv3
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Paolo Bonzini [Thu, 24 Jul 2014 14:08:04 +0000 (16:08 +0200)]
qemu-char: ignore flow control if a PTY's slave is not connected
After commit f702e62 (serial: change retry logic to avoid concurrency,
2014-07-11), guest boot hangs if the backend is an unconnected PTY.
The reason is that PTYs do not support G_IO_HUP, and serial_xmit is
never called. To fix this, simply invoke serial_xmit immediately
(via g_idle_source_new) when this happens.
Tested-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We need to remember has_updates for each vnc client. Otherwise it might
happen that vnc_update_client(has_dirty=1) takes the first exit due to
output buffers not being flushed yet and subsequent calls with
has_dirty=0 take the second exit, wrongly assuming there is nothing to
do because the work defered in the first call is ignored.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de>
Stephan Kulow [Wed, 23 Jul 2014 14:03:14 +0000 (16:03 +0200)]
fix full frame updates for VNC clients
If the client asks for !incremental frame updates, it has lost its content
so dirty doesn't matter - it has to see the full frame, so setting force_update
Signed-off-by: Stephan Kulow <coolo@suse.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de>
Eric Blake [Wed, 23 Jul 2014 12:26:18 +0000 (06:26 -0600)]
docs: document missing VSERPORT_CHANGE event
The VSERPORT_CHANGE event was added in e2ae6159. The patch for
this event was prepared at a time when this file was gone, even
though it got applied immediately after dfab4892 restored this
file. Duplicate the documentation into this file, so that
anyone using this file instead of qapi will not miss out on this
new event.
* docs/qmp/qmp-events.txt (VSERPORT_CHANGE): Add.
Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Wenchao Xia <wenchaoqemu@gmail.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Eric Blake [Wed, 23 Jul 2014 12:26:17 +0000 (06:26 -0600)]
docs: document missing POWERDOWN event
The POWERDOWN event was first documented in 0aab9ec3. But since dfab4892 later restored this file to the state prior to qmp events,
and we never documented it in the past, anyone using this file
instead of qapi will miss out on this event. Tweak the existing
wording of SHUTDOWN to match 84321831, and make the difference
between the two events apparent.
The SPICE_MIGRATE_COMPLETED event was first documented in 7cfadb6b. But since dfab4892 later restored this file to the
state prior to qmp events, and we never documented it in the
past, anyone using this file instead of qapi will miss out on
this event.
Eric Blake [Wed, 23 Jul 2014 12:26:15 +0000 (06:26 -0600)]
docs: split SPICE_* event docs
For consistency with the rest of this file, every event should be
listed in isolation. Compare how commit 7cfadb6b split
SPICE_CONNECTED and SPICE_DISCONNECTED into separate qmp events.
Eric Blake [Wed, 23 Jul 2014 12:26:14 +0000 (06:26 -0600)]
docs: grammar fixes to qmp-events
When converting to qmp events, commits 7cfadb6b and a6330785
fixed some grammar as part of moving text between files. But
since dfab4892 later restored this file to the state prior to
qmp events, we have to do it again.
Peter Maydell [Tue, 22 Jul 2014 16:10:01 +0000 (17:10 +0100)]
hw/misc/imx_ccm.c: Add missing VMState list terminator
The VMStateDescription for the imx_ccm device was missing its
terminator. Found by static search of the codebase using
a regex based on one suggested by Ian Jackson:
pcregrep -rMi '(?s)VMStateField(?:(?!END_OF_LIST).)*?;' $(git grep -l 'VMStateField\[\]')
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-stable@nongnu.org
"vmstate_xhci_event" was introduced in commit 37352df3 ("xhci: add live
migration support"), and first released in v1.6.0. The field list in this
VMSD is not terminated with the VMSTATE_END_OF_LIST() macro.
During normal use (ie. migration), the issue is practically invisible,
because the "vmstate_xhci_event" object (with the unterminated field list)
is only ever referenced -- via "vmstate_xhci_intr" -- if xhci_er_full()
returns true, for the "ev_buffer" test. Since that field_exists() check
(apparently) almost always returns false, we almost never traverse
"vmstate_xhci_event" during migration, which hides the bug.
However, Amit's vmstate checker forces recursion into this VMSD as well,
and the lack of VMSTATE_END_OF_LIST() breaks the field list terminator
check (field->name != NULL) in dump_vmstate_vmsd(). The result is
undefined behavior, which in my case translates to infinite recursion
(because the loop happens to overflow into "vmstate_xhci_intr", which then
links back to "vmstate_xhci_event").
Add the missing terminator.
Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2. if there is a numa node backed by memory backend object, qemu fails
with message:
./ppc-softmmu/qemu-system-ppc -m 512 \
-object memory-backend-file,size=512M,mem-path=/hugepages,id=f0 \
-numa node,nodeid=0,memdev=f0 \
-kernel /home/hutao/Downloads/vmlinux-ppc \
-initrd /home/hutao/Downloads/initrd-ppc.gz
qemu-system-ppc: memory backend f0 is used multiple times. Each -numa option must use a different memdev value.
This patch does following:
1. replaces memory_region_allocate_system_memory() with
memory_region_init_ram() for rom, sram. Then only system memory
is backed by hugepages when specifying mem-path.
2. for memory banks, allocates all ram with
one memory_region_allocate_system_memory(), and use
memory_region_init_alias() to initialize memory banks.
John Snow [Mon, 21 Jul 2014 21:44:37 +0000 (17:44 -0400)]
virtio-rng: Add human-readable error message for negative max-bytes parameter
If a negative integer is used for the max_bytes parameter, QEMU currently
calls abort() and leaves behind a core dump. This patch replaces the
abort with a simple error message to make the reason for the termination
clearer. This also ensures device-hotplug with invalid input doesn't
cause qemu to quit.
There is an underlying insufficiency in the parameter parsing code of QEMU
that renders it unable to reject negative values for unsigned properties,
thus the error message "a non-negative integer below 2^63" is the most
user-friendly and correct message we can give until the underlying
insufficiency is corrected.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
Peter Maydell [Tue, 22 Jul 2014 11:03:44 +0000 (12:03 +0100)]
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
One of the two pending migration fix, and a small KVM patch.
# gpg: Signature made Tue 22 Jul 2014 11:49:30 BST using RSA key ID 9B4D86F2
# gpg: Can't check signature: public key not found
* remotes/bonzini/tags/for-upstream:
kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL
exec: fix migration with devices that use address_space_rw
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Chen Gang [Sat, 19 Jul 2014 01:21:46 +0000 (09:21 +0800)]
kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL
If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.
And kvm_arch_remove_sw_breakpoint() can assumes 'cpu' must never be NULL,
so need define additional temporary variable for 'cpu' to avoid the case.
Cc: qemu-stable@nongnu.org Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
projects / thirdparty / qemu.git / log
