[Qemu-commits] [qemu/qemu] ec79c5: hw/display/sm501: Remove dead code for non-32-bit ...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: ec79c56300c15fb32ad22596eacbdea0d218d9f5
      
https://github.com/qemu/qemu/commit/ec79c56300c15fb32ad22596eacbdea0d218d9f5
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/display/sm501.c

  Log Message:
  -----------
  hw/display/sm501: Remove dead code for non-32-bit RGB surfaces

For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the sm501 display device which was handling the
possibility that the console surface was some other format.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210212180653.27588-2-peter.maydell@linaro.org>
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 36144df315ca614a40a45daded8bc5c691fcc3e7
      
https://github.com/qemu/qemu/commit/36144df315ca614a40a45daded8bc5c691fcc3e7
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/display/sm501_template.h

  Log Message:
  -----------
  hw/display/sm501: Expand out macros in template header

Now that we only include sm501_template.h for the DEPTH==32 case, we
can expand out the uses of the BPP, PIXEL_TYPE and PIXEL_NAME macros
in that header.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210212180653.27588-3-peter.maydell@linaro.org>
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: f7b5c16182fcb90bd312c81d0a5f63926c1dc367
      
https://github.com/qemu/qemu/commit/f7b5c16182fcb90bd312c81d0a5f63926c1dc367
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/display/sm501.c
    R hw/display/sm501_template.h

  Log Message:
  -----------
  hw/display/sm501: Inline template header into C file

We no longer need to include sm501_template.h multiple times, so
we can simply inline its contents into sm501.c.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210212180653.27588-4-peter.maydell@linaro.org>
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 382907b10077ed4cff48d9afe219a023887c0522
      
https://github.com/qemu/qemu/commit/382907b10077ed4cff48d9afe219a023887c0522
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical()

drc_isolate_logical() is used to move the DRC from the "Configured" to
the "Available" state, erroring out if the DRC is in the unexpected
"Unisolate" state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC
is already in "Available" or in "Unusable" state.

When moving from "Configured" to "Available", the DRC is moved to the
LOGICAL_AVAILABLE state, a drc->unplug_requested check is done and, if
true, spapr_drc_detach() is called.

What spapr_drc_detach() does then is:

- set drc->unplug_requested to true. In fact, this is the only place
where unplug_request is set to true;
- does nothing else if drc->state != drck->empty_state. If the DRC
state is equal to drck->empty_state, spapr_drc_release() is
called. For logical DRCs, drck->empty_state = LOGICAL_UNUSABLE.

In short, calling spapr_drc_detach() in drc_isolate_logical() does
nothing. It'll set unplug_request to true again ('again' since it was
already true - otherwise the function wouldn't be called), and will
return without calling spapr_drc_release() because the DRC is not in
LOGICAL_UNUSABLE, since drc_isolate_logical() just moved it to
LOGICAL_AVAILABLE. The only place where the logical DRC is released is
when called from drc_set_unusable(), when it is moved to the
"Unusable" state.  As it should, according to PAPR.

Even though calling spapr_drc_detach() in drc_isolate_logical() is
benign, removing it will avoid further thought about the matter. So
let's go ahead and do that.

As a note, this logic was introduced in commit bbf5c878ab76. Since
then, the DRC handling code was refactored and enhanced, and PAPR
itself went through some changes in the DRC area as well. It is
expected that some assumptions we had back then are now deprecated.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210211225246.17315-2-danielhb413@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: b88e0a57e6577f22620873d2363671b53faf77a5
      
https://github.com/qemu/qemu/commit/b88e0a57e6577f22620873d2363671b53faf77a5
  Author: Alexey Kardashevskiy <aik@ozlabs.ru>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF

  Log Message:
  -----------
  pseries: Update SLOF firmware image

This is mostly compiler warnings fixed but while doing this,
a bug in MIN() in tcgbios was found.

Alexey Kardashevskiy (14):
      helpers: Define MIN()
      libc: Compile with -Wextra
      elf: Compile with -Wextra
      usb: Compile with -Wextra
      veth: Compile with -Wextra
      virtio: Compile with -Wextra
      e1000: Compile with -Wextra
      libnet: Compile with -Wextra
      libhv: Compile with -Wextra
      libnvram: Compile with -Wextra
      libtpm: Compile with -Wextra
      slof/prim: Compile with -Wextra
      Makefile: Actually compile with -Wextra
      version: update to 20210217

Thomas Huth (1):
      virtio-serial: Remove superfluous serial-* words

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 66d10d32ace18da3eacf2d8ee72c6076e87f9e72
      
https://github.com/qemu/qemu/commit/66d10d32ace18da3eacf2d8ee72c6076e87f9e72
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr_drc.c: use spapr_drc_release() in isolate_physical/set_unusable

When moving a physical DRC to "Available", drc_isolate_physical() will
move the DRC state to STATE_PHYSICAL_POWERON and, if the DRC is marked
for unplug, call spapr_drc_detach(). For physical DRCs,
drck->empty_state is STATE_PHYSICAL_POWERON, meaning that we're sure
that spapr_drc_detach() will end up calling spapr_drc_release() in the
end.

Likewise, for logical DRCs, drc_set_unusable will move the DRC to
"Unusable" state, setting drc->state to STATE_LOGICAL_UNUSABLE, which is
the drck->empty_state for logical DRCs. spapr_drc_detach() will call
spapr_drc_release() in this case as well.

In both scenarios, spapr_drc_detach() is being used as a
spapr_drc_release(), wrapper, where we also set unplug_requested (which
is already true, otherwise spapr_drc_detach() wouldn't be called in the
first place) and check if drc->state == drck->empty_state, which we also
know it's guaranteed to be true because we just set it.

Just use spapr_drc_release() in these functions to be clear of our
intentions in both these functions.

Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: a03509cd2baf48b1e947d9eb203ccb95bd99e5fb
      
https://github.com/qemu/qemu/commit/a03509cd2baf48b1e947d9eb203ccb95bd99e5fb
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/trace-events
    M include/hw/ppc/spapr_drc.h

  Log Message:
  -----------
  spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()

spapr_drc_detach() is not the best name for what the function does. The
function does not detach the DRC, it makes an uncommited attempt to do
it.  It'll mark the DRC as pending unplug, via the 'unplug_request'
flag, and only if the DRC state is drck->empty_state it will detach the
DRC, via spapr_drc_release().

This is a contrast with its pair spapr_drc_attach(), where the function
is indeed creating the DRC QOM object. If you know what
spapr_drc_attach() does, you can be misled into thinking that
spapr_drc_detach() is removing the DRC from QEMU internal state, which
isn't true.

The current role of this function is better described as a request for
detach, since there's no guarantee that we're going to detach the DRC in
the end.  Rename the function to spapr_drc_unplug_request to reflect
what is is doing.

The initial idea was to change the name to spapr_drc_detach_request(),
and later on change the unplug_request flag to detach_request. However,
unplug_request is a migratable boolean for a long time now and renaming
it is not worth the trouble. spapr_drc_unplug_request() setting
drc->unplug_request is more natural than spapr_drc_detach_request
setting drc->unplug_request.

Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: a4ee352fe025bd1308eb77b11b3b60542af8a370
      
https://github.com/qemu/qemu/commit/a4ee352fe025bd1308eb77b11b3b60542af8a370
  Author: Cédric Le Goater <clg@kaod.org>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    A docs/system/ppc/embedded.rst
    A docs/system/ppc/powermac.rst
    A docs/system/ppc/powernv.rst
    A docs/system/ppc/prep.rst
    A docs/system/ppc/pseries.rst
    M docs/system/target-ppc.rst

  Log Message:
  -----------
  docs/system: Extend PPC section

This moves the current documentation in files specific to each
platform family. PowerNV machine is updated, the other machines need
to be done.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210222133956.156001-1-clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
[dwg: Trivial capitalization fix]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 936fda4d771fdc51d3640bdb0cc8ceec14165730
      
https://github.com/qemu/qemu/commit/936fda4d771fdc51d3640bdb0cc8ceec14165730
  Author: Fabiano Rosas <farosas@linux.ibm.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M target/ppc/int_helper.c
    M tests/tcg/configure.sh
    A tests/tcg/ppc64/Makefile.target
    A tests/tcg/ppc64le/Makefile.target
    A tests/tcg/ppc64le/bcdsub.c

  Log Message:
  -----------
  target/ppc: Fix bcdsub. emulation when result overflows

The commit d03b174a83 (target/ppc: simplify bcdadd/sub functions)
meant to simplify some of the code but it inadvertently altered the
way the CR6 field is set after the operation has overflowed.

The CR6 bits are set based on the *unbounded* result of the operation,
so we need to look at the result before returning from bcd_add_mag,
otherwise we will look at 0 when it overflows.

Consider the following subtraction:

v0 = 0x9999999999999999999999999999999c (maximum positive BCD value)
v1 = 0x0000000000000000000000000000001d (negative one BCD value)
bcdsub. v0,v0,v1,0

The Power ISA 2.07B says:
If the unbounded result is greater than zero, do the following.
  If PS=0, the sign code of the result is set to 0b1100.
  If PS=1, the sign code of the result is set to 0b1111.
  If the operation overflows, CR field 6 is set to 0b0101. Otherwise,
  CR field 6 is set to 0b0100.

POWER9 hardware:
vr0 = 0x0000000000000000000000000000000c (positive zero BCD value)
cr6 = 0b0101 (0x5) (positive, overflow)

QEMU:
vr0 = 0x0000000000000000000000000000000c (positive zero BCD value)
cr6 = 0b0011 (0x3) (zero, overflow) <--- wrong

This patch reverts the part of d03b174a83 that introduced the
problem and adds a test-case to avoid further regressions:

before:
$ make run-tcg-tests-ppc64le-linux-user
(...)
  TEST    bcdsub on ppc64le
bcdsub: qemu/tests/tcg/ppc64le/bcdsub.c:58: test_bcdsub_gt:
Assertion `(cr >> 4) == ((1 << 2) | (1 << 0))' failed.

Fixes: d03b174a83 (target/ppc: simplify bcdadd/sub functions)
Reported-by: Paul Clarke <pc@us.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Message-Id: <20210222194035.2723056-1-farosas@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 51254ffb320183a4636635840c23ee0e3a1efffa
      
https://github.com/qemu/qemu/commit/51254ffb320183a4636635840c23ee0e3a1efffa
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

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

  Log Message:
  -----------
  spapr_drc.c: introduce unplug_timeout_timer

The LoPAR spec provides no way for the guest kernel to report failure of
hotplug/hotunplug events. This wouldn't be bad if those operations were
granted to always succeed, but that's far for the reality.

What ends up happening is that, in the case of a failed hotunplug,
regardless of whether it was a QEMU error or a guest misbehavior, the
pSeries machine is retaining the unplug state of the device in the
running guest.  This state is cleanup in machine reset, where it is
assumed that this state represents a device that is pending unplug, and
the device is hotunpluged from the board. Until the reset occurs, any
hotunplug operation of the same device is forbid because there is a
pending unplug state.

This behavior has at least one undesirable side effect. A long standing
pending unplug state is, more often than not, the result of a hotunplug
error. The user had to dealt with it, since retrying to unplug the
device is noy allowed, and then in the machine reset we're removing the
device from the guest. This means that we're failing the user twice -
failed to hotunplug when asked, then hotunplugged without notice.

Solutions to this problem range between trying to predict when the
hotunplug will fail and forbid the operation from the QEMU layer, from
opening up the IRQ queue to allow for multiple hotunplug attempts, from
telling the users to 'reboot the machine if something goes wrong'. The
first solution is flawed because we can't fully predict guest behavior
from QEMU, the second solution is a trial and error remediation that
counts on a hope that the unplug will eventually succeed, and the third
is ... well.

This patch introduces a crude, but effective solution to hotunplug
errors in the pSeries machine. For each unplug done, we'll timeout after
some time. If a certain amount of time passes, we'll cleanup the
hotunplug state from the machine.  During the timeout period, any unplug
operations in the same device will still be blocked. After that, we'll
assume that the guest failed the operation, and allow the user to try
again. If the timeout is too short we'll prevent legitimate hotunplug
situations to occur, so we'll need to overestimate the regular time an
unplug operation takes to succeed to account that.

The true solution for the hotunplug errors in the pSeries machines is a
PAPR change to allow for the guest to warn the platform about it. For
now, the work done in this timeout design can be used for the new PAPR
'abort hcall' in the future, given that for both cases we'll need code
to cleanup the existing unplug states of the DRCs.

At this moment we're adding the basic wiring of the timer into the DRC.
Next patch will use the timer to timeout failed CPU hotunplugs.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-4-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: d1c2e3ce3d5a5424651967bce1cf1f4caa0c6d91
      
https://github.com/qemu/qemu/commit/d1c2e3ce3d5a5424651967bce1cf1f4caa0c6d91
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

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

  Log Message:
  -----------
  spapr_drc.c: add hotunplug timeout for CPUs

There is a reliable way to make a CPU hotunplug fail in the pseries
machine. Hotplug a CPU A, then offline all other CPUs inside the guest
but A. When trying to hotunplug A the guest kernel will refuse to do it,
because A is now the last online CPU of the guest. PAPR has no 'error
callback' in this situation to report back to the platform, so the guest
kernel will deny the unplug in silent and QEMU will never know what
happened. The unplug pending state of A will remain until the guest is
shutdown or rebooted.

Previous attempts of fixing it (see [1] and [2]) were aimed at trying to
mitigate the effects of the problem. In [1] we were trying to guess
which guest CPUs were online to forbid hotunplug of the last online CPU
in the QEMU layer, avoiding the scenario described above because QEMU is
now failing in behalf of the guest. This is not robust because the last
online CPU of the guest can change while we're in the middle of the
unplug process, and our initial assumptions are now invalid. In [2] we
were accepting that our unplug process is uncertain and the user should
be allowed to spam the IRQ hotunplug queue of the guest in case the CPU
hotunplug fails.

This patch presents another alternative, using the timeout
infrastructure introduced in the previous patch. CPU hotunplugs in the
pSeries machine will now timeout after 15 seconds. This is a long time
for a single CPU unplug to occur, regardless of guest load - although
the user is *strongly* encouraged to *not* hotunplug devices from a
guest under high load - and we can be sure that something went wrong if
it takes longer than that for the guest to release the CPU (the same
can't be said about memory hotunplug - more on that in the next patch).

Timing out the unplug operation will reset the unplug state of the CPU
and allow the user to try it again, regardless of the error situation
that prevented the hotunplug to occur. Of all the not so pretty
fixes/mitigations for CPU hotunplug errors in pSeries, timing out the
operation is an admission that we have no control in the process, and
must assume the worst case if the operation doesn't succeed in a
sensible time frame.

[1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg03353.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04400.html

Reported-by: Xujun Ma <xuma@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1911414
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-5-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: fe1831eff8a41e96044fe98a6b0e232daa22ef83
      
https://github.com/qemu/qemu/commit/fe1831eff8a41e96044fe98a6b0e232daa22ef83
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

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

  Log Message:
  -----------
  spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state

Handling errors in memory hotunplug in the pSeries machine is more
complex than any other device type, because there are all the
complications that other devices has, and more.

For instance, determining a timeout for a DIMM hotunplug must consider
if it's a Hash-MMU or a Radix-MMU guest, because Hash guests takes
longer to hotunplug DIMMs. The size of the DIMM is also a factor, given
that longer DIMMs naturally takes longer to be hotunplugged from the
kernel. And there's also the guest memory usage to be considered: if
there's a process that is consuming memory that would be lost by the
DIMM unplug, the kernel will postpone the unplug process until the
process finishes, and then initiate the regular hotunplug process. The
first two considerations are manageable, but the last one is a deal
breaker.

There is no sane way for the pSeries machine to determine the memory
load in the guest when attempting a DIMM hotunplug - and even if there
was a way, the guest can start using all the RAM in the middle of the
unplug process and invalidate our previous assumptions - and in result
we can't even begin to calculate a timeout for the operation. This means
that we can't implement a viable timeout mechanism for memory unplug in
pSeries.

Going back to why we would consider an unplug timeout, the reason is
that we can't know if the kernel is giving up the unplug. Turns out
that, sometimes, we can. Consider a failed memory hotunplug attempt
where the kernel will error out with the following message:

'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any
removed LMBs'

This happens when there is a LMB that the kernel gave up in removing,
and the LMBs previously marked for removal are now being added back.
This happens in the pseries kernel in [1], dlpar_memory_remove_by_ic()
into dlpar_add_lmb(), and after that update_lmb_associativity_index().
In this function, the kernel is configuring the LMB DRC connector again.
Note that this is a valid usage in LOPAR, as stated in section
"ibm,configure-connector RTAS Call":

'A subsequent sequence of calls to ibm,configure-connector with the same
entry from the “ibm,drc-indexes” or “ibm,drc-info” property will restart
the configuration of devices which were not completely configured.'

We can use this kernel behavior in our favor. If a DRC connector
reconfiguration for a LMB that we marked as unplug pending happens, this
indicates that the kernel changed its mind about the unplug and is
reasserting that it will keep using all the LMBs of the DIMM. In this
case, it's safe to assume that the whole DIMM device unplug was
cancelled.

This patch hops into rtas_ibm_configure_connector() and, in the scenario
described above, clear the unplug state for the DIMM device. This will
not solve all the problems we still have with memory unplug, but it will
cover this case where the kernel reconfigures LMBs after a failed
unplug. We are a bit more resilient, without using an unreliable
timeout, and we didn't make the remaining error cases any worse.

[1] arch/powerpc/platforms/pseries/hotplug-memory.c

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: f149c9b7f942c56f30e66be034f669b95255474e
      
https://github.com/qemu/qemu/commit/f149c9b7f942c56f30e66be034f669b95255474e
  Author: Bin Meng <bin.meng@windriver.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/net/fsl_etsec/etsec.c
    M hw/net/fsl_etsec/rings.c

  Log Message:
  -----------
  hw/net: fsl_etsec: Fix build error when HEX_DUMP is on

"qemu-common.h" should be included to provide the forward declaration
of qemu_hexdump() when HEX_DUMP is on.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Message-Id: <20210228050431.24647-1-bmeng.cn@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: e5943b00d35efc68ca72ed304cfca98a9f3a647c
      
https://github.com/qemu/qemu/commit/e5943b00d35efc68ca72ed304cfca98a9f3a647c
  Author: Bin Meng <bin.meng@windriver.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/e500.c

  Log Message:
  -----------
  hw/ppc: e500: Add missing <ranges> in the eTSEC node

The eTSEC node should provide an empty <ranges> property in the
eTSEC node, otherwise of_translate_address() in the Linux kernel
fails to get the eTSEC register base, reporting:

  OF: ** translation for device /platform@f00000000/ethernet@0/queue-group **
  OF: bus is default (na=1, ns=1) on /platform@f00000000/ethernet@0
  OF: translating address: 00000000
  OF: parent bus is default (na=1, ns=1) on /platform@f00000000
  OF: no ranges; cannot translate

Per devicetree spec v0.3 [1] chapter 2.3.8:

  If the property is not present in a bus node, it is assumed that
  no mapping exists between children of the node and the parent
  address space.

This is why of_translate_address() aborts the address translation.
Apparently U-Boot devicetree parser seems to be tolerant with
missing <ranges> as this was not noticed when testing with U-Boot.
The empty <ranges> property is present in all kernel shipped dtsi
files for eTSEC, Let's add it to conform with the spec.

[1] 
https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

Fixes: fdfb7f2cdb2d ("e500: Add support for eTSEC in device tree")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Message-Id: <1614158919-9473-1-git-send-email-bmeng.cn@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 7420033ec460e7b9906bf05fbe1a0d3830536657
      
https://github.com/qemu/qemu/commit/7420033ec460e7b9906bf05fbe1a0d3830536657
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr.c: add 'unplug already in progress' message for PHB unplug

Both CPU hotunplug and PC_DIMM unplug reports an user warning,
mentioning that the hotunplug is in progress, if consecutive
'device_del' are issued in quick succession.

Do the same for PHBs in spapr_phb_unplug_request().

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210226163301.419727-4-danielhb413@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: e35dfbd22780aafbcd4b6da5130a00fc085fd5de
      
https://github.com/qemu/qemu/commit/e35dfbd22780aafbcd4b6da5130a00fc085fd5de
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr_pci.c

  Log Message:
  -----------
  spapr_pci.c: add 'unplug already in progress' message for PCI unplug

Hotunplug for all other devices are warning the user when the hotunplug
is already in progress. Do the same for PCI devices in
spapr_pci_unplug_request().

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210226163301.419727-5-danielhb413@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 4515a5f786024fabf0bef4cf3d28adf5647e6e82
      
https://github.com/qemu/qemu/commit/4515a5f786024fabf0bef4cf3d28adf5647e6e82
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr_drc.c
    M include/qemu/timer.h
    M util/qemu-timer.c

  Log Message:
  -----------
  qemu_timer.c: add timer_deadline_ms() helper

The pSeries machine is using QEMUTimer internals to return the timeout
in seconds for a timer object, in hw/ppc/spapr.c, function
spapr_drc_unplug_timeout_remaining_sec().

Create a helper in qemu-timer.c to retrieve the deadline for a QEMUTimer
object, in ms, to avoid exposing timer internals to the PPC code.

CC: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210301124133.23800-2-danielhb413@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 09db2216aa06be8bacd0101723d9c257f75c803f
      
https://github.com/qemu/qemu/commit/09db2216aa06be8bacd0101723d9c257f75c803f
  Author: Vitaly Cheptsov <cheptsov@ispras.ru>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M target/ppc/translate_init.c.inc

  Log Message:
  -----------
  target/ppc: fix icount support on Book-e vms accessing SPRs

Failing to guard SPR access with gen_io_start/gen_stop_exception
causes "Bad icount read" exceptions when running VMs with
e500mc and e500v2 CPUs with an icount parameter.

Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Greg Kurz <groug@kaod.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Vitaly Cheptsov <cheptsov@ispras.ru>
Message-Id: <20210303140851.78383-1-cheptsov@ispras.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 41c8ad3d920d6f1741b34bfdfaa72b43b45209b5
      
https://github.com/qemu/qemu/commit/41c8ad3d920d6f1741b34bfdfaa72b43b45209b5
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  spapr.c: remove duplicated assert in spapr_memory_unplug_request()

We are asserting the existence of the first DRC LMB after sending unplug
requests to all LMBs of the DIMM, where every DRC is being asserted
inside the loop. This means that the first DRC is being asserted twice.

Remove the duplicated assert.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210302141019.153729-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: eb7f80fd26d73e7e1af105431da58971b1dba517
      
https://github.com/qemu/qemu/commit/eb7f80fd26d73e7e1af105431da58971b1dba517
  Author: Daniel Henrique Barboza <danielhb413@gmail.com>
  Date:   2021-03-10 (Wed, 10 Mar 2021)

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

  Log Message:
  -----------
  spapr.c: send QAPI event when memory hotunplug fails

Recent changes allowed the pSeries machine to rollback the hotunplug
process for the DIMM when the guest kernel signals, via a
reconfiguration of the DR connector, that it's not going to release the
LMBs.

Let's also warn QAPI listerners about it. One place to do it would be
right after the unplug state is cleaned up,
spapr_clear_pending_dimm_unplug_state(). This would mean that the
function is now doing more than cleaning up the pending dimm state
though.

This patch does the following changes in spapr.c:

- send a QAPI event to inform that we experienced a failure in the
  hotunplug of the DIMM;

- rename spapr_clear_pending_dimm_unplug_state() to
  spapr_memory_unplug_rollback(). This is a better fit for what the
  function is now doing, and it makes callers care more about what the
  function goal is and less about spapr.c internals such as clearing
  the pending dimm unplug state.

Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210302141019.153729-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>


  Commit: 1941858448e76f83eb00614c4f34ac29e9a8e792
      
https://github.com/qemu/qemu/commit/1941858448e76f83eb00614c4f34ac29e9a8e792
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2021-03-12 (Fri, 12 Mar 2021)

  Changed paths:
    A docs/system/ppc/embedded.rst
    A docs/system/ppc/powermac.rst
    A docs/system/ppc/powernv.rst
    A docs/system/ppc/prep.rst
    A docs/system/ppc/pseries.rst
    M docs/system/target-ppc.rst
    M hw/display/sm501.c
    R hw/display/sm501_template.h
    M hw/net/fsl_etsec/etsec.c
    M hw/net/fsl_etsec/rings.c
    M hw/ppc/e500.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_pci.c
    M hw/ppc/trace-events
    M include/hw/ppc/spapr.h
    M include/hw/ppc/spapr_drc.h
    M include/qemu/timer.h
    M pc-bios/README
    M pc-bios/slof.bin
    M roms/SLOF
    M target/ppc/int_helper.c
    M target/ppc/translate_init.c.inc
    M tests/tcg/configure.sh
    A tests/tcg/ppc64/Makefile.target
    A tests/tcg/ppc64le/Makefile.target
    A tests/tcg/ppc64le/bcdsub.c
    M util/qemu-timer.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210310' 
into staging

ppc patch queue for 2021-03-10

Next batch of patches for the ppc target and machine types.  Includes:
 * Several cleanups for sm501 from Peter Maydell
 * An update to the SLOF guest firmware
 * Improved handling of hotplug failures in spapr, associated cleanups
   to the hotplug handling code
 * Several etsec fixes and cleanups from Bin Meng
 * Assorted other fixes and cleanups

# gpg: Signature made Wed 10 Mar 2021 04:08:53 GMT
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" 
[full]
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>" 
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dg-gitlab/tags/ppc-for-6.0-20210310:
  spapr.c: send QAPI event when memory hotunplug fails
  spapr.c: remove duplicated assert in spapr_memory_unplug_request()
  target/ppc: fix icount support on Book-e vms accessing SPRs
  qemu_timer.c: add timer_deadline_ms() helper
  spapr_pci.c: add 'unplug already in progress' message for PCI unplug
  spapr.c: add 'unplug already in progress' message for PHB unplug
  hw/ppc: e500: Add missing <ranges> in the eTSEC node
  hw/net: fsl_etsec: Fix build error when HEX_DUMP is on
  spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state
  spapr_drc.c: add hotunplug timeout for CPUs
  spapr_drc.c: introduce unplug_timeout_timer
  target/ppc: Fix bcdsub. emulation when result overflows
  docs/system: Extend PPC section
  spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()
  spapr_drc.c: use spapr_drc_release() in isolate_physical/set_unusable
  pseries: Update SLOF firmware image
  spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical()
  hw/display/sm501: Inline template header into C file
  hw/display/sm501: Expand out macros in template header
  hw/display/sm501: Remove dead code for non-32-bit RGB surfaces

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/6f34661b6c97...1941858448e7