qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 817a9f: target/i386: Fix handling of VEX pref


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 817a9f: target/i386: Fix handling of VEX prefixes
Date: Wed, 14 Feb 2018 13:51:51 -0800

  Branch: refs/heads/stable-2.11
  Home:   https://github.com/qemu/qemu
  Commit: 817a9fcba8043faa467929e7b0193df6bdc92211
      
https://github.com/qemu/qemu/commit/817a9fcba8043faa467929e7b0193df6bdc92211
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-08 (Mon, 08 Jan 2018)

  Changed paths:
    M target/i386/translate.c

  Log Message:
  -----------
  target/i386: Fix handling of VEX prefixes

In commit e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 we
replaced direct calls to to cpu_ld*_code() with calls
to the x86_ld*_code() wrappers which incorporate an
advance of s->pc. Unfortunately we didn't notice that
in one place the old code was deliberately not incrementing
s->pc:

@@ -4501,7 +4528,7 @@ static target_ulong disas_insn(DisasContext *s, CPUState 
*cpu)
       static const int pp_prefix[4] = {
           0, PREFIX_DATA, PREFIX_REPZ, PREFIX_REPNZ
       };
-            int vex3, vex2 = cpu_ldub_code(env, s->pc);
+            int vex3, vex2 = x86_ldub_code(env, s);
        if (!CODE64(s) && (vex2 & 0xc0) != 0xc0) {
           /* 4.1.4.6: In 32-bit mode, bits [7:6] must be 11b,

This meant we were mishandling this set of instructions.
Remove the manual advance of s->pc for the "is VEX" case
(which is now done by x86_ldub_code()) and instead rewind
PC in the case where we decide that this isn't really VEX.

Signed-off-by: Peter Maydell <address@hidden>
Cc: address@hidden
Reported-by: Alexandro Sanchez Bach <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cfcca361d77142f25fb1128755084cf91faa4db7)
Signed-off-by: Michael Roth <address@hidden>


  Commit: fd89d93e85df641d8110a2774591b9c9b63dad9b
      
https://github.com/qemu/qemu/commit/fd89d93e85df641d8110a2774591b9c9b63dad9b
  Author: Peter Lieven <address@hidden>
  Date:   2018-01-08 (Mon, 08 Jan 2018)

  Changed paths:
    M block/iscsi.c

  Log Message:
  -----------
  block/iscsi: dont leave allocmap in an invalid state on UNMAP failure

we forgot to set the allocmap to invalid if an UNMAP call fails.

Cc: address@hidden
Signed-off-by: Peter Lieven <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit aef172ffdc2f9c41d9cc043a55f1259e7c07e587)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ea311a995999f82f1647f4fd4967d4e8b3fbd806
      
https://github.com/qemu/qemu/commit/ea311a995999f82f1647f4fd4967d4e8b3fbd806
  Author: Alex Bennée <address@hidden>
  Date:   2018-01-08 (Mon, 08 Jan 2018)

  Changed paths:
    M target/sh4/translate.c

  Log Message:
  -----------
  target/sh4: fix TCG leak during gusa sequence

This fixes bug #1735384 while running java under qemu-sh4. When debug
was enabled it showed a problem with TCG temps. Once fixed I was able
to run java -version normally.

Cc: address@hidden
Reported-by: John Paul Adrian Glaubitz <address@hidden>
Suggested-by: Richard Henderson <address@hidden>
Signed-off-by: Alex Bennée <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Aurelien Jarno <address@hidden>
Signed-off-by: Aurelien Jarno <address@hidden>
(cherry picked from commit 6d56fc6cc372284a4571f09b361a9ccd99318103)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5ba945f1cbdf1f6d0b0ea6f6a722b1ddc1eef0b7
      
https://github.com/qemu/qemu/commit/5ba945f1cbdf1f6d0b0ea6f6a722b1ddc1eef0b7
  Author: Markus Armbruster <address@hidden>
  Date:   2018-01-08 (Mon, 08 Jan 2018)

  Changed paths:
    M qemu-options-wrapper.h
    M qemu-options.hx
    M scripts/hxtool

  Log Message:
  -----------
  qemu-options: Remove stray colons from output of --help

Commit 43f187a broke --help: it put colons into blank lines.  It
removed the colon from DEFHEADING(TITLE:) and added it back in the
macro expansion of DEFHEADING(TITLE), so hxtool can emit "@subsection
TITLE" more easily.  Trouble is it's added back even for the blank
lines made with DEFHEADING().

Put the colons back where they were before commit 43f187a, and strip
them in hxtool instead.

Cc: Paolo Bonzini <address@hidden>
CC: address@hidden
Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
(cherry picked from commit de6b4f908c300c7e7e0dc057310f5cbdcf1aed78)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c184e17c757a0b8ea7b4a582653957610645d13e
      
https://github.com/qemu/qemu/commit/c184e17c757a0b8ea7b4a582653957610645d13e
  Author: Paolo Bonzini <address@hidden>
  Date:   2018-01-08 (Mon, 08 Jan 2018)

  Changed paths:
    M include/scsi/utils.h
    M scsi/qemu-pr-helper.c
    M scsi/utils.c

  Log Message:
  -----------
  qemu-pr-helper: miscellaneous fixes

1) Return a generic sense if TEST UNIT READY does not provide one;

2) Fix two mistakes in copying from the spec.

Cc: address@hidden
Reported-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit a4a9b6eaf35dbe4bf0e069854945bf5e45fc7eab)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b9da3c1de7829a982685029222482cc5914638f4
      
https://github.com/qemu/qemu/commit/b9da3c1de7829a982685029222482cc5914638f4
  Author: Murilo Opsfelder Araujo <address@hidden>
  Date:   2018-01-09 (Tue, 09 Jan 2018)

  Changed paths:
    M block/nbd.c

  Log Message:
  -----------
  block/nbd: fix segmentation fault when .desc is not null-terminated

The find_desc_by_name() from util/qemu-option.c relies on the .name not being
NULL to call strcmp(). This check becomes unsafe when the list is not
NULL-terminated, which is the case of nbd_runtime_opts in block/nbd.c, and can
result in segmentation fault when strcmp() tries to access an invalid memory:

    #0 0x00007fff8c75f7d4 in __strcmp_power9 () from /lib64/libc.so.6
    #1 0x00000000102d3ec8 in find_desc_by_name (desc=0x1036d6f0, 
name=0x28e46670 "server.path") at util/qemu-option.c:166
    #2 0x00000000102d93e0 in qemu_opts_absorb_qdict (opts=0x28e47a80, 
qdict=0x28e469a0, errp=0x7fffec247c98) at util/qemu-option.c:1026
    #3 0x000000001012a2e4 in nbd_open (bs=0x28e42290, options=0x28e469a0, 
flags=24578, errp=0x7fffec247d80) at block/nbd.c:406
    #4 0x00000000100144e8 in bdrv_open_driver (bs=0x28e42290, drv=0x1036e070 
<bdrv_nbd_unix>, node_name=0x0, options=0x28e469a0, open_flags=24578, 
errp=0x7fffec247f50) at block.c:1135
    #5 0x0000000010015b04 in bdrv_open_common (bs=0x28e42290, file=0x0, 
options=0x28e469a0, errp=0x7fffec247f50) at block.c:1395

>From gdb, the desc[i].name was not NULL and resulted in strcmp() accessing an
invalid memory:

    >>> p desc[5]
    $8 = {
      name = 0x1037f098 "R27A",
      type = 1561964883,
      help = 0xc0bbb23e <error: Cannot access memory at address 0xc0bbb23e>,
      def_value_str = 0x2 <error: Cannot access memory at address 0x2>
    }
    >>> p desc[6]
    $9 = {
      name = 0x103dac78 <__gcov0.do_qemu_init_bdrv_nbd_init> "\001",
      type = 272101528,
      help = 0x29ec0b754403e31f <error: Cannot access memory at address 
0x29ec0b754403e31f>,
      def_value_str = 0x81f343b9 <error: Cannot access memory at address 
0x81f343b9>
    }

This patch fixes the segmentation fault in strcmp() by adding a NULL element at
the end of nbd_runtime_opts.desc list, which is the common practice to most of
other structs like runtime_opts in block/null.c. Thus, the desc[i].name != NULL
check becomes safe because it will not evaluate to true when .desc list reached
its end.

Reported-by: R. Nageswara Sastry <address@hidden>
Buglink: https://bugs.launchpad.net/qemu/+bug/1727259
Signed-off-by: Murilo Opsfelder Araujo <address@hidden>
Message-Id: <address@hidden>
CC: address@hidden
Fixes: 7ccc44fd7d1dfa62c4d6f3a680df809d6e7068ce
Signed-off-by: Eric Blake <address@hidden>
(cherry picked from commit c4365735a7d38f4355c6f77e6670d3972315f7c2)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 057364da7741285284fc2f6fd9ad8921bda6438b
      
https://github.com/qemu/qemu/commit/057364da7741285284fc2f6fd9ad8921bda6438b
  Author: Kevin Wolf <address@hidden>
  Date:   2018-01-09 (Tue, 09 Jan 2018)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block: Make bdrv_drain_invoke() recursive

This change separates bdrv_drain_invoke(), which calls the BlockDriver
drain callbacks, from bdrv_drain_recurse(). Instead, the function
performs its own recursion now.

One reason for this is that bdrv_drain_recurse() can be called multiple
times by bdrv_drain_all_begin(), but the callbacks may only be called
once. The separation is necessary to fix this bug.

The other reason is that we intend to go to a model where we call all
driver callbacks first, and only then start polling. This is not fully
achieved yet with this patch, as bdrv_drain_invoke() contains a
BDRV_POLL_WHILE() loop for the block driver callbacks, which can still
call callbacks for any unrelated event. It's a step in this direction
anyway.

Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit db0289b9b26cb653d5662f5d6a2a52d70243cd56)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 2b0c34cf61dbf9fa2d3ab78f0c43609cb781c5a9
      
https://github.com/qemu/qemu/commit/2b0c34cf61dbf9fa2d3ab78f0c43609cb781c5a9
  Author: Kevin Wolf <address@hidden>
  Date:   2018-01-09 (Tue, 09 Jan 2018)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block: Call .drain_begin only once in bdrv_drain_all_begin()

bdrv_drain_all_begin() used to call the .bdrv_co_drain_begin() driver
callback inside its polling loop. This means that how many times it got
called for each node depended on long it had to poll the event loop.

This is obviously not right and results in nodes that stay drained even
after bdrv_drain_all_end(), which calls .bdrv_co_drain_begin() once per
node.

Fix bdrv_drain_all_begin() to call the callback only once, too.

Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit 2da9b7d456278bccc6ce889ae350f2867155d7e8)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7f53a8107386d2943ff83c3224775a3eea82b767
      
https://github.com/qemu/qemu/commit/7f53a8107386d2943ff83c3224775a3eea82b767
  Author: Fam Zheng <address@hidden>
  Date:   2018-01-09 (Tue, 09 Jan 2018)

  Changed paths:
    M block.c

  Log Message:
  -----------
  block: Open backing image in force share mode for size probe

Management tools create overlays of running guests with qemu-img:

  $ qemu-img create -b /image/in/use.qcow2 -f qcow2 /overlay/image.qcow2

but this doesn't work anymore due to image locking:

    qemu-img: /overlay/image.qcow2: Failed to get shared "write" lock
    Is another process using the image?
    Could not open backing image to determine size.
Use the force share option to allow this use case again.

Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit cc954f01e3c004aad081aa36736a17e842b80211)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d6f1448277ac228dcc60346204d88363c94a1e3c
      
https://github.com/qemu/qemu/commit/d6f1448277ac228dcc60346204d88363c94a1e3c
  Author: Alex Williamson <address@hidden>
  Date:   2018-01-09 (Tue, 09 Jan 2018)

  Changed paths:
    M hw/vfio/common.c

  Log Message:
  -----------
  vfio: Fix vfio-kvm group registration

Commit 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container
attaching") moved registration of groups with the vfio-kvm device from
vfio_get_group() to vfio_connect_container(), but it missed the case
where a group is attached to an existing container and takes an early
exit.  Perhaps this is a less common case on ppc64/spapr, but on x86
(without viommu) all groups are connected to the same container and
thus only the first group gets registered with the vfio-kvm device.
This becomes a problem if we then hot-unplug the devices associated
with that first group and we end up with KVM being misinformed about
any vfio connections that might remain.  Fix by including the call to
vfio_kvm_device_add_group() in this early exit path.

Fixes: 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container 
attaching")
Cc: address@hidden # qemu-2.10+
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Tested-by: Peter Xu <address@hidden>
Reviewed-by: Eric Auger <address@hidden>
Tested-by: Eric Auger <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>
(cherry picked from commit 2016986aedb6ea2839662eb5f60630f3e231bd1a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 62425350b543a6d173131f7b1df7607a324b4ddd
      
https://github.com/qemu/qemu/commit/62425350b543a6d173131f7b1df7607a324b4ddd
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-11 (Thu, 11 Jan 2018)

  Changed paths:
    M hw/intc/arm_gicv3_dist.c
    M hw/intc/arm_gicv3_its_common.c
    M hw/intc/arm_gicv3_redist.c

  Log Message:
  -----------
  hw/intc/arm_gicv3: Make reserved register addresses RAZ/WI

The GICv3 specification says that reserved register addresses
should RAZ/WI. This means we need to return MEMTX_OK, not MEMTX_ERROR,
because now that we support generating external aborts the
latter will cause an abort on new board models.

Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Reviewed-by: Alistair Francis <address@hidden>
(cherry picked from commit f1945632b43e36bd9f3e0c2feb0e5b152be7ed91)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0af294d774a8fd7b79646d003124577f1798b585
      
https://github.com/qemu/qemu/commit/0af294d774a8fd7b79646d003124577f1798b585
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-11 (Thu, 11 Jan 2018)

  Changed paths:
    M hw/intc/arm_gic.c

  Log Message:
  -----------
  hw/intc/arm_gic: reserved register addresses are RAZ/WI

The GICv2 specification says that reserved register addresses
must RAZ/WI; now that we implement external abort handling
for Arm CPUs this means we must return MEMTX_OK rather than
MEMTX_ERROR, to avoid generating a spurious guest data abort.

Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Reviewed-by: Alistair Francis <address@hidden>
(cherry picked from commit 0cf09852015e47a5fbb974ff7ac320366afd21ee)
Signed-off-by: Michael Roth <address@hidden>


  Commit: f79312153902cb486c67a9817c4d827f67cd41ff
      
https://github.com/qemu/qemu/commit/f79312153902cb486c67a9817c4d827f67cd41ff
  Author: Michael S. Tsirkin <address@hidden>
  Date:   2018-01-15 (Mon, 15 Jan 2018)

  Changed paths:
    M hw/virtio/virtio.c

  Log Message:
  -----------
  virtio_error: don't invoke status callbacks

Backends don't need to know what frontend requested a reset,
and notifying then from virtio_error is messy because
virtio_error itself might be invoked from backend.

Let's just set the status directly.

Cc: address@hidden
Reported-by: Ilya Maximets <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 8fc47c876de638353bb635872f2c25bb7f4a3d6e)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 88bf4a70dfc5a552a2683e8ae861453e1d385a23
      
https://github.com/qemu/qemu/commit/88bf4a70dfc5a552a2683e8ae861453e1d385a23
  Author: Jay Zhou <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/virtio/vhost-user.c

  Log Message:
  -----------
  vhost: remove assertion to prevent crash

QEMU will assert on vhost-user backed virtio device hotplug if QEMU is
using more RAM regions than VHOST_MEMORY_MAX_NREGIONS (for example if
it were started with a lot of DIMM devices).

Fix it by returning error instead of asserting and let callers of
vhost_set_mem_table() handle error condition gracefully.

Cc: address@hidden
Signed-off-by: Igor Mammedov <address@hidden>
Signed-off-by: Jay Zhou <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit f4bf56fb78ed0e9f60fa1ed656c14ff4c494da5a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 3f44190cb65e41c97e8fb56be22e1e7769cbf373
      
https://github.com/qemu/qemu/commit/3f44190cb65e41c97e8fb56be22e1e7769cbf373
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/sd/pl181.c

  Log Message:
  -----------
  hw/sd/pl181: Reset SD card on controller reset

Since pl181 is still using the legacy SD card API, the SD
card created by sd_init() is not plugged into any bus. This
means that the controller has to reset it manually.

Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.

Cc: address@hidden
Fixes: https://bugs.launchpad.net/qemu/+bug/1739378
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
(cherry picked from commit 0cb57cc701839e7358918d5f2922ccbc04d28d17)
Signed-off-by: Michael Roth <address@hidden>


  Commit: a22b8096b60431d32e7b6bbef0ccb1ff1c984ed5
      
https://github.com/qemu/qemu/commit/a22b8096b60431d32e7b6bbef0ccb1ff1c984ed5
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/sd/milkymist-memcard.c

  Log Message:
  -----------
  hw/sd/milkymist-memcard: Reset SD card on controller reset

Since milkymist-memcard is still using the legacy SD card API,
the SD card created by sd_init() is not plugged into any bus.
This means that the controller has to reset it manually.

Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.

Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
(cherry picked from commit 16bf0e0e7aaa8efc0b8ee7e2aecb2fa235f82d38)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1e14820884c60be71646c8b83f536c209e1205b4
      
https://github.com/qemu/qemu/commit/1e14820884c60be71646c8b83f536c209e1205b4
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/sd/ssi-sd.c

  Log Message:
  -----------
  hw/sd/ssi-sd: Reset SD card on controller reset

Since ssi-sd is still using the legacy SD card API, the SD
card created by sd_init() is not plugged into any bus. This
means that the controller has to reset it manually.

Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.

In the case of sd-ssi, we have to implement an entire
reset function since there wasn't one previously, and
that requires a QOM cast macro that got omitted when this
device was QOMified.

Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
(cherry picked from commit 8046d44f3c9f67828d3368797d4d314433ee75e9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ccf82aee58424418845c881e1db5ca6d03918112
      
https://github.com/qemu/qemu/commit/ccf82aee58424418845c881e1db5ca6d03918112
  Author: Stefan Hajnoczi <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/scsi/scsi-disk.c

  Log Message:
  -----------
  scsi-disk: release AioContext in unaligned WRITE SAME case

scsi_write_same_complete() can retry the write if the request was
unaligned.  Make sure to release the AioContext when that code path is
taken!

This patch fixes a hang when QEMU terminates after an unaligned WRITE
SAME request has been processed with dataplane.  The hang occurs because
iothread_stop_all() cannot acquire the AioContext lock that was leaked
by the IOThread in scsi_write_same_complete().

Fixes: b9e413dd37 ("block: explicitly acquire aiocontext in aio callbacks that 
need it").
Cc: Paolo Bonzini <address@hidden>
Cc: address@hidden
Reported-by: Cong Li <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 24355b79bdaf6ab12f7c610b032fc35ec045cd55)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1027f3419b20329776696df343dbc8dc320d6b1b
      
https://github.com/qemu/qemu/commit/1027f3419b20329776696df343dbc8dc320d6b1b
  Author: Marcel Apfelbaum <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M hw/pci-bridge/gen_pcie_root_port.c

  Log Message:
  -----------
  hw/pci-bridge: fix QEMU crash because of pcie-root-port

If we try to use more pcie_root_ports then available slots
and an IO hint is passed to the port, QEMU crashes because
we try to init the "IO hint" capability even if the device
is not created.
Fix it by checking for error before adding the capability,
so QEMU can fail gracefully.

Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit fced4d00e68e7559c73746d963265f7fd0b6abf9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 4b220d88ba76fb2623ce4b8ba1f1eea66b82144e
      
https://github.com/qemu/qemu/commit/4b220d88ba76fb2623ce4b8ba1f1eea66b82144e
  Author: Eduardo Habkost <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386: Change X86CPUDefinition::model_id to const char*

It is valid to have a 48-character model ID on CPUID, however the
definition of X86CPUDefinition::model_id is char[48], which can
make the compiler drop the null terminator from the string.

If a CPU model happens to have 48 bytes on model_id, "-cpu help"
will print garbage and the object_property_set_str() call at
x86_cpu_load_def() will read data outside the model_id array.

We could increase the array size to 49, but this would mean the
compiler would not issue a warning if a 49-char string is used by
mistake for model_id.

To make things simpler, simply change model_id to be const char*,
and validate the string length using an assert() on
x86_register_cpudef_type().

Reported-by: "Dr. David Alan Gilbert" <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 807e9869b8c4119b81df902625af818519e01759)
Signed-off-by: Michael Roth <address@hidden>


  Commit: cb2637a5ae1f4e61af423395300548f14e8a2e2a
      
https://github.com/qemu/qemu/commit/cb2637a5ae1f4e61af423395300548f14e8a2e2a
  Author: Paolo Bonzini <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.h
    M target/i386/kvm.c
    M target/i386/machine.c

  Log Message:
  -----------
  i386: Add support for SPEC_CTRL MSR

Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit a33a2cfe2f771b360b3422f6cdf566a560860bfc)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 803d42fa65a371f7bb13180a5953299dc3a160e0
      
https://github.com/qemu/qemu/commit/803d42fa65a371f7bb13180a5953299dc3a160e0
  Author: Eduardo Habkost <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Add spec-ctrl CPUID bit

Add the feature name and a CPUID_7_0_EDX_SPEC_CTRL macro.

Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit a2381f0934432ef2cd47a335348ba8839632164c)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1ade973f5202404e772aae7b1acd331270d246dc
      
https://github.com/qemu/qemu/commit/1ade973f5202404e772aae7b1acd331270d246dc
  Author: Eduardo Habkost <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  i386: Add FEAT_8000_0008_EBX CPUID feature word

Add the new feature word and the "ibpb" feature flag.

Based on a patch by Paolo Bonzini.

Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 1b3420e1c4d523c49866cca4e7544753201cd43d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 61efbbf869293f1deb9ee39d44bd4e635de59fa7
      
https://github.com/qemu/qemu/commit/61efbbf869293f1deb9ee39d44bd4e635de59fa7
  Author: Eduardo Habkost <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386: Add new -IBRS versions of Intel CPU models

The new MSR IA32_SPEC_CTRL MSR was introduced by a recent Intel
microcode updated and can be used by OSes to mitigate
CVE-2017-5715.  Unfortunately we can't change the existing CPU
models without breaking existing setups, so users need to
explicitly update their VM configuration to use the new *-IBRS
CPU model if they want to expose IBRS to guests.

The new CPU models are simple copies of the existing CPU models,
with just CPUID_7_0_EDX_SPEC_CTRL added and model_id updated.

Cc: Jiri Denemark <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit ac96c41354b7e4c70b756342d9b686e31ab87458)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 8ebfafa796ca0cb2b035a7f06f836a675d8b48be
      
https://github.com/qemu/qemu/commit/8ebfafa796ca0cb2b035a7f06f836a675d8b48be
  Author: Eduardo Habkost <address@hidden>
  Date:   2018-01-23 (Tue, 23 Jan 2018)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386: Add EPYC-IBPB CPU model

EPYC-IBPB is a copy of the EPYC CPU model with
just CPUID_8000_0008_EBX_IBPB added.

Cc: Jiri Denemark <address@hidden>
Cc: Tom Lendacky <address@hidden>
Cc: Brijesh Singh <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 6cfbc54e8903a9bcc0346119949162d040c144c1)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 9327a8e2d639370960c1dc3e11ff5d9c2b26174c
      
https://github.com/qemu/qemu/commit/9327a8e2d639370960c1dc3e11ff5d9c2b26174c
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M linux-user/main.c

  Log Message:
  -----------
  linux-user: Fix locking order in fork_start()

Our locking order is that the tb lock should be taken
inside the mmap_lock, but fork_start() grabs locks the
other way around. This means that if a heavily multithreaded
guest process (such as Java) calls fork() it can deadlock,
with the thread that called fork() stuck in fork_start()
with the tb lock and waiting for the mmap lock, but some
other thread in tb_find() with the mmap lock and waiting
for the tb lock. The cpu_list_lock() should also always be
taken last, not first.

Fix this by making fork_start() grab the locks in the
right order. The order in which we drop locks doesn't
matter, so we leave fork_end() the way it is.

Signed-off-by: Peter Maydell <address@hidden>
Cc: address@hidden
Reviewed-by: Paolo Bonzini <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
(cherry picked from commit 024949caf32805f4cc3e7d363a80084b47aac1f6)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e7857ad9975400ef4a35237a92e21bc3c6bfd464
      
https://github.com/qemu/qemu/commit/e7857ad9975400ef4a35237a92e21bc3c6bfd464
  Author: Claudio Imbrenda <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/s390x/s390-stattrib-kvm.c

  Log Message:
  -----------
  s390x: fix storage attributes migration for non-small guests

Fix storage attribute migration so that it does not fail for guests
with more than a few GB of RAM.
With such guests, the index in the buffer would go out of bounds,
usually by large amounts, thus receiving -EFAULT from the kernel.
Migration itself would be successful, but storage attributes would then
not be migrated completely.

This patch fixes the out of bounds access, and thus migration of all
storage attributes when the guest have large amounts of memory.

Cc: address@hidden
Signed-off-by: Claudio Imbrenda <address@hidden>
Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device")
Message-Id: <address@hidden>
Reviewed-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 46fa893355e0bd88f3c59b886f0d75cbd5f0bbbe)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 61c8e67a66dbdb85e92764b0c030fa2a2b465df3
      
https://github.com/qemu/qemu/commit/61c8e67a66dbdb85e92764b0c030fa2a2b465df3
  Author: Eric Auger <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M include/standard-headers/asm-s390/virtio-ccw.h
    M include/standard-headers/asm-x86/hyperv.h
    M include/standard-headers/linux/input-event-codes.h
    M include/standard-headers/linux/input.h
    M include/standard-headers/linux/pci_regs.h
    M linux-headers/asm-arm/kvm.h
    M linux-headers/asm-arm/kvm_para.h
    M linux-headers/asm-arm/unistd.h
    M linux-headers/asm-arm64/kvm.h
    M linux-headers/asm-arm64/unistd.h
    M linux-headers/asm-powerpc/epapr_hcalls.h
    M linux-headers/asm-powerpc/kvm.h
    M linux-headers/asm-powerpc/kvm_para.h
    M linux-headers/asm-powerpc/unistd.h
    M linux-headers/asm-s390/kvm.h
    M linux-headers/asm-s390/kvm_para.h
    M linux-headers/asm-s390/unistd.h
    M linux-headers/asm-x86/kvm.h
    M linux-headers/asm-x86/kvm_para.h
    M linux-headers/asm-x86/unistd.h
    M linux-headers/linux/kvm.h
    M linux-headers/linux/kvm_para.h
    M linux-headers/linux/psci.h
    M linux-headers/linux/userfaultfd.h
    M linux-headers/linux/vfio.h
    M linux-headers/linux/vfio_ccw.h
    M linux-headers/linux/vhost.h

  Log Message:
  -----------
  linux-headers: update to 4.15-rc1

Update headers against v4.15-rc1.

Signed-off-by: Eric Auger <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit dd8739669f95b30653a3a05cb2e21da3f52894fa)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 098132386d08b0384beca20c4c55d6e8dfbbaa52
      
https://github.com/qemu/qemu/commit/098132386d08b0384beca20c4c55d6e8dfbbaa52
  Author: Cornelia Huck <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M include/standard-headers/asm-s390/virtio-ccw.h
    M linux-headers/asm-powerpc/kvm.h
    M linux-headers/asm-s390/kvm.h
    M linux-headers/asm-s390/kvm_para.h
    M linux-headers/linux/kvm.h

  Log Message:
  -----------
  linux-headers: update

Update headers against 4.15-rc9.

Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 9cbb636270b4df6f0a548e5c34b895330db5df8b)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 4d79c0e434110219c4de108bda9af13d927f2956
      
https://github.com/qemu/qemu/commit/4d79c0e434110219c4de108bda9af13d927f2956
  Author: Christian Borntraeger <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M target/s390x/cpu.c
    M target/s390x/cpu.h
    M target/s390x/cpu_features.c
    M target/s390x/cpu_features_def.h
    M target/s390x/gen-features.c
    M target/s390x/kvm.c
    M target/s390x/machine.c

  Log Message:
  -----------
  s390x/kvm: Handle bpb feature

We need to handle the bpb control on reset and migration. Normally
stfle.82 is transparent (and the normal guest part works without
hypervisor activity). To prevent any issues we require full
host kernel support for this feature.

Cc: address@hidden
Signed-off-by: Christian Borntraeger <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
[CH: 'Branch Prediction Blocking' -> 'Branch prediction blocking']
Signed-off-by: Cornelia Huck <address@hidden>

(cherry picked from commit b073c87517d4d348c7bac0f0b35e8e83e6354d82)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5683983e99a76ced16ae12da39222d741901389d
      
https://github.com/qemu/qemu/commit/5683983e99a76ced16ae12da39222d741901389d
  Author: Christian Borntraeger <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M target/s390x/cpu_features.c
    M target/s390x/cpu_features_def.h
    M target/s390x/gen-features.c

  Log Message:
  -----------
  s390x/kvm: provide stfle.81

stfle.81 (ppa15) is a transparent facility that can be passed to the
guest without the need to implement hypervisor support. As this feature
can be provided by firmware we add it to all full models.

Cc: address@hidden
Signed-off-by: Christian Borntraeger <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 9f0d13f4f1de3cf9b70435cc4e87a301ee12471f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: dccdaacc3d2c315f16e2723c619afcb0832e01fe
      
https://github.com/qemu/qemu/commit/dccdaacc3d2c315f16e2723c619afcb0832e01fe
  Author: Fam Zheng <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M util/osdep.c

  Log Message:
  -----------
  osdep: Retry SETLK upon EINTR

We could hit lock failure if there is a signal that makes fcntl return
-1 and errno set to EINTR. In this case we should retry.

Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit f86428a1f4f91a460ed585682af70d3e8c31dc06)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 50c6998c2004a9710925f0aefc5cdcf0ab2df4c9
      
https://github.com/qemu/qemu/commit/50c6998c2004a9710925f0aefc5cdcf0ab2df4c9
  Author: Fam Zheng <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/scsi/scsi-bus.c
    M hw/usb/dev-storage.c
    M include/hw/scsi/scsi.h

  Log Message:
  -----------
  usb-storage: Fix share-rw option parsing

Because usb-storage creates an internal scsi device, we should propagate
options. We already do so for bootindex etc, but failed to take care of
share-rw. Fix it in an apparent way: add a new parameter to
scsi_bus_legacy_add_drive and pass in s->conf.share_rw.

Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 395b95395934785ca86baafd314d0c31b307d16d)
 Conflicts:
        hw/usb/dev-storage.c
* dropped context dep on ceff3e1f01e
Signed-off-by: Michael Roth <address@hidden>


  Commit: 80277d7cd5522e8dbfd68413b1a935d9f19be8e8
      
https://github.com/qemu/qemu/commit/80277d7cd5522e8dbfd68413b1a935d9f19be8e8
  Author: Greg Kurz <address@hidden>
  Date:   2018-02-01 (Thu, 01 Feb 2018)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci: fix MSI/MSIX selection

In various place we don't correctly check if the device supports MSI or
MSI-X. This can cause devices to be advertised with MSI support, even
if they only support MSI-X (like virtio-pci-* devices for example):
           address@hidden {
                  ibm,req#msi = <0x1>; <--- wrong!
                        .
                        ibm,loc-code = "qemu_virtio-net-pci:0000:00:00.0";
                        .
                        ibm,req#msi-x = <0x3>;
          };

Worse, this can also cause the "ibm,change-msi" RTAS call to corrupt the
PCI status and cause migration to fail:

  qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x6
    read: 0 device: 10 cmask: 10 wmask: 0 w1cmask:0
                        ^^
     PCI_STATUS_CAP_LIST bit which is assumed to be constant

This patch changes spapr_populate_pci_child_dt() to properly check for
MSI support using msi_present(): this ensures that PCIDevice::msi_cap
was set by msi_init() and that msi_nr_vectors_allocated() will look at
the right place in the config space.

Checking PCIDevice::msix_entries_nr is enough for MSI-X but let's add
a call to msix_present() there as well for consistency.

It also changes rtas_ibm_change_msi() to select the appropriate MSI
type in Function 1 instead of always selecting plain MSI. This new
behaviour is compliant with LoPAPR 1.1, as described in "Table 71.
ibm,change-msi Argument Call Buffer":

  Function 1: If Number Outputs is equal to 3, request to set to a new
     number of MSIs (including set to 0).
     If the “ibm,change-msix-capable” property exists and Number
     Outputs is equal to 4, request is to set to a new number of
     MSI or MSI-X (platform choice) interrupts (including set to
     0).

Since MSI is the the platform default (LoPAPR 6.2.3 MSI Option), let's
check for MSI support first.

And finally, it checks the input parameters are valid, as described in
LoPAPR 1.1 "R1–7.3.10.5.1–3":

  For the MSI option: The platform must return a Status of -3 (Parameter
  error) from ibm,change-msi, with no change in interrupt assignments if
  the PCI configuration address does not support MSI and Function 3 was
  requested (that is, the “ibm,req#msi” property must exist for the PCI
  configuration address in order to use Function 3), or does not support
  MSI-X and Function 4 is requested (that is, the “ibm,req#msi-x” property
  must exist for the PCI configuration address in order to use Function 4),
  or if neither MSIs nor MSI-Xs are supported and Function 1 is requested.

This ensures that the ret_intr_type variable contains a valid MSI type
for this device, and that spapr_msi_setmsg() won't corrupt the PCI status.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 9cbe305b60cc49cfcd134765b85c28be95b1b57d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7e25155a7bd23902d41d6b4e7d3d4f6310e86cc0
      
https://github.com/qemu/qemu/commit/7e25155a7bd23902d41d6b4e7d3d4f6310e86cc0
  Author: Peter Maydell <address@hidden>
  Date:   2018-02-01 (Thu, 01 Feb 2018)

  Changed paths:
    M linux-user/signal.c

  Log Message:
  -----------
  linux-user/signal.c: Rename MC_* defines

The SPARC code in linux-user/signal.c defines a set of
MC_* constants. On some SPARC hosts these are also defined
by sys/ucontext.h, resulting in build failures:

linux-user/signal.c:2786:0: error: "MC_NGREG" redefined [-Werror]
 #define MC_NGREG 19

In file included from /usr/include/signal.h:302:0,
           from include/qemu/osdep.h:86,
           from linux-user/signal.c:19:
/usr/include/sparc64-linux-gnu/sys/ucontext.h:59:0: note: this is the location 
of the previous definition
 # define MC_NGREG __MC_NGREG

Rename all these constants to SPARC_MC_* to avoid the clash.

Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
(cherry picked from commit 8ebb314b957403c1c9a3f1cf995f73c6ae9d5d10)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 97d17551b57bfbcae5371295cf48850076ce6caa
      
https://github.com/qemu/qemu/commit/97d17551b57bfbcae5371295cf48850076ce6caa
  Author: Laurent Vivier <address@hidden>
  Date:   2018-02-04 (Sun, 04 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: don't initialize PATB entry if max-cpu-compat < power9

if KVM is enabled and KVM capabilities MMU radix is available,
the partition table entry (patb_entry) for the radix mode is
initialized by default in ppc_spapr_reset().

It's a problem if we want to migrate the guest to a POWER8 host
while the kernel is not started to set the value to the one
expected for a POWER8 CPU.

The "-machine max-cpu-compat=power8" should allow to migrate
a POWER9 KVM host to a POWER8 KVM host, but because patb_entry
is set, the destination QEMU tries to enable radix mode on the
POWER8 host. This fails and cancels the migration:

    Process table config unsupported by the host
    error while loading state for instance 0x0 of device 'spapr'
    load of migration failed: Invalid argument

This patch doesn't set the PATB entry if the user provides
a CPU compatibility mode that doesn't support radix mode.

Signed-off-by: Laurent Vivier <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 1481fe5fcfeb7fcf3c1ebb9d8c0432e3e0188ccf)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0fac4aa93074c9966bafb6c8787e2c336f014aa7
      
https://github.com/qemu/qemu/commit/0fac4aa93074c9966bafb6c8787e2c336f014aa7
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M include/hw/compat.h

  Log Message:
  -----------
  spapr: Add pseries-2.12 machine type

While we're at it fix a couple of small errors in the 2.11 and 2.10 models
(they didn't have any real effect, but don't quite match the template).

Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 2b6154120cbd7f5514cefd3c6084d39922d26d88)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 78a38cd47e1083e67f007743c5f2448f10ff6110
      
https://github.com/qemu/qemu/commit/78a38cd47e1083e67f007743c5f2448f10ff6110
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/Makefile.objs
    M hw/ppc/spapr.c
    A hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Capabilities infrastructure

Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor.  PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.

In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.

Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.

We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability.  But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.

This introduces an infrastructure for defining "sPAPR capabilities".  These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.

The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations).  If not we simply fail, rather than silently modifying the
advertised featureset to the guest.

This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 33face6b8981add8eba1f7cdaf4cf6cede415d2e)
 Conflicts:
        include/hw/ppc/spapr.h
*drop context dep on 60c6823b9bc
Signed-off-by: Michael Roth <address@hidden>


  Commit: 9070f408f491693291f7a7335340acc93d2610a5
      
https://github.com/qemu/qemu/commit/9070f408f491693291f7a7335340acc93d2610a5
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Treat Hardware Transactional Memory (HTM) as an optional capability

This adds an spapr capability bit for Hardware Transactional Memory.  It is
enabled by default for pseries-2.11 and earlier machine types. with POWER8
or later CPUs (as it must be, since earlier qemu versions would implicitly
allow it).  However it is disabled by default for the latest pseries-2.12
machine type.

This means that with the latest machine type, HTM will not be available,
regardless of CPU, unless it is explicitly enabled on the command line.
That change is made on the basis that:

 * This way running with -M pseries,accel=tcg will start with whatever cpu
   and will provide the same guest visible model as with accel=kvm.
     - More specifically, this means existing make check tests don't have
       to be modified to use cap-htm=off in order to run with TCG

 * We hope to add a new "HTM without suspend" feature in the not too
   distant future which could work on both POWER8 and POWER9 cpus, and
   could be enabled by default.

 * Best guesses suggest that future POWER cpus may well only support the
   HTM-without-suspend model, not the (frankly, horribly overcomplicated)
   POWER8 style HTM with suspend.

 * Anecdotal evidence suggests problems with HTM being enabled when it
   wasn't wanted are more common than being missing when it was.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit ee76a09fc72cfbfab2bb5529320ef7e460adffd8)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 804e5ea9ed1ac001ca3e3b5e30843e1073296003
      
https://github.com/qemu/qemu/commit/804e5ea9ed1ac001ca3e3b5e30843e1073296003
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Validate capabilities on migration

Now that the "pseries" machine type implements optional capabilities (well,
one so far) there's the possibility of having different capabilities
available at either end of a migration.  Although arguably a user error,
it would be nice to catch this situation and fail as gracefully as we can.

This adds code to migrate the capabilities flags.  These aren't pulled
directly into the destination's configuration since what the user has
specified on the destination command line should take precedence.  However,
they are checked against the destination capabilities.

If the source was using a capability which is absent on the destination,
we fail the migration, since that could easily cause a guest crash or other
bad behaviour.  If the source lacked a capability which is present on the
destination we warn, but allow the migration to proceed.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit be85537d654565e35e359a74b46fc08b7956525c)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7c578cbc37bb4fdb54408dc565895b23020341ee
      
https://github.com/qemu/qemu/commit/7c578cbc37bb4fdb54408dc565895b23020341ee
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h

  Log Message:
  -----------
  target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM

When constructing the "host" cpu class we modify whether the VMX and VSX
vector extensions and DFP (Decimal Floating Point) are available
based on whether KVM can support those instructions.  This can depend on
policy in the host kernel as well as on the actual host cpu capabilities.

However, the way we probe for this is not very nice: we explicitly check
the host's device tree.  That works in practice, but it's not really
correct, since the device tree is a property of the host kernel's platform
which we don't really know about.  We get away with it because the only
modern POWER platforms happen to encode VMX, VSX and DFP availability in
the device tree in the same way.

Arguably we should have an explicit KVM capability for this, but we haven't
needed one so far.  Barring specific KVM policies which don't yet exist,
each of these instruction classes will be available in the guest if and
only if they're available in the qemu userspace process.  We can determine
that from the ELF AUX vector we're supplied with.

Once reworked like this, there are no more callers for kvmppc_get_vmx() and
kvmppc_get_dfp() so remove them.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 3f2ca480eb872b4946baf77f756236b637a5b15a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ff6f7e10c6991c676b9a4058e15db5262a6c38f3
      
https://github.com/qemu/qemu/commit/ff6f7e10c6991c676b9a4058e15db5262a6c38f3
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Handle VMX/VSX presence as an spapr capability flag

We currently have some conditionals in the spapr device tree code to decide
whether or not to advertise the availability of the VMX (aka Altivec) and
VSX vector extensions to the guest, based on whether the guest cpu has
those features.

This can lead to confusion and subtle failures on migration, since it makes
a guest visible change based only on host capabilities.  We now have a
better mechanism for this, in spapr capabilities flags, which explicitly
depend on user options rather than host capabilities.

Rework the advertisement of VSX and VMX based on a new VSX capability.  We
no longer bother with a conditional for VMX support, because every CPU
that's ever been supported by the pseries machine type supports VMX.

NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on
availability of VSX in libc, so using cap-vsx=off may lead to a fatal
SIGILL in init.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 2938664286499c0c30d6e455a7e2e5d3e6c3f63d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e4f4fa00ebebe4b2c2f2ec2d27b7a2b77ce1c25f
      
https://github.com/qemu/qemu/commit/e4f4fa00ebebe4b2c2f2ec2d27b7a2b77ce1c25f
  Author: David Gibson <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  spapr: Handle Decimal Floating Point (DFP) as an optional capability

Decimal Floating Point has been available on POWER7 and later (server)
cpus.  However, it can be disabled on the hypervisor, meaning that it's
not available to guests.

We currently handle this by conditionally advertising DFP support in the
device tree depending on whether the guest CPU model supports it - which
can also depend on what's allowed in the host for -cpu host.  That can lead
to confusion on migration, since host properties are silently affecting
guest visible properties.

This patch handles it by treating it as an optional capability for the
pseries machine type.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 2d1fb9bc8e6e78931d8e1bfeb0ed7a4d223b0480)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 6a47136799c942bc8bc6eda0c39a2fe19b418864
      
https://github.com/qemu/qemu/commit/6a47136799c942bc8bc6eda0c39a2fe19b418864
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation

Currently spapr_caps are tied to boolean values (on or off). This patch
reworks the caps so that they can have any uint8 value. This allows more
capabilities with various values to be represented in the same way
internally. Capabilities are numbered in ascending order. The internal
representation of capability values is an array of uint8s in the
sPAPRMachineState, indexed by capability number.

Capabilities can have their own name, description, options, getter and
setter functions, type and allow functions. They also each have their own
section in the migration stream. Capabilities are only migrated if they
were explictly set on the command line, with the assumption that
otherwise the default will match.

On migration we ensure that the capability value on the destination
is greater than or equal to the capability value from the source. So
long at this remains the case then the migration is considered
compatible and allowed to continue.

This patch implements generic getter and setter functions for boolean
capabilities. It also converts the existings cap-htm, cap-vsx and
cap-dfp capabilities to this new format.

Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 4e5fe3688e23d61b45cc549ff1322aff8f50ef45)
 Conflicts:
        include/hw/ppc/spapr.h
*drop context dep on 60c6823b9bc
Signed-off-by: Michael Roth <address@hidden>


  Commit: a1f33a5b93f75abfdbaf4023cf9b7935285a705f
      
https://github.com/qemu/qemu/commit/a1f33a5b93f75abfdbaf4023cf9b7935285a705f
  Author: Jose Ricardo Ziviani <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M target/ppc/compat.c

  Log Message:
  -----------
  ppc: Change Power9 compat table to support at most 8 threads/core

Increases the max smt mode to 8 for Power9. That's because KVM supports
smt emulation in this platform so QEMU should allow users to use it as
well.

Today if we try to pass -smp ...,threads=8, QEMU will silently truncate
it to smt4 mode and may cause a crash if we try to perform a cpu
hotplug.

Signed-off-by: Jose Ricardo Ziviani <address@hidden>
[dwg: Added an explanatory comment]
Signed-off-by: David Gibson <address@hidden>

(cherry picked from commit 03ee51d3548f5f553a3089f466483c1c6d5c666b)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 4374cbca952851b92ec2532041f7557d959dbd23
      
https://github.com/qemu/qemu/commit/4374cbca952851b92ec2532041f7557d959dbd23
  Author: Greg Kurz <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_cpu_core.c

  Log Message:
  -----------
  spapr: fix device tree properties when using compatibility mode

Commit 51f84465dd98 changed the compatility mode setting logic:
- machine reset only sets compatibility mode for the boot CPU
- compatibility mode is set for other CPUs when they are put online
  by the guest with the "start-cpu" RTAS call

This causes a regression for machines started with max-compat-cpu:
the device tree nodes related to secondary CPU cores contain wrong
"cpu-version" and "ibm,pa-features" values, as shown below.

Guest started on a POWER8 host with:
     -smp cores=2 -machine pseries,max-cpu-compat=compat7
                   ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00
 00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00];
                  cpu-version = <0x4d0200>;
                          ^^^
                  second CPU core
                   ibm,pa-features = <0x600f63f 0xc70080c0>;
                  cpu-version = <0xf000003>;
                          ^^^
                    boot CPU core

The second core is advertised in raw POWER8 mode. This happens because
CAS assumes all CPUs to have the same compatibility mode. Since the
boot CPU already has the requested compatibility mode, the CAS code
does not set it for the secondary one, and exposes the bogus device
tree properties in in the CAS response to the guest.

A similar situation is observed when hot-plugging a CPU core. The
related device tree properties are generated and exposed to guest
with the "ibm,configure-connector" RTAS before "start-cpu" is called.
The CPU core is advertised to the guest in raw mode as well.

It both cases, it boils down to the fact that "start-cpu" happens too
late. This can be fixed globally by propagating the compatibility mode
of the boot CPU to the other CPUs during reset.  For this to work, the
compatibility mode of the boot CPU must be set before the machine code
actually resets all CPUs.

It is not needed to set the compatibility mode in "start-cpu" anymore,
so the code is dropped.

Fixes: 51f84465dd98
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 9012a53f067a78022947e18050b145c34a3dc599)
 Conflicts:
        hw/ppc/spapr_cpu_core.c
        hw/ppc/spapr_rtas.c
* drop context dep on d6322252b32
Signed-off-by: Michael Roth <address@hidden>


  Commit: d72e0a69eadc93c4f74b16c88ca0e507edaf17a4
      
https://github.com/qemu/qemu/commit/d72e0a69eadc93c4f74b16c88ca0e507edaf17a4
  Author: Cédric Le Goater <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M target/ppc/cpu.h

  Log Message:
  -----------
  target/ppc: introduce the PPC_BIT() macro

and use them in a couple of obvious places. Other macros will be used
in the model of the XIVE interrupt controller.

Signed-off-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 2a83f9976efa9a85e8ceb9d1035a68f25c321334)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 43a29f00257e8fce59bf3838b818817655f1d364
      
https://github.com/qemu/qemu/commit/43a29f00257e8fce59bf3838b818817655f1d364
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr_caps.c

  Log Message:
  -----------
  target/ppc/spapr_caps: Add macro to generate spapr_caps migration vmstate

The vmstate description and the contained needed function for migration
of spapr_caps is the same for each cap, with the name of the cap
substituted. As such introduce a macro to allow for easier generation of
these.

Convert the three existing spapr_caps (htm, vsx, and dfp) to use this
macro.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 1f63ebaa91f73f469c8f107dbd266cabdbea3a40)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 49b1fa33a39c14bb1116507ea689454f8a052dcb
      
https://github.com/qemu/qemu/commit/49b1fa33a39c14bb1116507ea689454f8a052dcb
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M include/hw/ppc/spapr.h
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h

  Log Message:
  -----------
  target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch]

Add three new kvm capabilities used to represent the level of host support
for three corresponding workarounds.

Host support for each of the capabilities is queried through the
new ioctl KVM_PPC_GET_CPU_CHAR which returns four uint64 quantities. The
first two, character and behaviour, represent the available
characteristics of the cpu and the behaviour of the cpu respectively.
The second two, c_mask and b_mask, represent the mask of known bits for
the character and beheviour dwords respectively.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Reviewed-by: David Gibson <address@hidden>
[dwg: Correct some compile errors due to name change in final kernel
 patch version]
Signed-off-by: David Gibson <address@hidden>

(cherry picked from commit 8acc2ae5e91681ceda3ff4cf946ebf163f6012e9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e9a8747cd2fcfe783148132819b013d395178e66
      
https://github.com/qemu/qemu/commit/e9a8747cd2fcfe783148132819b013d395178e66
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  target/ppc/spapr_caps: Add support for tristate spapr_capabilities

spapr_caps are used to represent the level of support for various
capabilities related to the spapr machine type. Currently there is
only support for boolean capabilities.

Add support for tristate capabilities by implementing their get/set
functions. These capabilities can have the values 0, 1 or 2
corresponding to broken, workaround and fixed.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 6898aed77f4636c3e77af9c12631f583f22cb5db)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 3dc12273b7033b449cfc938f7afd98b926c94d79
      
https://github.com/qemu/qemu/commit/3dc12273b7033b449cfc938f7afd98b926c94d79
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  target/ppc/spapr_caps: Add new tristate cap safe_cache

Add new tristate cap cap-cfpc to represent the cache flush on privilege
change capability.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 8f38eaf8f9dd194c9961cf76c675724930ce4570)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d7aa3d0a0af9efbdfccb4db05418068a21603788
      
https://github.com/qemu/qemu/commit/d7aa3d0a0af9efbdfccb4db05418068a21603788
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  target/ppc/spapr_caps: Add new tristate cap safe_bounds_check

Add new tristate cap cap-sbbc to represent the speculation barrier
bounds checking capability.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 09114fd8179977e4157b36aab2e3d68eaf08adca)
Signed-off-by: Michael Roth <address@hidden>


  Commit: eab4b5170f1dd9b0e36722dcc118104e43d11e26
      
https://github.com/qemu/qemu/commit/eab4b5170f1dd9b0e36722dcc118104e43d11e26
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_caps.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch

Add new tristate cap cap-ibs to represent the indirect branch
serialisation capability.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 4be8d4e7d935fc8919d61f53a0f0fb7230052bb3)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ed8b4ecc68d6bfe98000b08d649049d0c1174c11
      
https://github.com/qemu/qemu/commit/ed8b4ecc68d6bfe98000b08d649049d0c1174c11
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2018-02-05 (Mon, 05 Feb 2018)

  Changed paths:
    M hw/ppc/spapr_hcall.c
    M include/hw/ppc/spapr.h

  Log Message:
  -----------
  target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS

The new H-Call H_GET_CPU_CHARACTERISTICS is used by the guest to query
behaviours and available characteristics of the cpu.

Implement the handler for this new H-Call which formulates its response
based on the setting of the spapr_caps cap-cfpc, cap-sbbc and cap-ibs.

Signed-off-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit c59704b254734182c3202e0c261589ea2ccf485e)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ab7b4f67344f1371b181d2515408f4ee4a6cd52d
      
https://github.com/qemu/qemu/commit/ab7b4f67344f1371b181d2515408f4ee4a6cd52d
  Author: linzhecheng <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: set ioeventfd_update_pending after address_space_update_ioeventfds

We should set ioeventfd_update_pending same as memory_region_update_pending.

Signed-off-by: linzhecheng <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Fixes: ade9c1aac5292ff698fa550adebe794c37d86cc9
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 0b15209571e5eae706027f42da2ecd175eddc4e3)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b8aa511bc045bba085d9b557e869a16c1ee56491
      
https://github.com/qemu/qemu/commit/b8aa511bc045bba085d9b557e869a16c1ee56491
  Author: Christian Borntraeger <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M hw/s390x/event-facility.c

  Log Message:
  -----------
  s390x/sclp: fix event mask handling

commit 67915de9f038 ("s390x/event-facility: variable-length event
masks") switched the sclp receive/send mask. This broke the sclp
lm console.

Signed-off-by: Christian Borntraeger <address@hidden>
Fixes: commit 67915de9f038 ("s390x/event-facility: variable-length event masks")
Cc: Cornelia Huck <address@hidden>
Cc: Jason J. Herne <address@hidden>
Cc: address@hidden
Message-Id: <address@hidden>
Reviewed-by: Claudio Imbrenda <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 869e676ae7c7ef678292652be8995a525e642bee)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b9eec804f4624a59d7a7347117f8bb3354c078fd
      
https://github.com/qemu/qemu/commit/b9eec804f4624a59d7a7347117f8bb3354c078fd
  Author: Ross Lagerwall <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M migration/savevm.c

  Log Message:
  -----------
  migration: Don't leak IO channels

Since qemu_fopen_channel_{in,out}put take references on the underlying
IO channels, make sure to release our references to them.

Signed-off-by: Ross Lagerwall <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit 032b79f7173051e7f8742a43d106c7fc526856f9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c8847f55656a26cef9a864689e75379410280d9b
      
https://github.com/qemu/qemu/commit/c8847f55656a26cef9a864689e75379410280d9b
  Author: Dr. David Alan Gilbert <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M migration/migration.c

  Log Message:
  -----------
  migration: Recover block devices if failure in device state

In e91d895 I added the new pause-before-switchover mechanism
to allow migration completion to be delayed; this changes the
last state prior to completion to MIGRATE_STATUS_DEVICE rather
than MIGRATE_STATUS_ACTIVE.

Fix the failure path in migration_completion to recover the block
devices if it fails in MIGRATE_STATUS_DEVICE, not just the
MIGRATE_STATUS_ACTIVE that it previously had.

This corresponds to rh bz:
  https://bugzilla.redhat.com/show_bug.cgi?id=1538494
whose symptom is an occasional source crash on a failed migration.

Fixes: e91d8951d59d483f085f
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit 6039dd5b1c45d76403b9dcadd2afd7efd8f42330)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 2095c5a2e38a51c6777640396bb471dde3948c27
      
https://github.com/qemu/qemu/commit/2095c5a2e38a51c6777640396bb471dde3948c27
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M migration/savevm.c

  Log Message:
  -----------
  migration/savevm.c: set MAX_VM_CMD_PACKAGED_SIZE to 1ul << 32

MAX_VM_CMD_PACKAGED_SIZE is a constant used in qemu_savevm_send_packaged
and loadvm_handle_cmd_packaged to determine whether a package is too
big to be sent or received. qemu_savevm_send_packaged is called inside
postcopy_start (migration/migration.c) to send the MigrationState
in a single blob to the destination, using the MIG_CMD_PACKAGED subcommand,
which will read it up using loadvm_handle_cmd_packaged. If the blob is
larger than MAX_VM_CMD_PACKAGED_SIZE, an error is thrown and the postcopy
migration is aborted. Both MAX_VM_CMD_PACKAGED_SIZE and MIG_CMD_PACKAGED
were introduced by commit 11cf1d984b ("MIG_CMD_PACKAGED: Send a packaged
chunk ..."). The constant has its original value of 1ul << 24 (16MB).

The current MAX_VM_CMD_PACKAGED_SIZE value is not enough to support postcopy
migration of bigger pseries guests. The blob size for a postcopy migration of
a pseries guest with the following setup:

qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm -m 64G \
-smp 1,maxcpus=32 -device virtio-blk-pci,drive=rootdisk \
-drive file=f27.qcow2,if=none,cache=none,format=qcow2,id=rootdisk \
-netdev user,id=u1 -net nic,netdev=u1

Goes around 12MB. Bumping the RAM to 128G makes the blob sizes goes to 20MB.
With 256G the blob goes to 37MB - more than twice the current maximum size.
At this moment the pseries machine can handle guests with up to 1TB of RAM,
making this postcopy blob goes to 128MB of size approximately.

Following the discussions made in [1], there is a need to understand what
devices are aggressively consuming the blob in that manner and see if that
can be mitigated. Until then, we can set MAX_VM_CMD_PACKAGED_SIZE to the
maximum value allowed. Since the size is a 32 bit int variable, we can set
it as 1ul << 32, giving a maximum blob size of 4G that is enough to support
postcopy migration of 32TB RAM guests given the above constraints.

[1] https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg06313.html

Signed-off-by: Daniel Henrique Barboza <address@hidden>
Reported-by: Balamuruhan S <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Juan Quintela <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit ee555cdf4d495ddd83633406e3099c5d1ef22e0a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 68d7e24475dc38195eaf9722c3a967aac5cb03bb
      
https://github.com/qemu/qemu/commit/68d7e24475dc38195eaf9722c3a967aac5cb03bb
  Author: Philippe Mathieu-Daudé <address@hidden>
  Date:   2018-02-11 (Sun, 11 Feb 2018)

  Changed paths:
    M target/sh4/translate.c

  Log Message:
  -----------
  target/sh4: add missing tcg_temp_free() in _decode_opc()

missed in c55497ecb8c and 852d481faf7.

Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Aurelien Jarno <address@hidden>
Signed-off-by: Aurelien Jarno <address@hidden>
(cherry picked from commit e691e0ed135ac989221683ca9560c34d357edc57)
Signed-off-by: Michael Roth <address@hidden>


  Commit: a3fd64f2fe9f90c7b4d002910a54049ee6a09b64
      
https://github.com/qemu/qemu/commit/a3fd64f2fe9f90c7b4d002910a54049ee6a09b64
  Author: Greg Kurz <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M migration/savevm.c

  Log Message:
  -----------
  migration: incoming postcopy advise sanity checks

If postcopy-ram was set on the source but not on the destination,
migration doesn't occur, the destination prints an error and boots
the guest:

qemu-system-ppc64: Expected vmdescription section, but got 0

We end up with two running instances.

This behaviour was introduced in 2.11 by commit 58110f0acb1a "migration:
split common postcopy out of ram postcopy" to prepare ground for the
upcoming dirty bitmap postcopy support. It adds a new case where the
source may send an empty postcopy advise because dirty bitmap doesn't
need to check page sizes like RAM postcopy does.

If the source has enabled postcopy-ram, then it sends an advise with
the page size values. If the destination hasn't enabled postcopy-ram,
then loadvm_postcopy_handle_advise() leaves the page size values on
the stream and returns. This confuses qemu_loadvm_state() later on
and causes the destination to start execution.

As discussed several times, postcopy-ram should be enabled both sides
to be functional. This patch changes the destination to perform some
extra checks on the advise length to ensure this is the case. Otherwise
an error is returned and migration is aborted.

Reported-by: Balamuruhan S <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Daniel Henrique Barboza <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit 875fcd013ab68c64802998b22f54f0184479d21b)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0181686a984ba04406b7b46b283275978ba44ab6
      
https://github.com/qemu/qemu/commit/0181686a984ba04406b7b46b283275978ba44ab6
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: remove 'sync' parameter from vnc_update_client

There is only one caller of vnc_update_client and that always passes false
for the 'sync' parameter.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 6af998db05aec9af95a06f84ad94f1b96785e667)
Signed-off-by: Michael Roth <address@hidden>


  Commit: de1e7a91c8fdec1527f454e14384653789ba7f1a
      
https://github.com/qemu/qemu/commit/de1e7a91c8fdec1527f454e14384653789ba7f1a
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: remove unreachable code in vnc_update_client

A previous commit:

  commit 5a8be0f73d6f60ff08746377eb09ca459f39deab
  Author: Gerd Hoffmann <address@hidden>
  Date:   Wed Jul 13 12:21:20 2016 +0200

    vnc: make sure we finish disconnect

Added a check for vs->disconnecting at the very start of the
vnc_update_client method. This means that the very next "if"
statement check for !vs->disconnecting always evaluates true,
and is thus redundant. This in turn means the vs->disconnecting
check at the very end of the method never evaluates true, and
is thus unreachable code.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit c53df961617736f94731d94b62c2954c261d2bae)
Signed-off-by: Michael Roth <address@hidden>


  Commit: a7b2537f8a853c47fc2ed19a67962ec5532366ee
      
https://github.com/qemu/qemu/commit/a7b2537f8a853c47fc2ed19a67962ec5532366ee
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: remove redundant indentation in vnc_client_update

Now that previous dead / unreachable code has been removed, we can simplify
the indentation in the vnc_client_update method.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit b939eb89b6f320544a9328fa908d881d0024c1ee)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 616d64ac06c1bc8ad4954827b0655c59169e8585
      
https://github.com/qemu/qemu/commit/616d64ac06c1bc8ad4954827b0655c59169e8585
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: avoid pointless VNC updates if framebuffer isn't dirty

The vnc_update_client() method checks the 'has_dirty' flag to see if there are
dirty regions that are pending to send to the client. Regardless of this flag,
if a forced update is requested, updates must be sent. For unknown reasons
though, the code also tries to sent updates if audio capture is enabled. This
makes no sense as audio capture state does not impact framebuffer contents, so
this check is removed.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 3541b08475d51bddf8aded36576a0ff5a547a978)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 8a9c5c34ac978844eff539b711a7839e4d352958
      
https://github.com/qemu/qemu/commit/8a9c5c34ac978844eff539b711a7839e4d352958
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc-auth-sasl.c
    M ui/vnc-auth-sasl.h

  Log Message:
  -----------
  ui: track how much decoded data we consumed when doing SASL encoding

When we encode data for writing with SASL, we encode the entire pending output
buffer. The subsequent write, however, may not be able to send the full encoded
data in one go though, particularly with a slow network. So we delay setting the
output buffer offset back to zero until all the SASL encoded data is sent.

Between encoding the data and completing sending of the SASL encoded data,
however, more data might have been placed on the pending output buffer. So it
is not valid to set offset back to zero. Instead we must keep track of how much
data we consumed during encoding and subtract only that amount.

With the current bug we would be throwing away some pending data without having
sent it at all. By sheer luck this did not previously cause any serious problem
because appending data to the send buffer is always an atomic action, so we
only ever throw away complete RFB protocol messages. In the case of frame buffer
updates we'd catch up fairly quickly, so no obvious problem was visible.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 126617e6f8d395aa6d432527c28ff98cdf50a4c0
      
https://github.com/qemu/qemu/commit/126617e6f8d395aa6d432527c28ff98cdf50a4c0
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui: introduce enum to track VNC client framebuffer update request state

Currently the VNC servers tracks whether a client has requested an incremental
or forced update with two boolean flags. There are only really 3 distinct
states to track, so create an enum to more accurately reflect permitted states.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit fef1bbadfb2c3027208eb3d14b43e1bdb51166ca)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 2e6571e6713d7d2b6156c99c9067cc1aa8008098
      
https://github.com/qemu/qemu/commit/2e6571e6713d7d2b6156c99c9067cc1aa8008098
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: correctly reset framebuffer update state after processing dirty regions

According to the RFB protocol, a client sends one or more framebuffer update
requests to the server. The server can reply with a single framebuffer update
response, that covers all previously received requests. Once the client has
read this update from the server, it may send further framebuffer update
requests to monitor future changes. The client is free to delay sending the
framebuffer update request if it needs to throttle the amount of data it is
reading from the server.

The QEMU VNC server, however, has never correctly handled the framebuffer
update requests. Once QEMU has received an update request, it will continue to
send client updates forever, even if the client hasn't asked for further
updates. This prevents the client from throttling back data it gets from the
server. This change fixes the flawed logic such that after a set of updates are
sent out, QEMU waits for a further update request before sending more data.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 728a7ac95484a7ba5e624ccbac4c1326571576b0)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5af9f2504fa2bc393b5b2d49ff1a85e5e11016bc
      
https://github.com/qemu/qemu/commit/5af9f2504fa2bc393b5b2d49ff1a85e5e11016bc
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: refactor code for determining if an update should be sent to the client

The logic for determining if it is possible to send an update to the client
will become more complicated shortly, so pull it out into a separate method
for easier extension later.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 0bad834228b9ee63e4239108d02dcb94568254d0)
Signed-off-by: Michael Roth <address@hidden>


  Commit: f9c8767828aa44441681ea683f53cef8135050cd
      
https://github.com/qemu/qemu/commit/f9c8767828aa44441681ea683f53cef8135050cd
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui: fix VNC client throttling when audio capture is active

The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).

The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.

As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).

To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.

If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.

This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.

This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:

  commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
  Author: Daniel P. Berrange <address@hidden>
  Date:   Mon Oct 9 14:43:42 2017 +0100

    io: monitor encoutput buffer size from websocket GSource

This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit e2b72cb6e0443d90d7ab037858cb6834b6cca852)
Signed-off-by: Michael Roth <address@hidden>


  Commit: f9e53c77ea3bfe92ddc8c755935e7521dd3ed08e
      
https://github.com/qemu/qemu/commit/f9e53c77ea3bfe92ddc8c755935e7521dd3ed08e
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc-auth-sasl.c
    M ui/vnc-jobs.c
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui: fix VNC client throttling when forced update is requested

The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).

The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.

As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).

To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.

This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.

This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:

  commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493
  Author: Daniel P. Berrange <address@hidden>
  Date:   Mon Oct 9 14:43:42 2017 +0100

    io: monitor encoutput buffer size from websocket GSource

This new general memory usage flaw has been assigned CVE-2017-15124, and is
partially fixed by this patch.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit ada8d2e4369ea49677d8672ac81bce73eefd5b54)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0c85a40e710d4b71656b28f1f5e1ae5e3780d369
      
https://github.com/qemu/qemu/commit/0c85a40e710d4b71656b28f1f5e1ae5e3780d369
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c

  Log Message:
  -----------
  ui: place a hard cap on VNC server output buffer size

The previous patches fix problems with throttling of forced framebuffer updates
and audio data capture that would cause the QEMU output buffer size to grow
without bound. Those fixes are graceful in that once the client catches up with
reading data from the server, everything continues operating normally.

There is some data which the server sends to the client that is impractical to
throttle. Specifically there are various pseudo framebuffer update encodings to
inform the client of things like desktop resizes, pointer changes, audio
playback start/stop, LED state and so on. These generally only involve sending
a very small amount of data to the client, but a malicious guest might be able
to do things that trigger these changes at a very high rate. Throttling them is
not practical as missed or delayed events would cause broken behaviour for the
client.

This patch thus takes a more forceful approach of setting an absolute upper
bound on the amount of data we permit to be present in the output buffer at
any time. The previous patch set a threshold for throttling the output buffer
by allowing an amount of data equivalent to one complete framebuffer update and
one seconds worth of audio data. On top of this it allowed for one further
forced framebuffer update to be queued.

To be conservative, we thus take that throttling threshold and multiply it by
5 to form an absolute upper bound. If this bound is hit during vnc_write() we
forceably disconnect the client, refusing to queue further data. This limit is
high enough that it should never be hit unless a malicious client is trying to
exploit the sever, or the network is completely saturated preventing any sending
of data on the socket.

This completes the fix for CVE-2017-15124 started in the previous patches.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit f887cf165db20f405cb8805c716bd363aaadf815)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 172f4e5a31afd17d891ab4e19fc4aa7b7164d2c3
      
https://github.com/qemu/qemu/commit/172f4e5a31afd17d891ab4e19fc4aa7b7164d2c3
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/trace-events
    M ui/vnc.c

  Log Message:
  -----------
  ui: add trace events related to VNC client throttling

The VNC client throttling is quite subtle so will benefit from having trace
points available for live debugging.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 6aa22a29187e1908f5db738d27c64a9efc8d0bfa)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 9a26ca6b9422e4bb68baec8ad1cf4c3ce6d1db98
      
https://github.com/qemu/qemu/commit/9a26ca6b9422e4bb68baec8ad1cf4c3ce6d1db98
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc-auth-sasl.c
    M ui/vnc-auth-sasl.h
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui: mix misleading comments & return types of VNC I/O helper methods

While the QIOChannel APIs for reading/writing data return ssize_t, with negative
value indicating an error, the VNC code passes this return value through the
vnc_client_io_error() method. This detects the error condition, disconnects the
client and returns 0 to indicate error. Thus all the VNC helper methods should
return size_t (unsigned), and misleading comments which refer to the possibility
of negative return values need fixing.

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Darren Kenny <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 30b80fd5269257f55203b7072c505b4ebaab5115)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 64653b7fbe616b7159fd1e5be2f04f30e048dda4
      
https://github.com/qemu/qemu/commit/64653b7fbe616b7159fd1e5be2f04f30e048dda4
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui: avoid sign extension using client width/height

Pixman returns a signed int for the image width/height, but the VNC
protocol only permits a unsigned int16. Effective framebuffer size
is determined by the guest, limited by the video RAM size, so the
dimensions are unlikely to exceed the range of an unsigned int16,
but this is not currently validated.

With the current use of 'int' for client width/height, the calculation
of offsets in vnc_update_throttle_offset() suffers from integer size
promotion and sign extension, causing coverity warnings

*** CID 1385147:  Integer handling issues  (SIGN_EXTENSION)
/ui/vnc.c: 979 in vnc_update_throttle_offset()
973      * than that the client would already suffering awful audio
974      * glitches, so dropping samples is no worse really).
975      */
976     static void vnc_update_throttle_offset(VncState *vs)
977     {
978         size_t offset =
>>>     CID 1385147:  Integer handling issues  (SIGN_EXTENSION)
>>>     Suspicious implicit sign extension:
    "vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits,
    unsigned) is promoted in "vs->client_width * vs->client_height *
    vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then
    sign-extended to type "unsigned long" (64 bits, unsigned).  If
    "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel"
    is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
979             vs->client_width * vs->client_height * 
vs->client_pf.bytes_per_pixel;

Change client_width / client_height to be a size_t to avoid sign
extension and integer promotion. Then validate that dimensions are in
range wrt the RFB protocol u16 limits.

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 4c956bd81e2e16afd19d38d1fdeba6d9faa8a1ae)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 88ab85384da431950d319ab69438891c29e4a5dd
      
https://github.com/qemu/qemu/commit/88ab85384da431950d319ab69438891c29e4a5dd
  Author: Daniel P. Berrangé <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/vnc-auth-sasl.c

  Log Message:
  -----------
  ui: correctly advance output buffer when writing SASL data

In this previous commit:

  commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07
  Author: Daniel P. Berrange <address@hidden>
  Date:   Mon Dec 18 19:12:20 2017 +0000

    ui: track how much decoded data we consumed when doing SASL encoding

I attempted to fix a flaw with tracking how much data had actually been
processed when encoding with SASL. With that flaw, the VNC server could
mistakenly discard queued data that had not been sent.

The fix was not quite right though, because it merely decremented the
vs->output.offset value. This is effectively discarding data from the
end of the pending output buffer. We actually need to discard data from
the start of the pending output buffer. We also want to free memory that
is no longer required. The correct way to handle this is to use the
buffer_advance() helper method instead of directly manipulating the
offset value.

Reported-by: Laszlo Ersek <address@hidden>
Signed-off-by: Daniel P. Berrangé <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 627ebec208a8809818589e17f4fce55a59420ad2)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 30c3b4823c34a7410ec86c8e8b42db56b7b11117
      
https://github.com/qemu/qemu/commit/30c3b4823c34a7410ec86c8e8b42db56b7b11117
  Author: linzhecheng <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M ui/input.c

  Log Message:
  -----------
  input: fix memory leak

If kbd_queue is not empty and queue_count >= queue_limit,
we should free evt.

Change-Id: Ieeacf90d5e7e370a40452ec79031912d8b864d83
Signed-off-by: linzhecheng <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit fca4774a96843ba9d32a5d5d1c3826e1478facae)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 63112b16a6abd31d40df2b9a1dd713b42eb59c6b
      
https://github.com/qemu/qemu/commit/63112b16a6abd31d40df2b9a1dd713b42eb59c6b
  Author: linzhecheng <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M hw/display/vga.c

  Log Message:
  -----------
  vga: check the validation of memory addr when draw text

Start a vm with qemu-kvm -enable-kvm -vnc :66 -smp 1 -m 1024 -hda
redhat_5.11.qcow2  -device pcnet -vga cirrus,
then use VNC client to connect to VM, and excute the code below in guest
OS will lead to qemu crash:

int main()
 {
    iopl(3);
    srand(time(NULL));
    int a,b;
    while(1){
        a = rand()%0x100;
        b = 0x3c0 + (rand()%0x20);
  outb(a,b);
    }
    return 0;
}

The above code is writing the registers of VGA randomly.
We can write VGA CRT controller registers index 0x0C or 0x0D
(which is the start address register) to modify the
the display memory address of the upper left pixel
or character of the screen. The address may be out of the
range of vga ram. So we should check the validation of memory address
when reading or writing it to avoid segfault.

Signed-off-by: linzhecheng <address@hidden>
Message-id: address@hidden
Fixes: CVE-2018-5683
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 191f59dc17396bb5a8da50f8c59b6e0a430711a4)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 00e9fba2beb4a0366965ce4ec1068df68ce9f4c0
      
https://github.com/qemu/qemu/commit/00e9fba2beb4a0366965ce4ec1068df68ce9f4c0
  Author: Greg Kurz <address@hidden>
  Date:   2018-02-12 (Mon, 12 Feb 2018)

  Changed paths:
    M hw/ppc/spapr_hcall.c

  Log Message:
  -----------
  spapr: add missing break in h_get_cpu_characteristics()

Detected by Coverity (CID 1385702). This fixes the recently added hypercall
to let guests properly apply Spectre and Meltdown workarounds.

Fixes: c59704b25473 "target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS"
Reported-by: Paolo Bonzini <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit fa86f59234919b479b7e8da6b0dc2dad894a5eac)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7c1beb52ed86191d9e965444d934adaa2531710f
      
https://github.com/qemu/qemu/commit/7c1beb52ed86191d9e965444d934adaa2531710f
  Author: Michael Roth <address@hidden>
  Date:   2018-02-14 (Wed, 14 Feb 2018)

  Changed paths:
    M VERSION

  Log Message:
  -----------
  Update version for 2.11.1 release

Signed-off-by: Michael Roth <address@hidden>


Compare: https://github.com/qemu/qemu/compare/817a9fcba804^...7c1beb52ed86

reply via email to

[Prev in Thread] Current Thread [Next in Thread]