]> git.proxmox.com Git - mirror_qemu.git/log
mirror_qemu.git
5 years agoUpdate version for 2.11.2 release v2.11.2
Michael Roth [Wed, 27 Jun 2018 03:27:39 +0000 (22:27 -0500)]
Update version for 2.11.2 release

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agousb/dev-mtp: Fix use of uninitialized values
Philippe Mathieu-Daudé [Mon, 4 Jun 2018 15:14:20 +0000 (12:14 -0300)]
usb/dev-mtp: Fix use of uninitialized values

This fixes:

  hw/usb/dev-mtp.c:971:5: warning: 4th function call argument is an uninitialized value
      trace_usb_mtp_op_get_partial_object(s->dev.addr, o->handle, o->path,
                                           c->argv[1], c->argv[2]);
                                                       ^~~~~~~~~~
and:

  hw/usb/dev-mtp.c:981:12: warning: Assigned value is garbage or undefined
      offset = c->argv[1];
               ^ ~~~~~~~~~~

Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180604151421.23385-3-f4bug@amsat.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 62713a2e50f653162387451034f1a2490e87be88)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agousb: correctly handle Zero Length Packets
Philippe Mathieu-Daudé [Mon, 4 Jun 2018 15:14:19 +0000 (12:14 -0300)]
usb: correctly handle Zero Length Packets

USB Specification Revision 2.0, §5.5.3:
  The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following:
  • Has transferred exactly the amount of data specified during the Setup stage
  • Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet"

hw/usb/redirect.c:802:9: warning: Declared variable-length array (VLA) has zero size
        uint8_t buf[size];
        ^~~~~~~~~~~ ~~~~

Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180604151421.23385-2-f4bug@amsat.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit bf78fb1c1b61a819a47f7a1dbecf9934b9f32a0d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agogdbstub: fix off-by-one in gdb_handle_packet()
Philippe Mathieu-Daudé [Sun, 8 Apr 2018 14:59:33 +0000 (11:59 -0300)]
gdbstub: fix off-by-one in gdb_handle_packet()

memtohex() adds an extra trailing NUL character.

Reported-by: AddressSanitizer
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20180408145933.1149-1-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 9005774b27b6aa5e1c99d80bd59d5d048c2f7077)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoMerge tag 'tags/s390x-20180621-211-stable' into stable-2.11-staging
Michael Roth [Thu, 21 Jun 2018 15:16:52 +0000 (10:16 -0500)]
Merge tag 'tags/s390x-20180621-211-stable' into stable-2.11-staging

update s390-ccw.img for stable

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agopc-bios/s390-ccw.img: update image for stable
Cornelia Huck [Thu, 21 Jun 2018 08:22:15 +0000 (04:22 -0400)]
pc-bios/s390-ccw.img: update image for stable

Contains the following commits:
- s390: Do not pass inofficial IPL type to the guest
- s390-ccw: force diag 308 subcode to unsigned long
- pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
5 years agotpm: lookup cancel path under tpm device class
Marc-André Lureau [Mon, 29 Jan 2018 18:33:04 +0000 (19:33 +0100)]
tpm: lookup cancel path under tpm device class

Since Linux commit 313d21eeab9282e, tpm devices have their own device
class "tpm" and the cancel path must be looked up under
/sys/class/tpm/ instead of /sys/class/misc/.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
(cherry picked from commit 05b71fb207ab7f016e067bd2a40fc0804362eb74)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotpm-passthrough: don't save guessed cancel_path in options
Marc-André Lureau [Mon, 6 Nov 2017 18:39:06 +0000 (19:39 +0100)]
tpm-passthrough: don't save guessed cancel_path in options

The value is later unneeded, and may leak if the free visitor doesn't
consider it since has_cancel_path is false. And for consistency with
"path" it shouldn't be returned in get_tpm_options().

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
(cherry picked from commit 69c07db04625cb243db6e8a0ac0a8e3973dd961a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390-ccw-virtio: allow for systems larger that 7.999TB
Christian Borntraeger [Mon, 11 Dec 2017 12:21:46 +0000 (13:21 +0100)]
s390-ccw-virtio: allow for systems larger that 7.999TB

KVM does not allow memory regions > KVM_MEM_MAX_NR_PAGES, basically
limiting the memory per slot to 8TB-4k. As memory slots on s390/kvm must
be a multiple of 1MB we need start a new memory region if we cross
8TB-1M.

With that (and optimistic overcommitment in the kernel) I was able to
start a 24TB guest on a 1TB system.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20171211122146.162430-1-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
[CH: 1UL -> 1ULL in KVM_MEM_MAX_NR_PAGES; build fix on 32 bit hosts]
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit bb223055b9b327ec66e1f6d2fbaebaee0b8f3dbe)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agocrypto: ensure we use a predictable TLS priority setting
Daniel P. Berrangé [Wed, 28 Feb 2018 14:04:38 +0000 (14:04 +0000)]
crypto: ensure we use a predictable TLS priority setting

The TLS test cert generation relies on a fixed set of algorithms that are
only usable under GNUTLS' default priority setting. When building QEMU
with a custom distro specific priority setting, this can cause the TLS
tests to fail. By forcing the tests to always use "NORMAL" priority we
can make them more robust.

Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 057ad0b46992e3ec4ce29b9103162aa3c683f347)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqapi: ensure stable sort ordering when checking QAPI entities
Daniel P. Berrange [Tue, 16 Jan 2018 13:42:10 +0000 (13:42 +0000)]
qapi: ensure stable sort ordering when checking QAPI entities

Some early python 3.x versions will have different default
ordering when calling the 'values()' method on a dict, compared
to python 2.x and later 3.x versions. Explicitly sort the items
to get a stable ordering.

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20180116134217.8725-8-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit f7a5376d4b667cf6c83c1d640e32d22456d7b5ee)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoarm_gicv3_kvm: kvm_dist_get/put_priority: skip the registers banked by GICR_IPRIORITYR
Shannon Zhao [Fri, 15 Jun 2018 13:57:13 +0000 (14:57 +0100)]
arm_gicv3_kvm: kvm_dist_get/put_priority: skip the registers banked by GICR_IPRIORITYR

While for_each_dist_irq_reg loop starts from GIC_INTERNAL, it forgot to
offset the date array and index. This will overlap the GICR registers
value and leave the last GIC_INTERNAL irq's registers out of update.

Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 1dcf3675196a1cec616ce71b067d9498590a60a6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoiotests: Add test 221 to catch qemu-img map regression
Eric Blake [Mon, 11 Jun 2018 21:39:27 +0000 (16:39 -0500)]
iotests: Add test 221 to catch qemu-img map regression

Although qemu-img creates aligned files (by rounding up), it
must also gracefully handle files that are not sector-aligned.
Test that the bug fixed in the previous patch does not recur.

It's a bit annoying that we can see the (implicit) hole past
the end of the file on to the next sector boundary, so if we
ever reach the point where we report a byte-accurate size rather
than our current behavior of always rounding up, this test will
probably need a slight modification.

Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c6a9d2f6f9bc0c163b3a3073126464a2446bad5f)
 Conflicts:
tests/qemu-iotests/group
* drop context dep on tests not present in 2.11
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqemu-img: Fix assert when mapping unaligned raw file
Eric Blake [Mon, 11 Jun 2018 21:39:26 +0000 (16:39 -0500)]
qemu-img: Fix assert when mapping unaligned raw file

Commit a290f085 exposed a latent bug in qemu-img map introduced
during the conversion of block status to be byte-based.  Earlier in
commit 5e344dd8, the internal interface get_block_status() switched
to take byte-based parameters, but still called a sector-based
block layer function; as such, rounding was added in the lone
caller to obey the contract.  However, commit 237d78f8 changed
get_block_status() to truly be byte-based, at which point rounding
to sector boundaries can result in calling bdrv_block_status() with
'bytes == 0' (a coding error) when the boundary between data and a
hole falls mid-sector (true for the past-EOF implicit hole present
in POSIX files).  Fix things by removing the rounding that is now
no longer necessary.

See also https://bugzilla.redhat.com/1589738

Fixes: 237d78f8
Reported-by: Dan Kenigsberg <danken@redhat.com>
Reported-by: Nir Soffer <nsoffer@redhat.com>
Reported-by: Maor Lipchuk <mlipchuk@redhat.com>
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit e0b371ed5e2db079051139136fd0478728b6a58f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agovhost-user: delete net client if necessary
linzhecheng [Tue, 12 Jun 2018 02:24:45 +0000 (10:24 +0800)]
vhost-user: delete net client if necessary

As qemu_new_net_client create new ncs but error happens later,
ncs will be left in global net_clients list and we can't use them any
more, so we need to cleanup them.

Cc: qemu-stable@nongnu.org
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c67daf4a24442d1bb404a11a6a54dc45ea10f234)
 Conflicts:
net/vhost-user.c
* drop functional dep on 4d0cf552
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotap: set vhostfd passed from qemu cli to non-blocking
Brijesh Singh [Fri, 6 Apr 2018 18:51:25 +0000 (13:51 -0500)]
tap: set vhostfd passed from qemu cli to non-blocking

A guest boot hangs while probing the network interface when
iommu_platform=on is used.

The following qemu cli hangs without this patch:

# $QEMU \
  -netdev tap,fd=3,id=hostnet0,vhost=on,vhostfd=4 3<>/dev/tap67 4<>/dev/host-net \
  -device virtio-net-pci,netdev=hostnet0,id=net0,iommu_platform=on,disable-legacy=on \
  ...

Commit: c471ad0e9bd46 (vhost_net: device IOTLB support) took care of
setting vhostfd to non-blocking when QEMU opens /dev/host-net but if
the fd is passed from qemu cli then we need to ensure that fd is set
to non-blocking.

Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support")
Cc: qemu-stable@nongnu.org
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit d542800d1edc62f63f8a29cfa6bdd1a9536ae11c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoi386: define the AMD 'virt-ssbd' CPUID feature bit (CVE-2018-3639)
Konrad Rzeszutek Wilk [Mon, 21 May 2018 21:54:23 +0000 (22:54 +0100)]
i386: define the AMD 'virt-ssbd' CPUID feature bit (CVE-2018-3639)

AMD Zen expose the Intel equivalant to Speculative Store Bypass Disable
via the 0x80000008_EBX[25] CPUID feature bit.

This needs to be exposed to guest OS to allow them to protect
against CVE-2018-3639.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180521215424.13520-3-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 403503b162ffc33fb64cfefdf7b880acf41772cd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoi386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639)
Konrad Rzeszutek Wilk [Mon, 21 May 2018 21:54:24 +0000 (22:54 +0100)]
i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639)

"Some AMD processors only support a non-architectural means of enabling
speculative store bypass disable (SSBD).  To allow a simplified view of
this to a guest, an architectural definition has been created through a new
CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f.  With this, a
hypervisor can virtualize the existence of this definition and provide an
architectural method for using SSBD to a guest.

Add the new CPUID feature, the new MSR and update the existing SSBD
support to use this MSR when present." (from x86/speculation: Add virtualized
speculative store bypass disable support in Linux).

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180521215424.13520-4-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit cfeea0c021db6234c154dbc723730e81553924ff)
 Conflicts:
target/i386/kvm.c
target/i386/machine.c
* drop context dep on b77146e9a
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoi386: define the 'ssbd' CPUID feature bit (CVE-2018-3639)
Daniel P. Berrangé [Mon, 21 May 2018 21:54:22 +0000 (22:54 +0100)]
i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639)

New microcode introduces the "Speculative Store Bypass Disable"
CPUID feature bit. This needs to be exposed to guest OS to allow
them to protect against CVE-2018-3639.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20180521215424.13520-2-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit d19d1f965904a533998739698020ff4ee8a103da)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agovga: fix region calculation
Gerd Hoffmann [Fri, 9 Mar 2018 14:37:04 +0000 (15:37 +0100)]
vga: fix region calculation

Typically the scanline length and the line offset are identical.  But
in case they are not our calculation for region_end is incorrect.  Using
line_offset is fine for all scanlines, except the last one where we have
to use the actual scanline length.

Fixes: CVE-2018-7550
Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Tested-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Message-id: 20180309143704.13420-1-kraxel@redhat.com
(cherry picked from commit 7cdc61becd095b64a786b2625f321624e7111f3d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agothrottle: Fix crash on reopen
Alberto Garcia [Fri, 8 Jun 2018 15:15:36 +0000 (18:15 +0300)]
throttle: Fix crash on reopen

The throttle block filter can be reopened, and with this it is
possible to change the throttle group that the filter belongs to.

The way the code does that is the following:

  - On throttle_reopen_prepare(): create a new ThrottleGroupMember
    and attach it to the new throttle group.

  - On throttle_reopen_commit(): detach the old ThrottleGroupMember,
    delete it and replace it with the new one.

The problem with this is that by replacing the ThrottleGroupMember the
previous value of io_limits_disabled is lost, causing an assertion
failure in throttle_co_drain_end().

This problem can be reproduced by reopening a throttle node:

   $QEMU -monitor stdio
   -object throttle-group,id=tg0,x-iops-total=1000 \
   -blockdev node-name=hd0,driver=qcow2,file.driver=file,file.filename=hd.qcow2 \
   -blockdev node-name=root,driver=throttle,throttle-group=tg0,file=hd0,read-only=on

   (qemu) block_stream root
   block/throttle.c:214: throttle_co_drain_end: Assertion `tgm->io_limits_disabled' failed.

Since we only want to change the throttle group on reopen there's no
need to create a ThrottleGroupMember and discard the old one. It's
easier if we simply detach it from its current group and attach it to
the new one.

Signed-off-by: Alberto Garcia <berto@igalia.com>
Message-id: 20180608151536.7378-1-berto@igalia.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit bc33c047d1ec0b35c9cd8be62bcefae2da28654f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoiotests: Add case for a corrupted inactive image
Max Reitz [Wed, 6 Jun 2018 19:37:02 +0000 (21:37 +0200)]
iotests: Add case for a corrupted inactive image

Reviewed-by: John Snow <jsnow@redhat.com>
Tested-by: Jeff Cody <jcody@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-4-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit c50abd175a88cd41c2c08339de91f6f6e4a7b162)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqcow2: Do not mark inactive images corrupt
Max Reitz [Wed, 6 Jun 2018 19:37:01 +0000 (21:37 +0200)]
qcow2: Do not mark inactive images corrupt

When signaling a corruption on a read-only image, qcow2 already makes
fatal events non-fatal (i.e., they will not result in the image being
closed, and the image header's corrupt flag will not be set).  This is
necessary because we cannot set the corrupt flag on read-only images,
and it is possible because further corruption of read-only images is
impossible.

Inactive images are effectively read-only, too, so we should do the same
for them.  bdrv_is_writable() can tell us whether an image can actually
be written to, so use its result instead of !bs->read_only.

(Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in
bdrv_co_pwritev() will fail, crashing qemu.)

Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-3-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoblock: Make bdrv_is_writable() public
Max Reitz [Wed, 6 Jun 2018 19:37:00 +0000 (21:37 +0200)]
block: Make bdrv_is_writable() public

This is a useful function for the whole block layer, so make it public.
At the same time, users outside of block.c probably do not need to make
use of the reopen functionality, so rename the current function to
bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function
that just passes NULL to it for the reopen queue.

Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-2-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit cc022140972f8b6ac3973c12ccf9dd6b1d2fd200)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoarm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR
Shannon Zhao [Fri, 8 Jun 2018 12:15:32 +0000 (13:15 +0100)]
arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR

While we skip the GIC_INTERNAL irqs, we don't change the register offset
accordingly. This will overlap the GICR registers value and leave the
last GIC_INTERNAL irq's registers out of update.

Fix this by skipping the registers banked by GICR.

Also for migration compatibility if the migration source (old version
qemu) doesn't send gicd_no_migration_shift_bug = 1 to destination, then
we shift the data of PPI to get the right data for SPI.

Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: qemu-stable@nongnu.org
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Message-id: 1527816987-16108-1-git-send-email-zhaoshenglong@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 910e204841954b95c051b2ee49ab0f5c735ff93c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoahci: fix PxCI register race
John Snow [Fri, 8 Jun 2018 17:17:36 +0000 (13:17 -0400)]
ahci: fix PxCI register race

Fixes: https://bugs.launchpad.net/qemu/+bug/1769189
AHCI presently signals completion prior to the PxCI register being
cleared to indicate completion. If a guest driver attempts to issue
a new command in its IRQ handler, it might be surprised to learn there
is still a command pending.

In the case of Windows 10's boot driver, it will actually poll the IRQ
register hoping to find out when the command is done running -- which
will never happen, as there isn't a command running.

Fix this: clear PxCI in ahci_cmd_done and not in the asynchronous BH.
Because it now runs synchronously, we don't need to check if the command
is actually done by spying on the ATA registers. We know it's done.

CC: qemu-stable <qemu-stable@nongnu.org>
Reported-by: François Guerraz <kubrick@fgv6.net>
Tested-by: Bruce Rogers <brogers@suse.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180531004323.4611-3-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 5694c7eacce6b263ad7497cc1bb76aad746cfd4e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoFix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
John Thomson [Thu, 5 Apr 2018 13:20:46 +0000 (23:20 +1000)]
Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option

libusb-1.0.22 marked libusb_set_debug deprecated
it is replaced with
libusb_set_option(libusb_context, LIBUSB_OPTION_LOG_LEVEL, libusb_log_level);

details here: https://github.com/libusb/libusb/commit/539f22e2fd916558d11ab9a66f10f461c5593168

Warning here:

  CC      hw/usb/host-libusb.o
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c: In function 'usb_host_init':
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c:250:5: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
     libusb_set_debug(ctx, loglevel);
     ^~~~~~~~~~~~~~~~
In file included from /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:40:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
 void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
                  ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/builds/xen/src/qemu-xen/rules.mak:66: hw/usb/host-libusb.o] Error 1
make: Leaving directory '/builds/xen/src/xen/tools/qemu-xen-build'

Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Message-id: 20180405132046.4968-1-git@johnthomson.fastmail.com.au
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 9d8fa0df49af16a208fa961c2968fba4daffcc07)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoarm_gicv3_kvm: increase clroffset accordingly
Shannon Zhao [Thu, 31 May 2018 13:50:51 +0000 (14:50 +0100)]
arm_gicv3_kvm: increase clroffset accordingly

It forgot to increase clroffset during the loop. So it only clear the
first 4 bytes.

Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: qemu-stable@nongnu.org
Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1527047633-12368-1-git-send-email-zhaoshenglong@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 34ffacae085914fce54590ea84bae9c6ad95e2a4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: rework the page walk logic
Peter Xu [Fri, 18 May 2018 07:25:17 +0000 (15:25 +0800)]
intel-iommu: rework the page walk logic

This patch fixes a potential small window that the DMA page table might
be incomplete or invalid when the guest sends domain/context
invalidations to a device.  This can cause random DMA errors for
assigned devices.

This is a major change to the VT-d shadow page walking logic. It
includes but is not limited to:

- For each VTDAddressSpace, now we maintain what IOVA ranges we have
  mapped and what we have not.  With that information, now we only send
  MAP or UNMAP when necessary.  Say, we don't send MAP notifies if we
  know we have already mapped the range, meanwhile we don't send UNMAP
  notifies if we know we never mapped the range at all.

- Introduce vtd_sync_shadow_page_table[_range] APIs so that we can call
  in any places to resync the shadow page table for a device.

- When we receive domain/context invalidation, we should not really run
  the replay logic, instead we use the new sync shadow page table API to
  resync the whole shadow page table without unmapping the whole
  region.  After this change, we'll only do the page walk once for each
  domain invalidations (before this, it can be multiple, depending on
  number of notifiers per address space).

While at it, the page walking logic is also refactored to be simpler.

CC: QEMU Stable <qemu-stable@nongnu.org>
Reported-by: Jintack Lim <jintack@cs.columbia.edu>
Tested-by: Jintack Lim <jintack@cs.columbia.edu>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 63b88968f139b6a77f2f81e6f1eedf70c0170a85)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoutil: implement simple iova tree
Peter Xu [Fri, 18 May 2018 07:25:16 +0000 (15:25 +0800)]
util: implement simple iova tree

Introduce a simplest iova tree implementation based on GTree.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit eecf5eedbdc0fc04f39abcf3afeedfbf21b25ca4)
 Conflicts:
util/Makefile.objs
* drop context dep
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: trace domain id during page walk
Peter Xu [Fri, 18 May 2018 07:25:15 +0000 (15:25 +0800)]
intel-iommu: trace domain id during page walk

This patch only modifies the trace points.

Previously we were tracing page walk levels.  They are redundant since
we have page mask (size) already.  Now we trace something much more
useful which is the domain ID of the page walking.  That can be very
useful when we trace more than one devices on the same system, so that
we can know which map is for which domain.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d118c06ebbee2d23ddf873cae4a809311aa61310)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: pass in address space when page walk
Peter Xu [Fri, 18 May 2018 07:25:14 +0000 (15:25 +0800)]
intel-iommu: pass in address space when page walk

We pass in the VTDAddressSpace too.  It'll be used in the follow up
patches.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 2f764fa87d2a81812b313dd6d998e10126292653)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: introduce vtd_page_walk_info
Peter Xu [Fri, 18 May 2018 07:25:13 +0000 (15:25 +0800)]
intel-iommu: introduce vtd_page_walk_info

During the recursive page walking of IOVA page tables, some stack
variables are constant variables and never changed during the whole page
walking procedure.  Isolate them into a struct so that we don't need to
pass those contants down the stack every time and multiple times.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit fe215b0cbb8c1f4b4af0a64aa5c02042080dd537)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: only do page walk for MAP notifiers
Peter Xu [Fri, 18 May 2018 07:25:12 +0000 (15:25 +0800)]
intel-iommu: only do page walk for MAP notifiers

For UNMAP-only IOMMU notifiers, we don't need to walk the page tables.
Fasten that procedure by skipping the page table walk.  That should
boost performance for UNMAP-only notifiers like vhost.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 4f8a62a933a79094e44bc1b16b63bb23e62d67b4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: add iommu lock
Peter Xu [Fri, 18 May 2018 07:25:11 +0000 (15:25 +0800)]
intel-iommu: add iommu lock

SECURITY IMPLICATION: this patch fixes a potential race when multiple
threads access the IOMMU IOTLB cache.

Add a per-iommu big lock to protect IOMMU status.  Currently the only
thing to be protected is the IOTLB/context cache, since that can be
accessed even without BQL, e.g., in IO dataplane.

Note that we don't need to protect device page tables since that's fully
controlled by the guest kernel.  However there is still possibility that
malicious drivers will program the device to not obey the rule.  In that
case QEMU can't really do anything useful, instead the guest itself will
be responsible for all uncertainties.

CC: QEMU Stable <qemu-stable@nongnu.org>
Reported-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1d9efa73e12ddf361ea997c2d532cc4afa6674d1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: remove IntelIOMMUNotifierNode
Peter Xu [Fri, 18 May 2018 07:25:10 +0000 (15:25 +0800)]
intel-iommu: remove IntelIOMMUNotifierNode

That is not really necessary.  Removing that node struct and put the
list entry directly into VTDAddressSpace.  It simplfies the code a lot.
Since at it, rename the old notifiers_list into vtd_as_with_notifiers.

CC: QEMU Stable <qemu-stable@nongnu.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit b4a4ba0d68f50f218ee3957b6638dbee32a5eeef)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: send PSI always even if across PDEs
Peter Xu [Fri, 18 May 2018 07:25:09 +0000 (15:25 +0800)]
intel-iommu: send PSI always even if across PDEs

SECURITY IMPLICATION: without this patch, any guest with both assigned
device and a vIOMMU might encounter stale IO page mappings even if guest
has already unmapped the page, which may lead to guest memory
corruption.  The stale mappings will only be limited to the guest's own
memory range, so it should not affect the host memory or other guests on
the host.

During IOVA page table walking, there is a special case when the PSI
covers one whole PDE (Page Directory Entry, which contains 512 Page
Table Entries) or more.  In the past, we skip that entry and we don't
notify the IOMMU notifiers.  This is not correct.  We should send UNMAP
notification to registered UNMAP notifiers in this case.

For UNMAP only notifiers, this might cause IOTLBs cached in the devices
even if they were already invalid.  For MAP/UNMAP notifiers like
vfio-pci, this will cause stale page mappings.

This special case doesn't trigger often, but it is very easy to be
triggered by nested device assignments, since in that case we'll
possibly map the whole L2 guest RAM region into the device's IOVA
address space (several GBs at least), which is far bigger than normal
kernel driver usages of the device (tens of MBs normally).

Without this patch applied to L1 QEMU, nested device assignment to L2
guests will dump some errors like:

qemu-system-x86_64: VFIO_MAP_DMA: -17
qemu-system-x86_64: vfio_dma_map(0x557305420c30, 0xad000, 0x1000,
                    0x7f89a920d000) = -17 (File exists)

CC: QEMU Stable <qemu-stable@nongnu.org>
Acked-by: Jason Wang <jasowang@redhat.com>
[peterx: rewrite the commit message]
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 36d2d52bdb45f5b753a61fdaf0fe7891f1f5b61d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: Extend address width to 48 bits
Prasad Singamsetty [Tue, 14 Nov 2017 23:13:50 +0000 (18:13 -0500)]
intel-iommu: Extend address width to 48 bits

The current implementation of Intel IOMMU code only supports 39 bits
iova address width. This patch provides a new parameter (x-aw-bits)
for intel-iommu to extend its address width to 48 bits but keeping the
default the same (39 bits). The reason for not changing the default
is to avoid potential compatibility problems with live migration of
intel-iommu enabled QEMU guest. The only valid values for 'x-aw-bits'
parameter are 39 and 48.

After enabling larger address width (48), we should be able to map
larger iova addresses in the guest. For example, a QEMU guest that
is configured with large memory ( >=1TB ). To check whether 48 bits
aw is enabled, we can grep in the guest dmesg output with line:
"DMAR: Host address width 48".

Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 37f51384ae05bd50f83308339dbffa3e78404874)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agointel-iommu: Redefine macros to enable supporting 48 bit address width
Prasad Singamsetty [Tue, 14 Nov 2017 23:13:49 +0000 (18:13 -0500)]
intel-iommu: Redefine macros to enable supporting 48 bit address width

The current implementation of Intel IOMMU code only supports 39 bits
host/iova address width so number of macros use hard coded values based
on that. This patch is to redefine them so they can be used with
variable address widths. This patch doesn't add any new functionality
but enables adding support for 48 bit address width.

Signed-off-by: Prasad Singamsetty <prasad.singamsety@oracle.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 92e5d85e8345a22e87eda940ffe0f6422eb45360)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agohw/intc/arm_gicv3: Fix APxR<n> register dispatching
Jan Kiszka [Thu, 31 May 2018 13:50:51 +0000 (14:50 +0100)]
hw/intc/arm_gicv3: Fix APxR<n> register dispatching

There was a nasty flip in identifying which register group an access is
targeting. The issue caused spuriously raised priorities of the guest
when handing CPUs over in the Jailhouse hypervisor.

Cc: qemu-stable@nongnu.org
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Message-id: 28b927d3-da58-bce4-cc13-bfec7f9b1cb9@siemens.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 887aae10f6150dfdc71c45d7588e8efe6c144019)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoconsole: Avoid segfault in screendump
Michal Privoznik [Thu, 17 May 2018 15:00:11 +0000 (17:00 +0200)]
console: Avoid segfault in screendump

After f771c5440e04626f1 it is possible to select device and
head which to take screendump from. And even though we check if
provided head number falls within range, it may still happen that
the console has no surface yet leading to SIGSEGV:

  qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
    -qmp stdio \
    -device virtio-vga,id=video0,max_outputs=4

  {"execute":"qmp_capabilities"}
  {"execute":"screendump", "arguments":{"filename":"/tmp/screen.ppm", "device":"video0", "head":1}}
  Segmentation fault

 #0  0x00005628249dda88 in ppm_save (filename=0x56282826cbc0 "/tmp/screen.ppm", ds=0x0, errp=0x7fff52a6fae0) at ui/console.c:304
 #1  0x00005628249ddd9b in qmp_screendump (filename=0x56282826cbc0 "/tmp/screen.ppm", has_device=true, device=0x5628276902d0 "video0", has_head=true, head=1, errp=0x7fff52a6fae0) at ui/console.c:375
 #2  0x00005628247740df in qmp_marshal_screendump (args=0x562828265e00, ret=0x7fff52a6fb68, errp=0x7fff52a6fb60) at qapi/qapi-commands-ui.c:110

Here, @ds from frame #0 (or @surface from frame #1) is
dereferenced at the very beginning of ppm_save(). And because
it's NULL crash happens.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: cb05bb1909daa6ba62145c0194aafa05a14ed3d1.1526569138.git.mprivozn@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 08d9864fa4e0c616e076ca8b225d39a7ecb189af)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390x/ccw: make sure all ccw devices are properly reset
Cornelia Huck [Mon, 7 May 2018 13:27:57 +0000 (15:27 +0200)]
s390x/ccw: make sure all ccw devices are properly reset

Thomas reported that the subchannel for a  3270 device that ended up
in a broken state (status pending even though not enabled) did not
get out of that state even after a reboot (which involves a subsytem
reset). The reason for this is that the 3270 device did not define
a reset handler.

Let's fix this by introducing a base reset handler (set up for all
ccw devices) that resets the subchannel and have virtio-ccw call
its virtio-specific reset procedure in addition to that.

CC: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 838fb84f83c84f00d15b1bede5e080b495644458)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agovirtio-ccw: common reset handler
Cornelia Huck [Mon, 7 May 2018 13:05:42 +0000 (15:05 +0200)]
virtio-ccw: common reset handler

All the different virtio ccw devices use the same reset handler,
so let's move setting it into the base virtio ccw device class.

CC: qemu-stable@nongnu.org
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 0c53057adb04d254bc09511880670c92ab185fc6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390x/virtio: Convert virtio-ccw from *_exit to *_unrealize
Nia Alarie [Wed, 7 Mar 2018 16:29:58 +0000 (16:29 +0000)]
s390x/virtio: Convert virtio-ccw from *_exit to *_unrealize

Signed-off-by: Nia Alarie <nia.alarie@gmail.com>
Message-Id: <20180307162958.11232-1-nia.alarie@gmail.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 24118af846868bb22e573be206c63e684ba9846a)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqdev: add helpers to be more explicit when using abstract QOM parent functions
Philippe Mathieu-Daudé [Sun, 14 Jan 2018 02:04:11 +0000 (23:04 -0300)]
qdev: add helpers to be more explicit when using abstract QOM parent functions

QOM API learning curve is quite hard, in particular when devices inherit from
abstract parent.
To be more explicit about when a device class change the parent hooks, add few
helpers hoping a device class_init() will be easier to understand.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180114020412.26160-3-f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 46795cf2e2f643ace9454822022ba8b1e9c0cf61)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqdev: rename typedef qdev_resetfn() -> DeviceReset()
Philippe Mathieu-Daudé [Sun, 14 Jan 2018 02:04:10 +0000 (23:04 -0300)]
qdev: rename typedef qdev_resetfn() -> DeviceReset()

following the DeviceRealize and DeviceUnrealize typedefs,
this unify a bit the new QOM API.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180114020412.26160-2-f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b850f664a1dbbc1ea27bef12cd251ee5da0bfe05)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agopc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)
Thomas Huth [Tue, 8 May 2018 10:17:52 +0000 (12:17 +0200)]
pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)

I've run into a compilation error today with the current version of GCC 8:

In file included from s390-ccw.h:49,
                 from main.c:12:
cio.h:128:1: error: alignment 1 of 'struct tpi_info' is less than 4 [-Werror=packed-not-aligned]
 } __attribute__ ((packed));
 ^
cc1: all warnings being treated as errors

Since the struct tpi_info contains an element ("struct subchannel_id schid")
which is marked as aligned(4), we've got to mark the struct tpi_info as
aligned(4), too.

CC: qemu-stable@nongnu.org
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1525774672-11913-1-git-send-email-thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit a6e4385dea94850d7b06b0542e7960c1063fdabd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390x/css: disabled subchannels cannot be status pending
Cornelia Huck [Fri, 4 May 2018 12:53:16 +0000 (14:53 +0200)]
s390x/css: disabled subchannels cannot be status pending

The 3270 code will try to post an attention interrupt when the
3270 emulator (e.g. x3270) attaches. If the guest has not yet
enabled the subchannel for the 3270 device, we will present a spurious
cc 1 (status pending) when it uses msch on it later on, e.g. when
trying to enable the subchannel.

To fix this, just don't do anything in css_conditional_io_interrupt()
if the subchannel is not enabled. The 3270 code will work fine with
that, and the other user of this function (virtio-ccw) never
attempts to post an interrupt for a disabled device to begin with.

CC: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 6e9c893ecd00afd5344c35d0d0ded50eaa0938f6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoraw: Check byte range uniformly
Fam Zheng [Fri, 1 Jun 2018 09:26:40 +0000 (17:26 +0800)]
raw: Check byte range uniformly

We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is inconsistent (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them, in the meanwhile
make the helper reusable by the coming new callbacks.

Note that in most cases the block layer already verifies the request
byte range against our reported image length, before invoking the driver
callbacks.  The exception is during image creating, after
blk_set_allow_write_beyond_eof(blk, true) is called. But in that case,
the requests are not directly from the user or guest. So there is no
visible behavior change in adding the check code.

The int64_t -> uint64_t inconsistency, as shown by the type casting, is
pre-existing due to the interface.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 20180601092648.24614-3-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 384455385248762e74a080978f18f0c8f74757fe)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agolm32: take BQL before writing IP/IM register
Michael Walle [Tue, 9 Jan 2018 17:01:13 +0000 (18:01 +0100)]
lm32: take BQL before writing IP/IM register

Writing to these registers may raise an interrupt request. Actually,
this prevents the milkymist board from starting.

Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Walle <michael@walle.cc>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit 81e9cbd0ca1131012b058df6804b1f626a6b730c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoiotests: Add test for -U/force-share conflicts
Max Reitz [Wed, 2 May 2018 20:20:51 +0000 (22:20 +0200)]
iotests: Add test for -U/force-share conflicts

Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-4-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 4e7d73c5fbd97e55ffe5af02f24d1f7dbe3bbf20)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqemu-img: Use only string options in img_open_opts
Max Reitz [Wed, 2 May 2018 20:20:50 +0000 (22:20 +0200)]
qemu-img: Use only string options in img_open_opts

img_open_opts() takes a QemuOpts and converts them to a QDict, so all
values therein are strings.  Then it may try to call qdict_get_bool(),
however, which will fail with a segmentation fault every time:

$ ./qemu-img info -U --image-opts \
    driver=file,filename=/dev/null,force-share=off
[1]    27869 segmentation fault (core dumped)  ./qemu-img info -U
--image-opts driver=file,filename=/dev/null,force-share=off

Fix this by using qdict_get_str() and comparing the value as a string.
Also, when adding a force-share value to the QDict, add it as a string
so it fits the rest of the dict.

Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-3-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 4615f87832d2fcb7a544bedeece2741bf8c21f94)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqemu-io: Use purely string blockdev options
Max Reitz [Wed, 2 May 2018 20:20:49 +0000 (22:20 +0200)]
qemu-io: Use purely string blockdev options

Currently, qemu-io only uses string-valued blockdev options (as all are
converted directly from QemuOpts) -- with one exception: -U adds the
force-share option as a boolean.  This in itself is already a bit
questionable, but a real issue is that it also assumes the value already
existing in the options QDict would be a boolean, which is wrong.

That has the following effect:

$ ./qemu-io -r -U --image-opts \
    driver=file,filename=/dev/null,force-share=off
[1]    15200 segmentation fault (core dumped)  ./qemu-io -r -U
--image-opts driver=file,filename=/dev/null,force-share=off

Since @opts is converted from QemuOpts, the value must be a string, and
we have to compare it as such.  Consequently, it makes sense to also set
it as a string instead of a boolean.

Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-2-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 2a01c01f9ecb43af4c0a85fe6adc429ffc9c31b5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoiotests: Add test for rebasing with relative paths
Max Reitz [Wed, 9 May 2018 18:20:02 +0000 (20:20 +0200)]
iotests: Add test for rebasing with relative paths

Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509182002.8044-3-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 28036a7f7044fddb79819e3c8fcb4ae5605c60e0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqemu-img: Resolve relative backing paths in rebase
Max Reitz [Wed, 9 May 2018 18:20:01 +0000 (20:20 +0200)]
qemu-img: Resolve relative backing paths in rebase

Currently, rebase interprets a relative path for the new backing image
as follows:
(1) Open the new backing image with the given relative path (thus relative to
    qemu-img's working directory).
(2) Write it directly into the overlay's backing path field (thus
    relative to the overlay).

If the overlay is not in qemu-img's working directory, both will be
different interpretations, which may either lead to an error somewhere
(either rebase fails because it cannot open the new backing image, or
your overlay becomes unusable because its backing path does not point to
a file), or, even worse, it may result in your rebase being performed
for a different backing file than what your overlay will point to after
the rebase.

Fix this by interpreting the target backing path as relative to the
overlay, like qemu-img does everywhere else.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180509182002.8044-2-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit d16699b64671466b42079c45b89127aeea1ca565)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoconfigure: recognize more rpmbuild macros
Olaf Hering [Wed, 18 Apr 2018 07:50:44 +0000 (09:50 +0200)]
configure: recognize more rpmbuild macros

Extend the list of recognized, but ignored options from rpms %configure
macro. This fixes build on hosts running SUSE Linux.

Cc: qemu-stable@nongnu.org
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Message-Id: <20180418075045.27393-1-olaf@aepfle.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 181ce1d05c6d4f1c80f0e7ebb41e489c2b541edf)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqxl: fix local renderer crash
Gerd Hoffmann [Fri, 27 Apr 2018 11:55:28 +0000 (13:55 +0200)]
qxl: fix local renderer crash

Make sure we only ask the spice local renderer for display updates in
case we have a valid primary surface.  Without that spice is confused
and throws errors in case a display update request (triggered by
screendump for example) happens in parallel to a mode switch and hits
the race window where the old primary surface is gone and the new isn't
establisted yet.

Cc: qemu-stable@nongnu.org
Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20180427115528.345-1-kraxel@redhat.com
(cherry picked from commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agospapr: don't advertise radix GTSE if max-compat-cpu < power9
Greg Kurz [Thu, 3 May 2018 21:16:59 +0000 (23:16 +0200)]
spapr: don't advertise radix GTSE if max-compat-cpu < power9

On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 0550b1206a91d66051a21441a02c4ff126b531fe)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotarget/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
Greg Kurz [Thu, 3 May 2018 21:16:29 +0000 (23:16 +0200)]
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack

The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument

This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit bce009645b9f1d59195518e35747c8ea30f985f7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotarget/arm: Implement v8M VLLDM and VLSTM
Peter Maydell [Fri, 4 May 2018 17:05:51 +0000 (18:05 +0100)]
target/arm: Implement v8M VLLDM and VLSTM

For v8M the instructions VLLDM and VLSTM support lazy saving
and restoring of the secure floating-point registers. Even
if the floating point extension is not implemented, these
instructions must act as NOPs in Secure state, so they can
be used as part of the secure-to-nonsecure call sequence.

Fixes: https://bugs.launchpad.net/qemu/+bug/1768295
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180503105730.5958-1-peter.maydell@linaro.org
(cherry picked from commit b1e5336a9899016c53d59eba53ebf6abcc21995c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotcg/arm: Fix memory barrier encoding
Henry Wertz [Tue, 17 Apr 2018 22:06:23 +0000 (12:06 -1000)]
tcg/arm: Fix memory barrier encoding

I found with qemu 2.11.x or newer that I would get an illegal instruction
error running some Intel binaries on my ARM chromebook.  On investigation,
I found it was quitting on memory barriers.

qemu instruction:
mb $0x31
was translating as:
0x604050cc:  5bf07ff5  blpl     #0x600250a8

After patch it gives:
0x604050cc:  f57ff05b  dmb      ish

In short, I found INSN_DMB_ISH (memory barrier for ARMv7) appeared to be
correct based on online docs, but due to some endian-related shenanigans it
had to be byte-swapped to suit qemu; it appears INSN_DMB_MCR (memory
barrier for ARMv6) also should be byte swapped  (and this patch does so).
I have not checked for correctness of aarch64's barrier instruction.

Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Henry Wertz <hwertz10@gmail.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 3f814b803797c007abfe5c4041de754e01723031)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390-ccw: force diag 308 subcode to unsigned long
Cornelia Huck [Wed, 2 May 2018 12:52:21 +0000 (14:52 +0200)]
s390-ccw: force diag 308 subcode to unsigned long

We currently pass an integer as the subcode parameter. However,
the upper bits of the register containing the subcode need to
be 0, which is not guaranteed unless we explicitly specify the
subcode to be an unsigned long value.

Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag 308/6")
Cc: qemu-stable@nongnu.org
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 63d8b5ace31c1e1f3996fe4cd551d6d377594d5a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agos390: Do not pass inofficial IPL type to the guest
Viktor Mihajlovski [Thu, 5 Apr 2018 15:07:24 +0000 (17:07 +0200)]
s390: Do not pass inofficial IPL type to the guest

IPL over a virtio-scsi device requires special handling not
available in the real architecture. For this purpose the IPL
type 0xFF has been chosen as means of communication between
QEMU and the pc-bios. However, a guest OS could be confused
by seeing an unknown IPL type.

This change sets the IPL parameter type to 0x02 (CCW) to prevent
this. Pre-existing Linux has looked up the IPL parameters only in
the case of FCP IPL. This means that the behavior should stay
the same even if Linux checks for the IPL type unconditionally.

Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Message-Id: <1522940844-12336-4-git-send-email-mihajlov@linux.vnet.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit e8c7ef288abb05b741a95418ee2de85c1071e0db)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agonbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE
Eric Blake [Tue, 1 May 2018 15:46:53 +0000 (10:46 -0500)]
nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE

A missing space makes for poor error messages, and sizes can't
go negative.  Also, we missed diagnosing a server that sends
a maximum block size less than the minimum.

Fixes: 081dd1fe
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180501154654.943782-1-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit e475d108f1b3d3163f0affea67cdedbe5fc9752b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoccid: Fix dwProtocols advertisement of T=0
Jason Andryuk [Fri, 20 Apr 2018 18:32:19 +0000 (14:32 -0400)]
ccid: Fix dwProtocols advertisement of T=0

Commit d7d218ef02d87c637d20d64da8f575d434ff6f78 attempted to change
dwProtocols to only advertise support for T=0 and not T=1.  The change
was incorrect as it changed 0x00000003 to 0x00010000.

lsusb -v in a linux guest shows:
"dwProtocols         65536  (Invalid values detected)", though the
smart card could still be accessed.  Windows 7 does not detect inserted
smart cards and logs the the following Error in the Event Logs:

    Source: Smart Card Service
    Event ID: 610
    Smart Card Reader 'QEMU QEMU USB CCID 0' rejected IOCTL SET_PROTOCOL:
    Incorrect function. If this error persists, your smart card or reader
    may not be functioning correctly

    Command Header: 03 00 00 00

Setting to 0x00000001 fixes the Windows issue.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Message-id: 20180420183219.20722-1-jandryuk@gmail.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 0ee86bb6c5beb6498488850104f7557c376d0bef)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agodevice_tree: Increase FDT_MAX_SIZE to 1 MiB
Geert Uytterhoeven [Thu, 26 Apr 2018 10:04:38 +0000 (11:04 +0100)]
device_tree: Increase FDT_MAX_SIZE to 1 MiB

It is not uncommon for a contemporary FDT to be larger than 64 KiB,
leading to failures loading the device tree from sysfs:

    qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE

Hence increase the limit to 1 MiB, like on PPC.

For reference, the largest arm64 DTB created from the Linux sources is
ca. 75 KiB large (100 KiB when built with symbols/fixup support).

Cc: qemu-stable@nongnu.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Message-id: 1523541337-23919-1-git-send-email-geert+renesas@glider.be
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 14ec3cbd7c1e31dca4d23f028100c8f43e156573)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agohw/char/cmsdk-apb-uart.c: Correctly clear INTSTATUS bits on writes
Peter Maydell [Tue, 10 Apr 2018 13:42:03 +0000 (14:42 +0100)]
hw/char/cmsdk-apb-uart.c: Correctly clear INTSTATUS bits on writes

The CMSDK APB UART INTSTATUS register bits are all write-one-to-clear.
We were getting this correct for the TXO and RXO bits (which need
special casing because their state lives in the STATE register),
but had forgotten to handle the normal bits for RX and TX which
we do store in our s->intstatus field.

Perform the W1C operation on the bits in s->intstatus too.

Fixes: https://bugs.launchpad.net/qemu/+bug/1760262
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20180410134203.17552-1-peter.maydell@linaro.org
(cherry picked from commit 6670b494fdb23f74ecd9be3d952c007f64e268f1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotcg: Introduce tcg_set_insn_start_param
Richard Henderson [Tue, 10 Apr 2018 12:02:26 +0000 (13:02 +0100)]
tcg: Introduce tcg_set_insn_start_param

The parameters for tcg_gen_insn_start are target_ulong, which may be split
into two TCGArg parameters for storage in the opcode on 32-bit hosts.

Fixes the ARM target and its direct use of tcg_set_insn_param, which would
set the wrong argument in the 64-on-32 case.

Cc: qemu-stable@nongnu.org
Reported-by: alarson@ddci.com
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180410003558.2470-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 9743cd5736263e90d312b2c33bd739ffe1eae70d)
 Conflicts:
target/arm/translate.h
tcg/tcg.h
* rework to avoid functional dependency on 15fa08f

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agohw/block/pflash_cfi: fix off-by-one error
Philippe Mathieu-Daudé [Wed, 4 Apr 2018 23:32:38 +0000 (20:32 -0300)]
hw/block/pflash_cfi: fix off-by-one error

ASAN reported:

    hw/block/pflash_cfi02.c:245:33: runtime error: index 82 out of bounds for type 'uint8_t [82]'

Since the 'cfi_len' member is not used, remove it to keep the code safer.

Cc: qemu-stable@nongnu.org
Reported-by: AddressSanitizer
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 07c13a71721d9f8c690b66752964e254af247475)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agovfio-ccw: fix memory leaks in vfio_ccw_realize()
Greg Kurz [Sat, 7 Apr 2018 14:43:46 +0000 (16:43 +0200)]
vfio-ccw: fix memory leaks in vfio_ccw_realize()

If the subchannel is already attached or if vfio_get_device() fails, the
code jumps to the 'out_device_err' label and doesn't free the string it
has just allocated.

The code should be reworked so that vcdev->vdev.name only gets set when
the device has been attached, and freed when it is about to be detached.
This could be achieved  with the addition of a vfio_ccw_get_device()
function that would be the counterpart of vfio_put_device(). But this is
a more elaborate cleanup that should be done in a follow-up. For now,
let's just add calls to g_free() on the buggy error paths.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <152311222681.203086.8874800175539040298.stgit@bahia>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit be4d026f645eb31078e08d431c93a898b895024e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agocpus.c: ensure running CPU recalculates icount deadlines on timer expiry
Peter Maydell [Tue, 10 Apr 2018 12:02:25 +0000 (13:02 +0100)]
cpus.c: ensure running CPU recalculates icount deadlines on timer expiry

When we run in TCG icount mode, we calculate the number of instructions
to execute using tcg_get_icount_limit(), which ensures that we stop
execution at the next timer deadline. However there is a bug where
currently we do not recalculate that limit if the guest reprograms
a timer so that the next deadline moves closer, and so we will
continue execution until the original limit and fire the timer
later than we should.

Fix this bug in qemu_timer_notify_cb(): if we are currently running
a VCPU in icount mode, we simply need to kick it out of the main
loop and back to tcg_cpu_exec(), where it will recalculate the
icount limit. If we are not currently running a VCPU, then we
retain the existing logic for waking up a halted CPU.

Cc: qemu-stable@nongnu.org
Fixes: https://bugs.launchpad.net/qemu/+bug/1754038
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180406123838.21249-1-peter.maydell@linaro.org
(cherry picked from commit c52e7132d7c885841500f5277f7305f62767fe1d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agogluster: Fix blockdev-add with server.N.type=unix
Kevin Wolf [Tue, 3 Apr 2018 11:08:10 +0000 (13:08 +0200)]
gluster: Fix blockdev-add with server.N.type=unix

The legacy command line interface gets the socket path from an option
called 'socket'. QAPI in contract uses SocketAddress, where the
corresponding option is called 'path'.

Fix the gluster block driver to accept both 'socket' and 'path', with
'path' being the preferred syntax.

https://bugzilla.redhat.com/show_bug.cgi?id=1545155

Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20180403110810.25624-1-kwolf@redhat.com
Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit 9dae635afa98f83688806861cefe77ff1b4d76a8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoexec: fix memory leak in find_max_supported_pagesize()
Greg Kurz [Thu, 29 Mar 2018 09:09:46 +0000 (11:09 +0200)]
exec: fix memory leak in find_max_supported_pagesize()

The string returned by object_property_get_str() is dynamically allocated.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <152231458624.69730.1752893648612848392.stgit@bahia.lan>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 72a841d2a403b56ff894fa007b172dc9bcb3dae8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotarget/i386: Fix andn instruction
Alexandro Sanchez Bach [Thu, 5 Apr 2018 12:40:58 +0000 (14:40 +0200)]
target/i386: Fix andn instruction

In commit 7073fbada733c8d10992f00772c9b9299d740e9b, the `andn` instruction
was implemented via `tcg_gen_andc` but passes the operands in the wrong
order:
- X86 defines `andn dest,src1,src2` as: dest = ~src1 & src2
- TCG defines `andc dest,src1,src2` as: dest = src1 & ~src2

The following simple test shows the issue:

    #include <stdio.h>
    #include <stdint.h>

    int main(void) {
        uint32_t ret = 0;
        __asm (
            "mov $0xFF00, %%ecx\n"
            "mov $0x0F0F, %%eax\n"
            "andn %%ecx, %%eax, %%ecx\n"
            "mov %%ecx, %0\n"
          : "=r" (ret));
        printf("%08X\n", ret);
        return 0;
    }

This patch fixes the problem by simply swapping the order of the two last
arguments in `tcg_gen_andc_tl`.

Reported-by: Alexandro Sanchez Bach <alexandro@phi.nz>
Signed-off-by: Alexandro Sanchez Bach <alexandro@phi.nz>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5cd10051c2e02b7a86eae49919d6c65a87dbea46)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops
Richard Henderson [Tue, 27 Mar 2018 03:37:24 +0000 (20:37 -0700)]
tcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops

Failure to do so results in the tcg optimizer sign-extending
any constant fold from 32-bits.  This turns out to be visible
in the RISC-V testsuite using a host that emits these opcodes
(e.g. any non-x86_64).

Reported-by: Michael Clark <mjc@sifive.com>
Reviewed-by: Emilio G. Cota <cota@braap.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit f2f1dde75160cac6ede330f3db50dc817d01a2d6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoiotests: Test preallocated truncate of 2G image
Max Reitz [Wed, 28 Feb 2018 13:13:15 +0000 (14:13 +0100)]
iotests: Test preallocated truncate of 2G image

Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180228131315.30194-3-mreitz@redhat.com
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 733d1dce0f3c8ab7b79a173f6482781d3718f844)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoblock/file-posix: Fix fully preallocated truncate
Max Reitz [Wed, 28 Feb 2018 13:13:14 +0000 (14:13 +0100)]
block/file-posix: Fix fully preallocated truncate

Storing the lseek() result in an int results in it overflowing when the
file is at least 2 GB big.  Then, we have a 50 % chance of the result
being "negative" and thus thinking an error occurred when actually
everything went just fine.

So we should use the correct type for storing the result: off_t.

Reported-by: Daniel P. Berrange <berrange@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1549231
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180228131315.30194-2-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 82b45e0a0b824787bd79ce3f6453eaa2afddd138)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoqemu-pr-helper: Actually allow users to specify pidfile
Michal Privoznik [Sat, 24 Mar 2018 05:14:49 +0000 (06:14 +0100)]
qemu-pr-helper: Actually allow users to specify pidfile

Due to wrong specification of arguments to getopt_long() any
attempt to set pidfile resulted in:

1) the default to be leaked
2) the @pidfile variable to be set to NULL (because optarg is
NULL without this patch).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Message-Id: <6f10cd53d361a395aa0e85a9311ec4e9a8fc11e5.1521868451.git.mprivozn@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit f8e1a989644f22ba2f7afb0e13b6ce2309ea9503)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agovirtio_net: flush uncompleted TX on reset
Greg Kurz [Tue, 20 Mar 2018 10:44:56 +0000 (11:44 +0100)]
virtio_net: flush uncompleted TX on reset

If the backend could not transmit a packet right away for some reason,
the packet is queued for asynchronous sending. The corresponding vq
element is tracked in the async_tx.elem field of the VirtIONetQueue,
for later freeing when the transmission is complete.

If a reset happens before completion, virtio_net_tx_complete() will push
async_tx.elem back to the guest anyway, and we end up with the inuse flag
of the vq being equal to -1. The next call to virtqueue_pop() is then
likely to fail with "Virtqueue size exceeded".

This can be reproduced easily by starting a guest with an hubport backend
that is not connected to a functional network, eg,

 -device virtio-net-pci,netdev=hub0 -netdev hubport,id=hub0,hubid=0

and no other -netdev hubport,hubid=0 on the command line.

The appropriate fix is to ensure that such an asynchronous transmission
cannot survive a device reset. So for all queues, we first try to send
the packet again, and eventually we purge it if the backend still could
not deliver it.

CC: qemu-stable@nongnu.org
Reported-by: R. Nageswara Sastry <nasastry@in.ibm.com>
Buglink: https://github.com/open-power-host-os/qemu/issues/37
Signed-off-by: Greg Kurz <groug@kaod.org>
Tested-by: R. Nageswara Sastry <nasastry@in.ibm.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 94b52958b77a2a040564cf7ed716d3a9545d94e5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoarm/translate-a64: treat DISAS_UPDATE as variant of DISAS_EXIT
Victor Kamensky [Fri, 23 Mar 2018 18:26:45 +0000 (18:26 +0000)]
arm/translate-a64: treat DISAS_UPDATE as variant of DISAS_EXIT

In OE project 4.15 linux kernel boot hang was observed under
single cpu aarch64 qemu. Kernel code was in a loop waiting for
vtimer arrival, spinning in TC generated blocks, while interrupt
was pending unprocessed. This happened because when qemu tried to
handle vtimer interrupt target had interrupts disabled, as
result flag indicating TCG exit, cpu->icount_decr.u16.high,
was cleared but arm_cpu_exec_interrupt function did not call
arm_cpu_do_interrupt to process interrupt. Later when target
reenabled interrupts, it happened without exit into main loop, so
following code that waited for result of interrupt execution
run in infinite loop.

To solve the problem instructions that operate on CPU sys state
(i.e enable/disable interrupt), and marked as DISAS_UPDATE,
should be considered as DISAS_EXIT variant, and should be
forced to exit back to main loop so qemu will have a chance
processing pending CPU state updates, including pending
interrupts.

This change brings consistency with how DISAS_UPDATE is treated
in aarch32 case.

CC: Peter Maydell <peter.maydell@linaro.org>
CC: Alex Bennée <alex.bennee@linaro.org>
CC: qemu-stable@nongnu.org
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 1521526368-1996-1-git-send-email-kamensky@cisco.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit a75a52d62418dafe462be4fe30485501d1010bb9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotests/multiboot: Add .gitignore
Kevin Wolf [Wed, 14 Mar 2018 12:34:40 +0000 (13:34 +0100)]
tests/multiboot: Add .gitignore

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit e2679395d598bd40770c22a793c0152576ac211f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotests/multiboot: Add tests for the a.out kludge
Kevin Wolf [Wed, 14 Mar 2018 12:33:49 +0000 (13:33 +0100)]
tests/multiboot: Add tests for the a.out kludge

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
(cherry picked from commit 1c8c426fb44bf5b3ffbcad1b00c7def4b89b03ec)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agotests/multiboot: Test exit code for every qemu run
Kevin Wolf [Wed, 14 Mar 2018 12:29:46 +0000 (13:29 +0100)]
tests/multiboot: Test exit code for every qemu run

Testing the exit code only once after a whole group of tests has
completed is not enough, it catches errors only in the very last qemu
invocation. We need to have the check after each qemu run.

The logging and diff with the reference output is still done once per
group to keep things more managable. This is not a problem because the
log file accumulates the output of all runs.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
(cherry picked from commit 49713c413a65ab4b02124aabe83f8539cc6ece5e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: Check validity of mh_header_addr
Kevin Wolf [Wed, 14 Mar 2018 16:57:45 +0000 (17:57 +0100)]
multiboot: Check validity of mh_header_addr

I couldn't find a case where this prevents something bad from happening
that isn't already caught by other checks, but let's err on the safe
side and check that mh_header_addr is as expected.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
(cherry picked from commit dbf2dce7aabb7723542bd182175904846d70b0f9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: Reject kernels exceeding the address space
Kevin Wolf [Wed, 14 Mar 2018 16:46:38 +0000 (17:46 +0100)]
multiboot: Reject kernels exceeding the address space

The code path where mh_load_end_addr is non-zero in the Multiboot
header checks that mh_load_end_addr >= mh_load_addr and so
mb_load_size is checked.  However, mb_load_size is not checked when
calculated from the file size, when mh_load_end_addr is 0.

If the kernel binary size is larger than can fit in the address space
after load_addr, we ended up with a kernel_size that is smaller than
load_size, which means that we read the file into a too small buffer.

Add a check to reject kernel files with such Multiboot headers.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
(cherry picked from commit b17a9054a0652a1481be48a6729e972abf02412f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: fprintf(stderr...) -> error_report()
Jack Schwartz [Thu, 21 Dec 2017 17:25:18 +0000 (09:25 -0800)]
multiboot: fprintf(stderr...) -> error_report()

Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call
error_report() instead, including the mb_debug macro.  Remove the "\n"
from strings passed to all modified calls, since error_report() appends
one.

Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 4b9006a41ea8818f2385ae5228e07f211bb4a33d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: Use header names when displaying fields
Jack Schwartz [Thu, 21 Dec 2017 17:25:17 +0000 (09:25 -0800)]
multiboot: Use header names when displaying fields

Refer to field names when displaying fields in printf and debug statements.

Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ce5eb6dc4dc5652f7e360a1db817f1d5dafab90f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: Remove unused variables from multiboot.c
Jack Schwartz [Thu, 21 Dec 2017 17:25:16 +0000 (09:25 -0800)]
multiboot: Remove unused variables from multiboot.c

Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth

Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 7a2e43cc96fd017883973caf9ee076ae23a3bebd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomultiboot: bss_end_addr can be zero
Jack Schwartz [Thu, 21 Dec 2017 17:25:15 +0000 (09:25 -0800)]
multiboot: bss_end_addr can be zero

The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/),
section 3.1.3, allows for bss_end_addr to be zero.

A zero bss_end_addr signifies there is no .bss section.

Suggested-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomigration/block: reset dirty bitmap before read in bulk phase
Peter Lieven [Thu, 8 Mar 2018 11:18:25 +0000 (12:18 +0100)]
migration/block: reset dirty bitmap before read in bulk phase

Reset the dirty bitmap before reading to make sure we don't miss
any new data.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-Id: <1520507908-16743-3-git-send-email-pl@kamp.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 86b124bc76bd7137d0fb20696c4e349571b8533d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomemory: fix flatview_access_valid RCU read lock/unlock imbalance
Paolo Bonzini [Wed, 7 Mar 2018 13:02:38 +0000 (14:02 +0100)]
memory: fix flatview_access_valid RCU read lock/unlock imbalance

Fixes: 11e732a5ed46903f997985bed4c3767ca28a7eb6
Reported-by: Cornelia Huck <cohuck@redhat.com>
Reported-by: luigi burdo <intermediadc@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Cornelia Huck <cohuck@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-id: 20180307130238.19358-1-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b39b61e410022f96ceb53d4381d25cba5126ac44)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoaddress_space_rw: address_space_to_flatview needs RCU lock
Paolo Bonzini [Mon, 5 Mar 2018 08:29:04 +0000 (09:29 +0100)]
address_space_rw: address_space_to_flatview needs RCU lock

address_space_rw is calling address_space_to_flatview but it can
be called outside the RCU lock.  To fix it, transform flatview_rw
into address_space_rw, since flatview_rw is otherwise unused.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit db84fd973eba3f1e121416dcab73a4e8a60f2526)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoaddress_space_map: address_space_to_flatview needs RCU lock
Paolo Bonzini [Sun, 4 Mar 2018 23:23:26 +0000 (00:23 +0100)]
address_space_map: address_space_to_flatview needs RCU lock

address_space_map is calling address_space_to_flatview but it can
be called outside the RCU lock.  The function itself is calling
rcu_read_lock/rcu_read_unlock, just in the wrong place, so the
fix is easy.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit ad0c60fa572d4050255b698ecdb67294dd4c0125)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoaddress_space_access_valid: address_space_to_flatview needs RCU lock
Paolo Bonzini [Sun, 4 Mar 2018 23:23:26 +0000 (00:23 +0100)]
address_space_access_valid: address_space_to_flatview needs RCU lock

address_space_access_valid is calling address_space_to_flatview but it can
be called outside the RCU lock.  To fix it, push the rcu_read_lock/unlock
pair up from flatview_access_valid to address_space_access_valid.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 11e732a5ed46903f997985bed4c3767ca28a7eb6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoaddress_space_read: address_space_to_flatview needs RCU lock
Paolo Bonzini [Sun, 4 Mar 2018 23:19:49 +0000 (00:19 +0100)]
address_space_read: address_space_to_flatview needs RCU lock

address_space_read is calling address_space_to_flatview but it can
be called outside the RCU lock.  To fix it, push the rcu_read_lock/unlock
pair up from flatview_read_full to address_space_read's constant size
fast path and address_space_read_full.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b2a44fcad74f1cc7a6786d38eba7db12ab2352ba)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoaddress_space_write: address_space_to_flatview needs RCU lock
Paolo Bonzini [Mon, 5 Mar 2018 08:23:56 +0000 (09:23 +0100)]
address_space_write: address_space_to_flatview needs RCU lock

address_space_write is calling address_space_to_flatview but it can
be called outside the RCU lock.  To fix it, push the rcu_read_lock/unlock
pair up from flatview_write to address_space_write.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4c6ebbb364aa6f42c5d8e83e932e967eb83f0e44)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agomemory: inline some performance-sensitive accessors
Paolo Bonzini [Sun, 4 Mar 2018 23:31:20 +0000 (00:31 +0100)]
memory: inline some performance-sensitive accessors

These accessors are called from inlined functions, and the call sequence
is much more expensive than just inlining the access.  Move the
struct declaration to memory-internal.h so that exec.c and memory.c
can both use an inline function.

Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 785a507ec78bbda1c346f3d3593e5a58b62e73ef)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agoopenpic_kvm: drop address_space_to_flatview call
Paolo Bonzini [Mon, 5 Mar 2018 08:18:26 +0000 (09:18 +0100)]
openpic_kvm: drop address_space_to_flatview call

The MemoryListener is registered on address_space_memory, there is
not much to assert.  This currently works because the callback
is invoked only once when the listener is registered, but section->fv
is the _new_ FlatView, not the old one on later calls and that
would break.

This confines address_space_to_flatview to exec.c and memory.c.

Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 80d2b933f9fe3e53d4f76a45a1bc1a0175669468)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agosparc: fix leon3 casa instruction when MMU is disabled
KONRAD Frederic [Fri, 2 Mar 2018 09:59:25 +0000 (10:59 +0100)]
sparc: fix leon3 casa instruction when MMU is disabled

Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8:
`casa [..](10), .., ..` (and probably others alternate space instructions)
triggers a data access exception when the MMU is disabled.

When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU
is disabled. Just keep mem_idx unchanged in this case so we passthrough the
MMU when it is disabled.

Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
(cherry picked from commit 6e10f37c86068e35151f982c976a85f1bec07ef2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
5 years agolinux-user: fix target_mprotect/target_munmap error return values
Max Filippov [Wed, 28 Feb 2018 22:16:05 +0000 (14:16 -0800)]
linux-user: fix target_mprotect/target_munmap error return values

target_mprotect/target_munmap return value goes through get_errno at the
call site, thus the functions must either set errno to host error code
and return -1 or return negative guest error code. Do the latter.

Cc: qemu-stable@nongnu.org
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20180228221609.11265-8-jcmvbkbc@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit 78cf339039c325b336442f1d7f3ccc531b22c4a0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>