qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 62695f: hw/ppc: CAS reset on early device hot


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 62695f: hw/ppc: CAS reset on early device hotplug
Date: Mon, 18 Dec 2017 08:06:41 -0800

  Branch: refs/heads/stable-2.10
  Home:   https://github.com/qemu/qemu
  Commit: 62695f60c330d06457498dd5e88c02ef12ce623b
      
https://github.com/qemu/qemu/commit/62695f60c330d06457498dd5e88c02ef12ce623b
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-10-03 (Tue, 03 Oct 2017)

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

  Log Message:
  -----------
  hw/ppc: CAS reset on early device hotplug

This patch is a follow up on the discussions made in patch
"hw/ppc: disable hotplug before CAS is completed" that can be
found at [1].

At this moment, we do not support CPU/memory hotplug in early
boot stages, before CAS. When a hotplug occurs, the event is logged
in an internal RTAS event log queue and an IRQ pulse is fired. In
regular conditions, the guest handles the interrupt by executing
check_exception, fetching the generated hotplug event and enabling
the device for use.

In early boot, this IRQ isn't caught (SLOF does not handle hotplug
events), leaving the event in the rtas event log queue. If the guest
executes check_exception due to another hotplug event, the re-assertion
of the IRQ ends up de-queuing the first hotplug event as well. In short,
a device hotplugged before CAS is considered coldplugged by SLOF.
This leads to device misbehavior and, in some cases, guest kernel
Ooops when trying to unplug the device.

A proper fix would be to turn every device hotplugged before CAS
as a colplugged device. This is not trivial to do with the current
code base though - the FDT is written in the guest memory at
ppc_spapr_reset and can't be retrieved without adding extra state
(fdt_size for example) that will need to managed and migrated. Adding
the hotplugged DT in the middle of CAS negotiation via the updated DT
tree works with CPU devs, but panics the guest kernel at boot. Additional
analysis would be necessary for LMBs and PCI devices. There are
questions to be made in QEMU/SLOF/kernel level about how we can make
this change in a sustainable way.

With Linux guests, a fix would be the kernel executing check_exception
at boot time, de-queueing the events that happened in early boot and
processing them. However, even if/when the newer kernels start
fetching these events at boot time, we need to take care of older
kernels that won't be doing that.

This patch works around the situation by issuing a CAS reset if a hotplugged
device is detected during CAS:

- the DRC conditions that warrant a CAS reset is the same as those that
triggers a DRC migration - the DRC must have a device attached and
the DRC state is not equal to its ready_state. With that in mind, this
patch makes use of 'spapr_drc_needed' to determine if a CAS reset
is needed.

- In the middle of CAS negotiations, the function
'spapr_hotplugged_dev_before_cas' goes through all the DRCs to see
if there are any DRC that requires a reset, using spapr_drc_needed. If
that happens, returns '1' in 'spapr_h_cas_compose_response' which will set
spapr->cas_reboot to true, causing the machine to reboot.

No changes are made for coldplug devices.

[1] http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02855.html

Signed-off-by: Daniel Henrique Barboza <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 10f12e6450407b18b4d5a6b50d3852dcfd7fff75)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b23426608629b3ccd263291ffa095f1e8ceadb55
      
https://github.com/qemu/qemu/commit/b23426608629b3ccd263291ffa095f1e8ceadb55
  Author: Thomas Huth <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M hw/usb/bus.c

  Log Message:
  -----------
  hw/usb/bus: Remove bad object_unparent() from usb_try_create_simple()

Valgrind detects an invalid read operation when hot-plugging of an
USB device fails:

$ valgrind x86_64-softmmu/qemu-system-x86_64 -device usb-ehci -nographic -S
==30598== Memcheck, a memory error detector
==30598== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30598== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==30598== Command: x86_64-softmmu/qemu-system-x86_64 -device usb-ehci 
-nographic -S
==30598==
QEMU 2.10.50 monitor - type 'help' for more information
(qemu) device_add usb-tablet
(qemu) device_add usb-tablet
(qemu) device_add usb-tablet
(qemu) device_add usb-tablet
(qemu) device_add usb-tablet
(qemu) device_add usb-tablet
==30598== Invalid read of size 8
==30598==    at 0x60EF50: object_unparent (object.c:445)
==30598==    by 0x580F0D: usb_try_create_simple (bus.c:346)
==30598==    by 0x581BEB: usb_claim_port (bus.c:451)
==30598==    by 0x582310: usb_qdev_realize (bus.c:257)
==30598==    by 0x4CB399: device_set_realized (qdev.c:914)
==30598==    by 0x60E26D: property_set_bool (object.c:1886)
==30598==    by 0x61235E: object_property_set_qobject (qom-qobject.c:27)
==30598==    by 0x61000F: object_property_set_bool (object.c:1162)
==30598==    by 0x4567C3: qdev_device_add (qdev-monitor.c:630)
==30598==    by 0x456D52: qmp_device_add (qdev-monitor.c:807)
==30598==    by 0x470A99: hmp_device_add (hmp.c:1933)
==30598==    by 0x3679C3: handle_hmp_command (monitor.c:3123)

The object_unparent() here is not necessary anymore since commit
69382d8b3e8600b3 ("qdev: Fix object reference leak in case device.realize()
fails"), so let's remove it now.

Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit f3b2bea3c76ba9283b957f1373e7cebdbf863059)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 49958d37e7fcacb71512c781d21de2bb69e1c16b
      
https://github.com/qemu/qemu/commit/49958d37e7fcacb71512c781d21de2bb69e1c16b
  Author: Vladimir Sementsov-Ogievskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M block/mirror.c

  Log Message:
  -----------
  block/mirror: check backing in bdrv_mirror_top_flush

Backing may be zero after failed bdrv_append in mirror_start_job,
which leads to SIGSEGV.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit ce960aa9062a407d0ca15aee3dcd3bd84a4e24f9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 26914ce48d9a67d49b88c54c78cb5bee461b958b
      
https://github.com/qemu/qemu/commit/26914ce48d9a67d49b88c54c78cb5bee461b958b
  Author: Jim Somerville <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M hw/i386/kvm/clock.c

  Log Message:
  -----------
  kvmclock: use the updated system_timer_msr

Fixes e2b6c17 (kvmclock: update system_time_msr address forcibly)
which makes a call to get the latest value of the address
stored in system_timer_msr, but then uses the old address anyway.

Signed-off-by: Jim Somerville <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 346b1215b1e9f7cc6d8fe9fb6f3c2778b890afb6)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 4af42e3cf1c5cdd586667ab900420ff2590b3925
      
https://github.com/qemu/qemu/commit/4af42e3cf1c5cdd586667ab900420ff2590b3925
  Author: Eric Blake <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block: Perform copy-on-read in loop

Improve our braindead copy-on-read implementation.  Pre-patch,
we have multiple issues:
- we create a bounce buffer and perform a write for the entire
request, even if the active image already has 99% of the
clusters occupied, and really only needs to copy-on-read the
remaining 1% of the clusters
- our bounce buffer was as large as the read request, and can
needlessly exhaust our memory by using double the memory of
the request size (the original request plus our bounce buffer),
rather than a capped maximum overhead beyond the original
- if a driver has a max_transfer limit, we are bypassing the
normal code in bdrv_aligned_preadv() that fragments to that
limit, and instead attempt to read the entire buffer from the
driver in one go, which some drivers may assert on
- a client can request a large request of nearly 2G such that
rounding the request out to cluster boundaries results in a
byte count larger than 2G.  While this cannot exceed 32 bits,
it DOES have some follow-on problems:
-- the call to bdrv_driver_pread() can assert for exceeding
BDRV_REQUEST_MAX_BYTES, if the driver is old and lacks
.bdrv_co_preadv
-- if the buffer is all zeroes, the subsequent call to
bdrv_co_do_pwrite_zeroes is a no-op due to a negative size,
which means we did not actually copy on read

Fix all of these issues by breaking up the action into a loop,
where each iteration is capped to sane limits.  Also, querying
the allocation status allows us to optimize: when data is
already present in the active layer, we don't need to bounce.

Note that the code has a telling comment that copy-on-read
should probably be a filter driver rather than a bolt-on hack
in io.c; but that remains a task for another day.

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit cb2e28780c7080af489e72227683fe374f05022d)
 Conflicts:
        block/io.c
* remove context dep on d855ebcd3
Signed-off-by: Michael Roth <address@hidden>


  Commit: 6424975ce912061ac9e4a375237b0c89d83d93e3
      
https://github.com/qemu/qemu/commit/6424975ce912061ac9e4a375237b0c89d83d93e3
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  exec: Explicitly export target AS from address_space_translate_internal

This adds an AS** parameter to address_space_do_translate()
to make it easier for the next patch to share FlatViews.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit e76bb18f7e430e0c50fb38d051feacf268bd78f4)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 1b04a1580917d9e41fd37ca62cbff9b4bf061e96
      
https://github.com/qemu/qemu/commit/1b04a1580917d9e41fd37ca62cbff9b4bf061e96
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c
    M include/exec/memory-internal.h
    M include/exec/memory.h
    M memory.c

  Log Message:
  -----------
  memory: Open code FlatView rendering

We are going to share FlatView's between AddressSpace's and per-AS
memory listeners won't suit the purpose anymore so open code
the dispatch tree rendering.

Since there is a good chance that dispatch_listener was the only
listener, this avoids address_space_update_topology_pass() if there is
no registered listeners; this should improve starting time.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 9a62e24f45bc97f8eaf198caf58906b47c50a8d5)
Signed-off-by: Michael Roth <address@hidden>


  Commit: de7e6815b84c797cbda56dc96fcacaf5f37d3a20
      
https://github.com/qemu/qemu/commit/de7e6815b84c797cbda56dc96fcacaf5f37d3a20
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Move FlatView allocation to a helper

This moves a FlatView allocation and initialization to a helper.
While we are nere, replace g_new with g_new0 to not to bother if we add
new fields in the future.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cc94cd6d36602d976a5e7bc29134d1eaefb4102e)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 4d2f8abb22ace8e43f4d8ffc03431292210c9de6
      
https://github.com/qemu/qemu/commit/4d2f8abb22ace8e43f4d8ffc03431292210c9de6
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c
    M include/exec/memory-internal.h
    M include/exec/memory.h
    M memory.c

  Log Message:
  -----------
  memory: Move AddressSpaceDispatch from AddressSpace to FlatView

As we are going to share FlatView's between AddressSpace's,
and AddressSpaceDispatch is a structure to perform quick lookup
in FlatView, this moves ASD to FlatView.

After previosly open coded ASD rendering, we can also remove
as->next_dispatch as the new FlatView pointer is stored
on a stack and set to an AS atomically.

flatview_destroy() is executed under RCU instead of
address_space_dispatch_free() now.

This makes mem_begin/mem_commit to work with ASD and mem_add with FV
as later on mem_add will be taking FV as an argument anyway.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 66a6df1dc6d5b28cc3e65db0d71683fbdddc6b62)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d0136db81292ccac38a74b4ef2d3c3853b7c1355
      
https://github.com/qemu/qemu/commit/d0136db81292ccac38a74b4ef2d3c3853b7c1355
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  memory: Remove AddressSpace pointer from AddressSpaceDispatch

AS in ASD is only used to pass AS from mem_begin() to register_subpage()
to store it in MemoryRegionSection, we can do this directly now.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit c7752523787dc148f5ee976162e80ab594c386a1)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 3568e119400aeffa98e32187c40d2802b7d4f574
      
https://github.com/qemu/qemu/commit/3568e119400aeffa98e32187c40d2802b7d4f574
  Author: Paolo Bonzini <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M docs/devel/atomics.txt
    M include/qemu/atomic.h
    M memory.c

  Log Message:
  -----------
  memory: avoid "resurrection" of dead FlatViews

It's possible for address_space_get_flatview() as it currently stands
to cause a use-after-free for the returned FlatView, if the reference
count is incremented after the FlatView has been replaced by a writer:

   thread 1             thread 2             RCU thread
  -------------------------------------------------------------
   rcu_read_lock
   read as->current_map
                  set as->current_map
                  flatview_unref
                     '--> call_rcu
   flatview_ref
     [ref=1]
   rcu_read_unlock
                                       flatview_destroy
   <badness>

Since FlatViews are not updated very often, we can just detect the
situation using a new atomic op atomic_fetch_inc_nonzero, similar to
Linux's atomic_inc_not_zero, which performs the refcount increment only if
it hasn't already hit zero.  This is similar to Linux commit de09a9771a53
("CRED: Fix get_task_cred() and task_state() to not resurrect dead
credentials", 2010-07-29).

Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 447b0d0b9ee8a0ac216c3186e0f3c427a1001f0c)
 Conflicts:
        docs/devel/atomics.txt
* drop documentation ref to atomic_fetch_xor
* prereq for 166206845f
Signed-off-by: Michael Roth <address@hidden>


  Commit: f7774e329bb7c2a4ed9a0db3e74dddf19cbe873f
      
https://github.com/qemu/qemu/commit/f7774e329bb7c2a4ed9a0db3e74dddf19cbe873f
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c
    M hw/intc/openpic_kvm.c
    M include/exec/memory-internal.h
    M include/exec/memory.h
    M memory.c

  Log Message:
  -----------
  memory: Switch memory from using AddressSpace to FlatView

FlatView's will be shared between AddressSpace's and subpage_t
and MemoryRegionSection cannot store AS anymore, hence this change.

In particular, for:

 typedef struct subpage_t {
     MemoryRegion iomem;
-    AddressSpace *as;
+    FlatView *fv;
     hwaddr base;
     uint16_t sub_section[];
 } subpage_t;

  struct MemoryRegionSection {
     MemoryRegion *mr;
-    AddressSpace *address_space;
+    FlatView *fv;
     hwaddr offset_within_region;
     Int128 size;
     hwaddr offset_within_address_space;
     bool readonly;
 };

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 166206845f7fd75e720e6feea0bb01957c8da07f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: eff5ed4ae97a091e5ac3abc1f5e5d653359f1dd8
      
https://github.com/qemu/qemu/commit/eff5ed4ae97a091e5ac3abc1f5e5d653359f1dd8
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  memory: Cleanup after switching to FlatView

We store AddressSpaceDispatch* in FlatView anyway so there is no need
to carry it from mem_add() to register_subpage/register_multipage.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 9950322a593ff900a860fb52938159461798a831)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 08101db63bd8114d9f36ae03da6bbb226ac3ab0b
      
https://github.com/qemu/qemu/commit/08101db63bd8114d9f36ae03da6bbb226ac3ab0b
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c
    M include/exec/memory-internal.h
    M memory.c

  Log Message:
  -----------
  memory: Rename mem_begin/mem_commit/mem_add helpers

This renames some helpers to reflect better what they do.

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 8629d3fcb77e9775e44d9051bad0fb5187925eae)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 260d3646b0c7158ce5937fc6cd05a6c38ebec550
      
https://github.com/qemu/qemu/commit/260d3646b0c7158ce5937fc6cd05a6c38ebec550
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Store physical root MR in FlatView

Address spaces get to keep a root MR (alias or not) but FlatView stores
the actual MR as this is going to be used later on to decide whether to
share a particular FlatView or not.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 89c177bbdd6cf8e50b3fd4831697d50e195d6432)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c14ce078b267a905c8046dc17918f20b3eb4a41e
      
https://github.com/qemu/qemu/commit/c14ce078b267a905c8046dc17918f20b3eb4a41e
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Alloc dispatch tree where topology is generared

This is to make next patches simpler.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 9bf561e36cf8fed9565011a19ba9ea0100e1811e)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c943efe8b501313892a98ad823e128f97b6430eb
      
https://github.com/qemu/qemu/commit/c943efe8b501313892a98ad823e128f97b6430eb
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Move address_space_update_ioeventfds

So it is called (twice) from the same function. This is to make the next
patches a bit simpler.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 02218487649558ed66c3689d4cc55250a42601d8)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e8c7ea3e75b5bc13a643d0339869ed347c6f2ce5
      
https://github.com/qemu/qemu/commit/e8c7ea3e75b5bc13a643d0339869ed347c6f2ce5
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Share FlatView's and dispatch trees between address spaces

This allows sharing flat views between address spaces (AS) when
the same root memory region is used when creating a new address space.
This is done by walking through all ASes and caching one FlatView per
a physical root MR (i.e. not aliased).

This removes search for duplicates from address_space_init_shareable() as
FlatViews are shared elsewhere and keeping as::ref_count correct seems
an unnecessary and useless complication.

This should cause no change and memory use or boot time yet.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 967dc9b1194a9281124b2e1ce67b6c3359a2138f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 7dd7f7ef44af7159513e6cd3499a3ba8bd82af6f
      
https://github.com/qemu/qemu/commit/7dd7f7ef44af7159513e6cd3499a3ba8bd82af6f
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Do not allocate FlatView in address_space_init

This creates a new AS object without any FlatView as
memory_region_transaction_commit() may want to reuse the empty FV.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 67ace39b253ed5ae465275bc870f7e495547658b)
Signed-off-by: Michael Roth <address@hidden>


  Commit: a7bb94e7849bbabadbdde02ef27a38b3c1056f87
      
https://github.com/qemu/qemu/commit/a7bb94e7849bbabadbdde02ef27a38b3c1056f87
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M cpus.c
    M hw/arm/armv7m.c
    M include/exec/memory.h
    M include/hw/arm/armv7m.h
    M memory.c
    M target/arm/cpu.c
    M target/i386/cpu.c

  Log Message:
  -----------
  memory: Get rid of address_space_init_shareable

Since FlatViews are shared now and ASes not, this gets rid of
address_space_init_shareable().

This should cause no behavioural change.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit b516572f31c0ea0937cd9d11d9bd72dd83809886)
 Conflicts:
        target/arm/cpu.c
* drop context deps on 1d2091bc and 1e577cc7
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5b5e49ab5fa68958f120036baff5fb0104a30002
      
https://github.com/qemu/qemu/commit/5b5e49ab5fa68958f120036baff5fb0104a30002
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Create FlatView directly

This avoids usual memory_region_transaction_commit() which rebuilds
all FVs.

On POWER8 with 255 CPUs, 255 virtio-net, 40 PCI bridges guest this brings
down the boot time from 25s to 20s and reduces the amount of temporary FVs
allocated during machine constructon (~800000 -> ~640000) and amount of
temporary dispatch trees (~370000 -> ~300000), the total memory footprint
goes down (18G -> 17G).

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 202fc01b05572ecb258fdf4c5bd56cf6de8140c7)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5dbd1f7884bedb04c4229499444502dc98a42db2
      
https://github.com/qemu/qemu/commit/5dbd1f7884bedb04c4229499444502dc98a42db2
  Author: Paolo Bonzini <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M include/exec/memory.h
    M include/qemu/typedefs.h
    M memory.c
    M trace-events

  Log Message:
  -----------
  memory: trace FlatView creation and destruction

Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 02d9651d6a46479e9d70b72dca34e43605d06cda)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 639701e4f2f57cd54b657a8281dba72d067db8ee
      
https://github.com/qemu/qemu/commit/639701e4f2f57cd54b657a8281dba72d067db8ee
  Author: Paolo Bonzini <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: seek FlatView sharing candidates among children subregions

A container can be used instead of an alias to allow switching between
multiple subregions.  In this case we cannot directly share the
subregions (since they only belong to a single parent), but if the
subregions are aliases we can in turn walk those.

This is not enough to remove all source of quadratic FlatView creation,
but it enables sharing of the PCI bus master FlatViews (and their
AddressSpaceDispatch structures) across all PCI devices.  For 112
virtio-net-pci devices, boot time is reduced from 25 to 10 seconds and
memory consumption from 1.4 to 1 G.

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


  Commit: 496f97293e29361f48054f63adcbf1187c99fca2
      
https://github.com/qemu/qemu/commit/496f97293e29361f48054f63adcbf1187c99fca2
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: Share special empty FlatView

This shares an cached empty FlatView among address spaces. The empty
FV is used every time when a root MR renders into a FV without memory
sections which happens when MR or its children are not enabled or
zero-sized. The empty_view is not NULL to keep the rest of memory
API intact; it also has a dispatch tree for the same reason.

On POWER8 with 255 CPUs, 255 virtio-net, 40 PCI bridges guest this halves
the amount of FlatView's in use (557 -> 260) and dispatch tables
(~800000 -> ~370000).  In an unrelated experiment with 112 non-virtio
devices on x86 ("-M pc"), only 4 FlatViews are alive, and about ~2000
are created at startup.

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 092aa2fc65b7a35121616aad8f39d47b8f921618)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c9dbe3e0fcf704395e35b0ec1cb48041e8c2ea92
      
https://github.com/qemu/qemu/commit/c9dbe3e0fcf704395e35b0ec1cb48041e8c2ea92
  Author: Peter Xu <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  exec: add page_mask for flatview_do_translate

The function is originally used for flatview_space_translate() and what
we care about most is (xlat, plen) range. However for iotlb requests, we
don't really care about "plen", but the size of the page that "xlat" is
located on. While, plen cannot really contain this information.

A simple example to show why "plen" is not good for IOTLB translations:

E.g., for huge pages, it is possible that guest mapped 1G huge page on
device side that used this GPA range:

  0x100000000 - 0x13fffffff

Then let's say we want to translate one IOVA that finally mapped to GPA
0x13ffffe00 (which is located on this 1G huge page). Then here we'll
get:

  (xlat, plen) = (0x13fffe00, 0x200)

So the IOTLB would be only covering a very small range since from
"plen" (which is 0x200 bytes) we cannot tell the size of the page.

Actually we can really know that this is a huge page - we just throw the
information away in flatview_do_translate().

This patch introduced "page_mask" optional parameter to capture that
page mask info. Also, I made "plen" an optional parameter as well, with
some comments for the whole function.

No functional change yet.

Signed-off-by: Peter Xu <address@hidden>
Signed-off-by: Maxime Coquelin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit d5e5fafd11be4458443c43f19c1ebdd24d99a751)
Signed-off-by: Michael Roth <address@hidden>


  Commit: ae13e2cfa85858d58a4f1c158bb47a395d983c0c
      
https://github.com/qemu/qemu/commit/ae13e2cfa85858d58a4f1c158bb47a395d983c0c
  Author: Peter Xu <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M exec.c

  Log Message:
  -----------
  exec: simplify address_space_get_iotlb_entry

This patch let address_space_get_iotlb_entry() to use the newly
introduced page_mask parameter in flatview_do_translate(). Then we
will be sure the IOTLB can be aligned to page mask, also we should
nicely support huge pages now when introducing a764040.

Fixes: a764040 ("exec: abstract address_space_do_translate()")
Signed-off-by: Peter Xu <address@hidden>
Signed-off-by: Maxime Coquelin <address@hidden>
Acked-by: Michael S. Tsirkin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 076a93d7972c9c1e3839d2f65edc32568a2cce93)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d765c5e5779fe25f8dcb7f65c9a27a7b5a77941f
      
https://github.com/qemu/qemu/commit/d765c5e5779fe25f8dcb7f65c9a27a7b5a77941f
  Author: Maxime Coquelin <address@hidden>
  Date:   2017-12-04 (Mon, 04 Dec 2017)

  Changed paths:
    M memory.c

  Log Message:
  -----------
  memory: fix off-by-one error in memory_region_notify_one()

This patch fixes an off-by-one error that could lead to the
notifyee to receive notifications for ranges it is not
registered to.

The bug has been spotted by code review.

Fixes: bd2bfa4c52e5 ("memory: introduce memory_region_notify_one()")
Cc: address@hidden
Cc: Peter Xu <address@hidden>
Signed-off-by: Maxime Coquelin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit b021d1c04452276f4926eed2d104ccbd1037a6e1)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 64f62e4e901e268696234e13357d7b978ad29f1e
      
https://github.com/qemu/qemu/commit/64f62e4e901e268696234e13357d7b978ad29f1e
  Author: Michael Olbrich <address@hidden>
  Date:   2017-12-05 (Tue, 05 Dec 2017)

  Changed paths:
    M hw/sd/sd.c

  Log Message:
  -----------
  hw/sd: fix out-of-bounds check for multi block reads

The current code checks if the next block exceeds the size of the card.
This generates an error while reading the last block of the card.
Do the out-of-bounds check when starting to read a new block to fix this.

This issue became visible with increased error checking in Linux 4.13.

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


  Commit: a25aca75f83895fd16bef572bbf31e33620b600d
      
https://github.com/qemu/qemu/commit/a25aca75f83895fd16bef572bbf31e33620b600d
  Author: Max Reitz <address@hidden>
  Date:   2017-12-05 (Tue, 05 Dec 2017)

  Changed paths:
    M block/qcow2.c

  Log Message:
  -----------
  qcow2: Fix unaligned preallocated truncation

A qcow2 image file's length is not required to have a length that is a
multiple of the cluster size.  However, qcow2_refcount_area() expects an
aligned value for its @start_offset parameter, so we need to round
@old_file_size up to the next cluster boundary.

Reported-by: Ping Li <address@hidden>
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1414049
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit e400ad1e1f0127b4fdabcb1c8de1e99be91788df)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 39475b880538cbf4eeba0affd4e10486839be4b2
      
https://github.com/qemu/qemu/commit/39475b880538cbf4eeba0affd4e10486839be4b2
  Author: Max Reitz <address@hidden>
  Date:   2017-12-05 (Tue, 05 Dec 2017)

  Changed paths:
    M block/qcow2.c

  Log Message:
  -----------
  qcow2: Always execute preallocate() in a coroutine

Some qcow2 functions (at least perform_cow()) expect s->lock to be
taken.  Therefore, if we want to make use of them, we should execute
preallocate() (as "preallocate_co") in a coroutine so that we can use
the qemu_co_mutex_* functions.

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 572b07bea1d1a0f7726fd95c2613c76002a379bc)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5aa698ab5fa049df7ff137e8cc76e75fdfd59bfe
      
https://github.com/qemu/qemu/commit/5aa698ab5fa049df7ff137e8cc76e75fdfd59bfe
  Author: Max Reitz <address@hidden>
  Date:   2017-12-05 (Tue, 05 Dec 2017)

  Changed paths:
    M tests/qemu-iotests/125
    M tests/qemu-iotests/125.out

  Log Message:
  -----------
  iotests: Add cluster_size=64k to 125

Apparently it would be a good idea to test that, too.

Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 4c112a397c2f61038914fa315a7896ce6d645d18)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e31942b4865634e613b3b3d17af80b38e82d5fbe
      
https://github.com/qemu/qemu/commit/e31942b4865634e613b3b3d17af80b38e82d5fbe
  Author: Paolo Bonzini <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M target/nios2/translate.c

  Log Message:
  -----------
  nios2: define tcg_env

This should be done by all target and, since commit 53f6672bcf
("gen-icount: use tcg_ctx.tcg_env instead of cpu_env", 2017-06-30),
is causing the NIOS2 target to hang.

This is because the test for "should I exit to the main loop"
was being done with the correct offset to the icount decrementer,
but using TCG temporary 0 (the frame pointer) rather than the
env pointer.

Cc: address@hidden
Cc: Marek Vasut <address@hidden>
Reported-by: Thomas Huth <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 17bd9597be45b96ae00716b0ae01a4d11bbee1ab)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e0809fcc4b03b51435eabc8ad84ecd61acd83d31
      
https://github.com/qemu/qemu/commit/e0809fcc4b03b51435eabc8ad84ecd61acd83d31
  Author: Daniel P. Berrange <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M io/channel-websock.c

  Log Message:
  -----------
  io: monitor encoutput buffer size from websocket GSource

The websocket GSource is monitoring the size of the rawoutput
buffer to determine if the channel can accepts more writes.
The rawoutput buffer, however, is merely a temporary staging
buffer before data is copied into the encoutput buffer. Thus
its size will always be zero when the GSource runs.

This flaw causes the encoutput buffer to grow without bound
if the other end of the underlying data channel doesn't
read data being sent. This can be seen with VNC if a client
is on a slow WAN link and the guest OS is sending many screen
updates. A malicious VNC client can act like it is on a slow
link by playing a video in the guest and then reading data
very slowly, causing QEMU host memory to expand arbitrarily.

This issue is assigned CVE-2017-15268, publically reported in

  https://bugs.launchpad.net/qemu/+bug/1718964

(cherry picked from commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493)

Reviewed-by: Eric Blake <address@hidden>

[Dan: Added extra checks to deal with code refactored in master but
 not stable 2.10]

Signed-off-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Michael Roth <address@hidden>


  Commit: 3342fd02863fac6a05db7f956abfc43341b190ab
      
https://github.com/qemu/qemu/commit/3342fd02863fac6a05db7f956abfc43341b190ab
  Author: Greg Kurz <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M target/ppc/compat.c

  Log Message:
  -----------
  ppc: fix setting of compat mode

While trying to make KVM PR usable again, commit 5dfaa532ae introduced a
regression: the current compat_pvr value is passed to KVM instead of the
new one. This means that we always pass 0 instead of the max-cpu-compat
PVR during the initial machine reset. And at CAS time, we either pass
the PVR from the command line or even don't call kvmppc_set_compat() at
all, ie, the PCR will not be set as expected.

For example if we start a big endian fedora26 guest in power7 compat
mode on a POWER8 host, we get this in the guest:

$ cat /proc/cpuinfo
processor       : 0
cpu             : POWER7 (architected), altivec supported
clock           : 4024.000000MHz
revision        : 2.0 (pvr 004d 0200)

timebase        : 512000000
platform        : pSeries
model           : IBM pSeries (emulated by qemu)
machine         : CHRP IBM pSeries (emulated by qemu)
MMU             : Hash

but the guest can still execute POWER8 instructions, and the following
program succeeds:

int main()
{
  asm("vncipher 0,0,0"); // ISA 2.07 instruction
}

Let's pass the new compat_pvr to kvmppc_set_compat() and the program fails
with SIGILL as expected.

Reported-by: Nageswara R Sastry <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit e4f0c6bb1a9f72ad9e32c3171d36bae17ea1cd67)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b637b865ed54d15de620b25f23d937845ebf91e5
      
https://github.com/qemu/qemu/commit/b637b865ed54d15de620b25f23d937845ebf91e5
  Author: Peter Maydell <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M target/arm/translate.c

  Log Message:
  -----------
  translate.c: Fix usermode big-endian AArch32 LDREXD and STREXD

For AArch32 LDREXD and STREXD, architecturally the 32-bit word at the
lowest address is always Rt and the one at addr+4 is Rt2, even if the
CPU is big-endian. Our implementation does these with a single
64-bit store, so if we're big-endian then we need to put the two
32-bit halves together in the opposite order to little-endian,
so that they end up in the right places. We were trying to do
this with the gen_aa32_frob64() function, but that is not correct
for the usermode emulator, because there there is a distinction
between "load a 64 bit value" (which does a BE 64-bit access
and doesn't need swapping) and "load two 32 bit values as one
64 bit access" (where we still need to do the swapping, like
system mode BE32).

Fixes: https://bugs.launchpad.net/qemu/+bug/1725267
Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
(cherry picked from commit 3448d47b3172015006b79197eb5a69826c6a7b6d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 3a82a03a2e671ad23865fed273d5baf19790e037
      
https://github.com/qemu/qemu/commit/3a82a03a2e671ad23865fed273d5baf19790e037
  Author: Eric Auger <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/intc/arm_gicv3_its_kvm.c

  Log Message:
  -----------
  hw/intc/arm_gicv3_its: Don't abort on table save failure

The ITS is not fully properly reset at the moment. Caches are
not emptied.

After a reset, in case we attempt to save the state before
the bound devices have registered their MSIs and after the
1st level table has been allocated by the ITS driver
(device BASER is valid), the first level entries are still
invalid. If the device cache is not empty (devices registered
before the reset), vgic_its_save_device_tables fails with -EINVAL.
This causes a QEMU abort().

Cc: address@hidden
Signed-off-by: Eric Auger <address@hidden>
Reported-by: wanghaibin <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 8a7348b5d62d7ea16807e6bea54b448a0184bb0f)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 957bd48acfc350fd9b05669fb55cb61b004dd7bb
      
https://github.com/qemu/qemu/commit/957bd48acfc350fd9b05669fb55cb61b004dd7bb
  Author: Jens Freimann <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M net/socket.c

  Log Message:
  -----------
  net/socket: fix coverity issue

This fixes coverity issue CID1005339.

Make sure that saddr is not used uninitialized if the
mcast parameter is NULL.

Cc: address@hidden
Reported-by: Peter Maydell <address@hidden>
Signed-off-by: Jens Freimann <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit bb160b571fe469b03228d4502c75a18045978a74)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 69f562ad9efbe7db5f99c879e2ff96d4d8403e46
      
https://github.com/qemu/qemu/commit/69f562ad9efbe7db5f99c879e2ff96d4d8403e46
  Author: Jens Freimann <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M net/socket.c

  Log Message:
  -----------
  net: fix check for number of parameters to -netdev socket

Since commit 0f8c289ad "net: fix -netdev socket,fd= for UDP sockets"
we allow more than one parameter for -netdev socket. But now
we run into an assert when no parameter at all is specified

> qemu-system-x86_64 -netdev socket
socket.c:729: net_init_socket: Assertion `sock->has_udp' failed.

Fix this by reverting the change of the if condition done in 0f8c289ad.

Cc: Jason Wang <address@hidden>
Cc: address@hidden
Fixes: 0f8c289ad539feb5135c545bea947b310a893f4b
Reported-by: Mao Zhongyi <address@hidden>
Signed-off-by: Jens Freimann <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit ff86d5762552787f1fcb7da695ec4f8c1be754b4)
 Conflicts:
        net/socket.c
* drop context dep on 0522a959
Signed-off-by: Michael Roth <address@hidden>


  Commit: 56a10ff664cf1a9be5dc97695e1cb7f028d1ab38
      
https://github.com/qemu/qemu/commit/56a10ff664cf1a9be5dc97695e1cb7f028d1ab38
  Author: Eric Blake <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M nbd/client.c

  Log Message:
  -----------
  nbd/client: Use error_prepend() correctly

When using error prepend(), it is necessary to end with a space
in the format string; otherwise, messages come out incorrectly,
such as when connecting to a socket that hangs up immediately:

can't open device nbd://localhost:10809/: Failed to read dataUnexpected 
end-of-file before all bytes were read

Originally botched in commit e44ed99d, then several more instances
added in the meantime.

Pre-existing and not fixed here: we are inconsistent on capitalization;
some of our messages start with lower case, and others start with upper,
although the use of error_prepend() is much nicer to read when all
fragments consistently start with lower.

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
(cherry picked from commit cb6b1a3fc30c52ffd94ed0b69ca5991b19651724)
Signed-off-by: Michael Roth <address@hidden>


  Commit: d6c99e8ff5c7e46ced686c7773cd9c5faf3e844e
      
https://github.com/qemu/qemu/commit/d6c99e8ff5c7e46ced686c7773cd9c5faf3e844e
  Author: Max Reitz <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M util/stats64.c

  Log Message:
  -----------
  util/stats64: Fix min/max comparisons

stat64_min_slow() and stat64_max_slow() compare the wrong way.  This
makes iotest 136 fail with clang and -m32.

Signed-off-by: Max Reitz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 26a5db322be1e424a815d070ddd04442a5e5df50)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 059422ddbc9e3b7fbe54a6d87b9ac0b329bb16b9
      
https://github.com/qemu/qemu/commit/059422ddbc9e3b7fbe54a6d87b9ac0b329bb16b9
  Author: Maxime Coquelin <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h

  Log Message:
  -----------
  virtio: Add queue interface to restore avail index from vring used index

In case of backend crash, it is not possible to restore internal
avail index from the backend value as vhost_get_vring_base
callback fails.

This patch provides a new interface to restore internal avail index
from the vring used index, as done by some vhost-user backend on
reconnection.

Signed-off-by: Maxime Coquelin <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2d4ba6cc741df15df6fbb4feaa706a02e103083a)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0bc76c8d0899f1f3a2bc5092ae9de7a900213a3b
      
https://github.com/qemu/qemu/commit/0bc76c8d0899f1f3a2bc5092ae9de7a900213a3b
  Author: Maxime Coquelin <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: restore avail index from vring used index on disconnection

vhost_virtqueue_stop() gets avail index value from the backend,
except if the backend is not responding.

It happens when the backend crashes, and in this case, internal
state of the virtio queue is inconsistent, making packets
to corrupt the vring state.

With a Linux guest, it results in following error message on
backend reconnection:

[   22.444905] virtio_net virtio0: output.0:id 0 is not a head!
[   22.446746] net enp0s3: Unexpected TXQ (0) queue failure: -5
[   22.476360] net enp0s3: Unexpected TXQ (0) queue failure: -5

Fixes: 283e2c2adcb8 ("net: virtio-net discards TX data after link down")
Cc: address@hidden
Signed-off-by: Maxime Coquelin <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2ae39a113af311cb56a0c35b7f212dafcef15303)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 0a5a2b938ab29ad80de43ed3548d4374dc612658
      
https://github.com/qemu/qemu/commit/0a5a2b938ab29ad80de43ed3548d4374dc612658
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

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

  Log Message:
  -----------
  hw/ppc: clear pending_events on machine reset

The sPAPR machine isn't clearing up the pending events QTAILQ on
machine reboot. This allows for unprocessed hotplug/epow events
to persist in the queue after reset and, when reasserting the IRQs in
check_exception later on, these will be being processed by the OS.

This patch implements a new function called 'spapr_clear_pending_events'
that clears up the pending_events QTAILQ. This helper is then called
inside ppc_spapr_reset to clear up the events queue, preventing
old/deprecated events from persisting after a reset.

Signed-off-by: Daniel Henrique Barboza <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 56258174238eb25df629a53a96e1ac16a32dc7d4)
Signed-off-by: Michael Roth <address@hidden>


  Commit: a77c5873fe27c3ca4a4120cb9547b6a264c9b5da
      
https://github.com/qemu/qemu/commit/a77c5873fe27c3ca4a4120cb9547b6a264c9b5da
  Author: Greg Kurz <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

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

  Log Message:
  -----------
  spapr: reset DRCs after devices

A DRC with a pending unplug request releases its associated device at
machine reset time.

In the case of LMB, when all DRCs for a DIMM device have been reset,
the DIMM gets unplugged, causing guest memory to disappear. This may
be very confusing for anything still using this memory.

This is exactly what happens with vhost backends, and QEMU aborts
with:

qemu-system-ppc64: used ring relocated for ring 2
qemu-system-ppc64: qemu/hw/virtio/vhost.c:649: vhost_commit: Assertion
 `r >= 0' failed.

The issue is that each DRC registers a QEMU reset handler, and we
don't control the order in which these handlers are called (ie,
a LMB DRC will unplug a DIMM before the virtio device using the
memory on this DIMM could stop its vhost backend).

To avoid such situations, let's reset DRCs after all devices
have been reset.

Reported-by: Mallesh N. Koti <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Daniel Henrique Barboza <address@hidden>
Reviewed-by: Michael Roth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 82512483940c756e2db1bd67ea91b02bc29c5e01)
Signed-off-by: Michael Roth <address@hidden>


  Commit: e1a2a273278c5250ab08bf7d6553eda8991a5e35
      
https://github.com/qemu/qemu/commit/e1a2a273278c5250ab08bf7d6553eda8991a5e35
  Author: Michael Roth <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M scripts/make-release

  Log Message:
  -----------
  scripts/make-release: ship u-boot source as a tarball

The u-boot sources we ship currently cause problems with unpacking on
a case-insensitive filesystem due to path conflicts. This has been
fixed in upstream u-boot via commit 610eec7f, but since it is not
yet included in an official release we implement this approach as a
temporary workaround.

Once we move to a u-boot containing commit 610eec7f we should revert
this patch.

Cc: address@hidden
Cc: Alexander Graf <address@hidden>
Cc: Richard Henderson <address@hidden>
Cc: Thomas Huth <address@hidden>
Cc: Peter Maydell <address@hidden>
Suggested-by: Richard Henderson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit d0dead3b6df7f6cd970ed02e8369ab8730aac9d3)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 30e499bdc9ef2101e08d12ccbec5f8f692a8a70a
      
https://github.com/qemu/qemu/commit/30e499bdc9ef2101e08d12ccbec5f8f692a8a70a
  Author: Peter Lieven <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M block/nfs.c

  Log Message:
  -----------
  block/nfs: fix nfs_client_open for filesize greater than 1TB

DIV_ROUND_UP(st.st_size, BDRV_SECTOR_SIZE) was overflowing ret (int) if
st.st_size is greater than 1TB.

Cc: address@hidden
Signed-off-by: Peter Lieven <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit f1a7ff770f7d71ee7833ff019aac9d6cc3d13f71)
Signed-off-by: Michael Roth <address@hidden>


  Commit: c2269a0b54c44ae2807e493e80fb1bdc4c2b8701
      
https://github.com/qemu/qemu/commit/c2269a0b54c44ae2807e493e80fb1bdc4c2b8701
  Author: Jason Wang <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/net/virtio-net.c

  Log Message:
  -----------
  virtio-net: don't touch virtqueue if vm is stopped

Guest state should not be touched if VM is stopped, unfortunately we
didn't check running state and tried to drain tx queue unconditionally
in virtio_net_set_status(). A crash was then noticed as a migration
destination when user type quit after virtqueue state is loaded but
before region cache is initialized. In this case,
virtio_net_drop_tx_queue_data() tries to access the uninitialized
region cache.

Fix this by only dropping tx queue data when vm is running.

Fixes: 283e2c2adcb80 ("net: virtio-net discards TX data after link down")
Cc: Yuri Benditovich <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Cc: Michael S. Tsirkin <address@hidden>
Cc: address@hidden
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit 70e53e6e4da3db4b2c31981191753a7e974936d0)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 2ce8993512fb5e6ba4d4f62cecd159d3862a9a7e
      
https://github.com/qemu/qemu/commit/2ce8993512fb5e6ba4d4f62cecd159d3862a9a7e
  Author: Eric Blake <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M nbd/server.c

  Log Message:
  -----------
  nbd/server: CVE-2017-15119 Reject options larger than 32M

The NBD spec gives us permission to abruptly disconnect on clients
that send outrageously large option requests, rather than having
to spend the time reading to the end of the option.  No real
option request requires that much data anyways; and meanwhile, we
already have the practice of abruptly dropping the connection on
any client that sends NBD_CMD_WRITE with a payload larger than 32M.

For comparison, nbdkit drops the connection on any request with
more than 4096 bytes; however, that limit is probably too low
(as the NBD spec states an export name can theoretically be up
to 4096 bytes, which means a valid NBD_OPT_INFO could be even
longer) - even if qemu doesn't permit exports longer than 256
bytes.

It could be argued that a malicious client trying to get us to
read nearly 4G of data on a bad request is a form of denial of
service.  In particular, if the server requires TLS, but a client
that does not know the TLS credentials sends any option (other
than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated
payload of nearly 4G, then the server was keeping the connection
alive trying to read all the payload, tying up resources that it
would rather be spending on a client that can get past the TLS
handshake.  Hence, this warranted a CVE.

Present since at least 2.5 when handling known options, and made
worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE
to handle unknown options.

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
(cherry picked from commit fdad35ef6c5839d50dfc14073364ac893afebc30)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 227196c1e73a77769dcbc9c3563f4ede7b908ad7
      
https://github.com/qemu/qemu/commit/227196c1e73a77769dcbc9c3563f4ede7b908ad7
  Author: Eric Blake <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M nbd/server.c

  Log Message:
  -----------
  nbd/server: CVE-2017-15118 Stack smash on large export name

Introduced in commit f37708f6b8 (2.10).  The NBD spec says a client
can request export names up to 4096 bytes in length, even though
they should not expect success on names longer than 256.  However,
qemu hard-codes the limit of 256, and fails to filter out a client
that probes for a longer name; the result is a stack smash that can
potentially give an attacker arbitrary control over the qemu
process.

The smash can be easily demonstrated with this client:
$ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a)

If the qemu NBD server binary (whether the standalone qemu-nbd, or
the builtin server of QMP nbd-server-start) was compiled with
-fstack-protector-strong, the ability to exploit the stack smash
into arbitrary execution is a lot more difficult (but still
theoretically possible to a determined attacker, perhaps in
combination with other CVEs).  Still, crashing a running qemu (and
losing the VM) is bad enough, even if the attacker did not obtain
full execution control.

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
(cherry picked from commit 51ae4f8455c9e32c54770c4ebc25bf86a8128183)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 82ded5166b82c16978526fe748db771c19efb794
      
https://github.com/qemu/qemu/commit/82ded5166b82c16978526fe748db771c19efb794
  Author: Greg Kurz <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: fix error check in vhost_verify_ring_mappings()

Since commit f1f9e6c5 "vhost: adapt vhost_verify_ring_mappings() to
virtio 1 ring layout", we check the mapping of each part (descriptor
table, available ring and used ring) of each virtqueue separately.

The checking of a part is done by the vhost_verify_ring_part_mapping()
function: it returns either 0 on success or a negative errno if the
part cannot be mapped at the same place.

Unfortunately, the vhost_verify_ring_mappings() function checks its
return value the other way round. It means that we either:
- only verify the descriptor table of the first virtqueue, and if it
  is valid we ignore all the other mappings
- or ignore all broken mappings until we reach a valid one

ie, we only raise an error if all mappings are broken, and we consider
all mappings are valid otherwise (false success), which is obviously
wrong.

This patch ensures that vhost_verify_ring_mappings() only returns
success if ALL mappings are okay.

Reported-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2fe45ec3bffbd3a26f2ed39f60bab0ca5217d8f6)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b01b1609e659863e7cdabc9eaad1514b8393ca78
      
https://github.com/qemu/qemu/commit/b01b1609e659863e7cdabc9eaad1514b8393ca78
  Author: Vladimir Sementsov-Ogievskiy <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M nbd/server.c

  Log Message:
  -----------
  nbd/server: fix nbd_negotiate_handle_info

namelen should be here, length is unrelated, and always 0 at this
point.  Broken in introduction in commit f37708f6, but mostly
harmless (replying with '' as the name does not violate protocol,
and does not confuse qemu as the nbd client since our implementation
does not ask for the name; but might confuse some other client that
does ask for the name especially if the default export is different
than the export name being queried).

Adding an assert makes it obvious that we are not skipping any bytes
in the client's message, as well as making it obvious that we were
using the wrong variable.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
CC: address@hidden
Message-Id: <address@hidden>
[eblake: improve commit message, squash in assert addition]
Signed-off-by: Eric Blake <address@hidden>

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


  Commit: 0fd80ef569bf6b97a8dd1be4d0881065979fa418
      
https://github.com/qemu/qemu/commit/0fd80ef569bf6b97a8dd1be4d0881065979fa418
  Author: Eric Blake <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M block/nbd-client.c
    M tests/qemu-iotests/058
    M tests/qemu-iotests/140
    M tests/qemu-iotests/147

  Log Message:
  -----------
  nbd-client: Refuse read-only client with BDRV_O_RDWR

The NBD spec says that clients should not try to write/trim to
an export advertised as read-only by the server.  But we failed
to check that, and would allow the block layer to use NBD with
BDRV_O_RDWR even when the server is read-only, which meant we
were depending on the server sending a proper EPERM failure for
various commands, and also exposes a leaky abstraction: using
qemu-io in read-write mode would succeed on 'w -z 0 0' because
of local short-circuiting logic, but 'w 0 0' would send a
request over the wire (where it then depends on the server, and
fails at least for qemu-nbd but might pass for other NBD
implementations).

With this patch, a client MUST request read-only mode to access
a server that is doing a read-only export, or else it will get
a message like:

can't open device nbd://localhost:10809/foo: request for write access conflicts 
with read-only export

It is no longer possible to even attempt writes over the wire
(including the corner case of 0-length writes), because the block
layer enforces the explicit read-only request; this matches the
behavior of qcow2 when backed by a read-only POSIX file.

Fix several iotests to comply with the new behavior (since
qemu-nbd of an internal snapshot, as well as nbd-server-add over QMP,
default to a read-only export, we must tell blockdev-add/qemu-io to
set up a read-only client).

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
(cherry picked from commit 1104d83c726d2b20f9cec7b99ab3570a2fdbd46d)
Signed-off-by: Michael Roth <address@hidden>


  Commit: b81833fe7d0dd56bec6f4066adec5859af01fdd6
      
https://github.com/qemu/qemu/commit/b81833fe7d0dd56bec6f4066adec5859af01fdd6
  Author: Eric Blake <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M nbd/client.c

  Log Message:
  -----------
  nbd/client: Don't hard-disconnect on ESHUTDOWN from server

The NBD spec says that a server may fail any transmission request
with ESHUTDOWN when it is apparent that no further request from
the client can be successfully honored.  The client is supposed
to then initiate a soft shutdown (wait for all remaining in-flight
requests to be answered, then send NBD_CMD_DISC).  However, since
qemu's server never uses ESHUTDOWN errors, this code was mostly
untested since its introduction in commit b6f5d3b5.

More recently, I learned that nbdkit as the NBD server is able to
send ESHUTDOWN errors, so I finally tested this code, and noticed
that our client was special-casing ESHUTDOWN to cause a hard
shutdown (immediate disconnect, with no NBD_CMD_DISC), but only
if the server sends this error as a simple reply.  Further
investigation found that commit d2febedb introduced a regression
where structured replies behave differently than simple replies -
but that the structured reply behavior is more in line with the
spec (even if we still lack code in nbd-client.c to properly quit
sending further requests).  So this patch reverts the portion of
b6f5d3b5 that introduced an improper hard-disconnect special-case
at the lower level, and leaves the future enhancement of a nicer
soft-disconnect at the higher level for another day.

CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
(cherry picked from commit 01b05c66a3616d5a4adc39fc90962e9efaf791d1)
 Conflicts:
        nbd/client.c
*drop dep on d2febedb
Signed-off-by: Michael Roth <address@hidden>


  Commit: a0ad811956908b699e87d8b8304910ca5979179a
      
https://github.com/qemu/qemu/commit/a0ad811956908b699e87d8b8304910ca5979179a
  Author: Gerd Hoffmann <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/display/vga.c

  Log Message:
  -----------
  vga: drop line_offset variable

Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 362f811793ff6cb4d209ab61d76cc4f841bb5e46)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 9c7714afd7b574245c86c6bad40ecbcc2992aeec
      
https://github.com/qemu/qemu/commit/9c7714afd7b574245c86c6bad40ecbcc2992aeec
  Author: Gerd Hoffmann <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/display/vga.c

  Log Message:
  -----------
  vga: handle cirrus vbe mode wraparounds.

Commit "3d90c62548 vga: stop passing pointers to vga_draw_line*
functions" is incomplete.  It doesn't handle the case that the vga
rendering code tries to create a shared surface, i.e. a pixman image
backed by vga video memory.  That can not work in case the guest display
wraps from end of video memory to the start.  So force shadowing in that
case.  Also adjust the snapshot region calculation.

Can trigger with cirrus only, when programming vbe modes using the bochs
api (stdvga, also qxl and virtio-vga in vga compat mode) wrap arounds
can't happen.

Fixes: CVE-2017-13672
Fixes: 3d90c6254863693a6b13d918d2b8682e08bbc681
Cc: P J P <address@hidden>
Reported-by: David Buchanan <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>
Message-id: address@hidden
(cherry picked from commit 28f77de26a4f9995458ddeb9d34bb06c0193bdc9)
Signed-off-by: Michael Roth <address@hidden>


  Commit: 5f214279d456a52bf738887005af0e8d29c358b0
      
https://github.com/qemu/qemu/commit/5f214279d456a52bf738887005af0e8d29c358b0
  Author: David Gibson <address@hidden>
  Date:   2017-12-06 (Wed, 06 Dec 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr: Include "pre-plugged" DIMMS in ram size calculation at reset

At guest reset time, we allocate a hash page table (HPT) for the guest
based on the guest's RAM size.  If dynamic HPT resizing is not available we
use the maximum RAM size, if it is we use the current RAM size.

But the "current RAM size" calculation is incorrect - we just use the
"base" ram_size from the machine structure.  This doesn't include any
pluggable DIMMs that are already plugged at reset time.

This means that if you try to start a 'pseries' machine with a DIMM
specified on the command line that's much larger than the "base" RAM size,
then the guest will get a woefully inadequate HPT.  This can lead to a
guest freeze during boot as it runs out of HPT space during initial MMU
setup.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Tested-by: Greg Kurz <address@hidden>
(cherry picked from commit 768a20f3a491ed4afce73ebb65347d55251c0ebd)
*drop dep on 9aa3397f
Signed-off-by: Michael Roth <address@hidden>


  Commit: 26c1b49d56d53453b561863c61b1028d551c7f0f
      
https://github.com/qemu/qemu/commit/26c1b49d56d53453b561863c61b1028d551c7f0f
  Author: Alex Williamson <address@hidden>
  Date:   2017-12-14 (Thu, 14 Dec 2017)

  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: 2f3e3890c49bae320431a95a72f45041c79ccc70
      
https://github.com/qemu/qemu/commit/2f3e3890c49bae320431a95a72f45041c79ccc70
  Author: Suraj Jitindar Singh <address@hidden>
  Date:   2017-12-15 (Fri, 15 Dec 2017)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  target/ppc: Update setting of cpu features to account for compat modes

The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
are used to communicate features of the cpu to the guest operating
system. The properties of each of these are determined based on the
selected cpu model and the availability of hypervisor features.
Currently the compatibility mode of the cpu is not taken into account.

The ibm,arch-vec-5-platform-support node is used to communicate the
level of support for various ISAv3 processor features to the guest
before CAS to inform the guests' request. The available mmu mode should
only be hash unless the cpu is a POWER9 which is not in a prePOWER9
compat mode, in which case the available modes depend on the
accelerator and the hypervisor capabilities.

The ibm,pa-featues node is used to communicate the level of cpu support
for various features to the guest os. This should only contain features
relevant to the operating mode of the processor, that is the selected
cpu model taking into account any compat mode. This means that the
compat mode should be taken into account when choosing the properties of
ibm,pa-features and they should match the compat mode selected, or the
cpu model selected if no compat mode.

Update the setting of these cpu features in the device tree as described
above to properly take into account any compat mode. We use the
ppc_check_compat function which takes into account the current processor
model and the cpu compat mode.

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


  Commit: b7d059b91f78ac0cc4ccfbb951c70f0befc49374
      
https://github.com/qemu/qemu/commit/b7d059b91f78ac0cc4ccfbb951c70f0befc49374
  Author: Laurent Vivier <address@hidden>
  Date:   2017-12-15 (Fri, 15 Dec 2017)

  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>


Compare: https://github.com/qemu/qemu/compare/7851197b812b...b7d059b91f78

reply via email to

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