[Qemu-commits] [qemu/qemu] 94b502: s390x/s390-virtio: get rid of DPRINTF

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 94b5024b1f466b4b8f03e7b2219f77e9a3a24d51
      
https://github.com/qemu/qemu/commit/94b5024b1f466b4b8f03e7b2219f77e9a3a24d51
  Author: Cornelia Huck <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/s390-virtio.c

  Log Message:
  -----------
  s390x/s390-virtio: get rid of DPRINTF

The DPRINTF approach is likely to introduce bitrot, and the preferred
way for debugging is tracing anyway. Fortunately, there are no users
(left), so nuke it.

Signed-off-by: Cornelia Huck <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>


  Commit: 409422cd83f36450a3c0bdd49163786cbff3a7ea
      
https://github.com/qemu/qemu/commit/409422cd83f36450a3c0bdd49163786cbff3a7ea
  Author: Christian Borntraeger <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M target/s390x/kvm.c

  Log Message:
  -----------
  s390x/kvm: detect some program check loops

Sometimes (e.g. early boot) a guest is broken in such ways that it loops
100% delivering operation exceptions (illegal operation) but the pgm new
PSW is not set properly. This will result in code being read from
address zero, which usually contains another illegal op. Let's detect
this case and put the guest in crashed state. Instead of only detecting
this for address zero apply a heuristic that will work for any program
check new psw so that it will also reach the crashed state if you
provide some random elf file to the -kernel option.
We do not want guest problem state to be able to trigger a guest panic,
e.g. by faulting on an address that is the same as the program check
new PSW, so we check for the problem state bit being off.

With this we
a: get rid of CPU consumption of such broken guests
b: keep the program old PSW. This allows to find out the original illegal
   operation - making debugging such early boot issues much easier than
   with single stepping

This relies on the kernel using a similar heuristic and passing such
operation exceptions to user space.

Signed-off-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: ba690c7171cb863643c21ab9f7e7116ad5df1c63
      
https://github.com/qemu/qemu/commit/ba690c7171cb863643c21ab9f7e7116ad5df1c63
  Author: Cornelia Huck <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/intc/s390_flic_kvm.c

  Log Message:
  -----------
  s390x/flic: fail migration on source already

Current code puts a 'FLIC_FAILED' marker into the migration stream
to indicate something went wrong while saving flic state and fails
load if it encounters that marker. VMState's put routine recently
gained the ability to return error codes (but did not wire it up
yet).

In order to be able to reap the benefits of returning an error and
failing migration on the source already once this gets wired up
in core, return an error in addition to storing 'FLIC_FAILED'.

Suggested-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
Reviewed-by: Jens Freimann <address@hidden>
Reviewed-by: Christian Borntraeger <address@hidden>


  Commit: 47e13dfd86e33397d55bc3c3d08ac0ec3088b138
      
https://github.com/qemu/qemu/commit/47e13dfd86e33397d55bc3c3d08ac0ec3088b138
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/virtio-ccw.c
    M hw/s390x/virtio-ccw.h

  Log Message:
  -----------
  virtio-ccw: handle virtio 1 only devices

As a preparation for wiring-up virtio-crypto, the first non-transitional
virtio device on the ccw transport, let us introduce a mechanism for
disabling revision 0.  This is more or less equivalent with disabling
legacy as revision 0 is legacy only, and legacy drivers use the revision
0 exclusively.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: d2256070d207ec49a42bed6a99c2cf55a720fb43
      
https://github.com/qemu/qemu/commit/d2256070d207ec49a42bed6a99c2cf55a720fb43
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/virtio-ccw.c
    M hw/s390x/virtio-ccw.h

  Log Message:
  -----------
  virtio-ccw: add virtio-crypto-ccw device

Wire up virtio-crypto for the CCW based VIRTIO.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 797b608638c5ac7492e789563bcbed9feff0423d
      
https://github.com/qemu/qemu/commit/797b608638c5ac7492e789563bcbed9feff0423d
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/virtio-ccw.c

  Log Message:
  -----------
  virtio-ccw: Check the number of vqs in CCW_CMD_SET_IND

We cannot support more than 64 virtqueues with the 64 bits provided by
classic indicators. If a driver tries to setup classic indicators
(which it is free to do even for virtio-1 devices) for a device with
more than 64 virtqueues, we should reject the attempt so that the
driver does not end up with an unusable device.

This is in preparation for bumping the number of supported virtqueues
on the ccw transport.

Signed-off-by: Halil Pasic <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: e61cc6b5c6909fa69059036bb910ef1725dc7f90
      
https://github.com/qemu/qemu/commit/e61cc6b5c6909fa69059036bb910ef1725dc7f90
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/intc/s390_flic.c
    M include/hw/s390x/s390_flic.h

  Log Message:
  -----------
  s390x: add property adapter_routes_max_batch

To make virtio-ccw supports more that  64 virtqueues we will have to
increase ADAPTER_ROUTES_MAX_GSI which is currently limiting the number if
possible adapter routes. Of course increasing the number of supported
routes can break backwards migration.

Let us introduce a compatibility property adapter_routes_max_batch so
client code can use the some old limit if in compatibility mode and
retain the migration compatibility.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 0708afa704f4f06d823af5757b1a331cc5fce438
      
https://github.com/qemu/qemu/commit/0708afa704f4f06d823af5757b1a331cc5fce438
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/virtio-ccw.c

  Log Message:
  -----------
  virtio-ccw: check flic->adapter_routes_max_batch

Currently VIRTIO_CCW_QUEUE_MAX is defined as ADAPTER_ROUTES_MAX_GSI.
That is when checking queue max we implicitly check the constraint
concerning the number of adapter routes. This won't be satisfactory any
more (due to backward migration considerations) if ADAPTER_ROUTES_MAX_GSI
changes (ADAPTER_ROUTES_MAX_GSI is going to change because we want to
support up to VIRTIO_QUEUE_MAX queues per virtio-ccw device).

Let us introduce a check on a recently introduce flic property which
gives us the compatibility machine aware limit on adapter routes.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 069097dad311ac9c6933d95ebee7c0b53b3378c4
      
https://github.com/qemu/qemu/commit/069097dad311ac9c6933d95ebee7c0b53b3378c4
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c
    M include/hw/s390x/s390_flic.h

  Log Message:
  -----------
  s390x: bump ADAPTER_ROUTES_MAX_GSI

Let's increase ADAPTER_ROUTES_MAX_GSI to VIRTIO_QUEUE_MAX which is the
largest demand foreseeable at the moment. Let us add a compatibility
macro for the previous machines so client code can maintain backwards
migration compatibility

To not mess up migration compatibility for virtio-ccw
VIRTIO_CCW_QUEUE_MAX is left at it's current value, and will be dropped
when virtio-ccw is converted to use the capability of the flic
introduced by this patch.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: b1914b824ade1706847428e64ef5637ffc0ae238
      
https://github.com/qemu/qemu/commit/b1914b824ade1706847428e64ef5637ffc0ae238
  Author: Halil Pasic <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c
    M hw/s390x/virtio-ccw.c
    M include/hw/s390x/s390_flic.h

  Log Message:
  -----------
  virtio-ccw: support VIRTIO_QUEUE_MAX virtqueues

The maximal number of virtqueues per device can be limited on a per
transport basis. For virtio-ccw this limit is defined by
VIRTIO_CCW_QUEUE_MAX, however the limitation used to come form the
number of adapter routes supported by flic (via notifiers).

Recently the limitation of the flic was adjusted so that it can
accommodate VIRTIO_QUEUE_MAX queues, and is in the meanwhile checked for
separately too.

Let us remove the transport specific limitation of virtio-ccw by
dropping VIRTIO_CCW_QUEUE_MAX and using VIRTIO_QUEUE_MAX instead.

Signed-off-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 5f706fdc164b20b48254eadf7bd413edace34499
      
https://github.com/qemu/qemu/commit/5f706fdc164b20b48254eadf7bd413edace34499
  Author: Christian Borntraeger <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M target/s390x/arch_dump.c

  Log Message:
  -----------
  s390x/arch_dump: use proper note name and note size

In binutils/libbfd (bfd/elf.c) it is enforced that all s390
specific ELF notes like e.g. NT_S390_PREFIX or NT_S390_CTRS
have "LINUX" specified as note name and that the namesz is
6. Otherwise the notes are ignored.

QEMU currently uses "CORE" for these notes. Up to now this has
not been a real problem because the dump analysis tool "crash"
does handle that. But it will break all programs that use libbfd
for processing ELF notes.

So fix this and use "LINUX" for all s390 specific notes to comply
with libbfd. Also set the correct namesz.

Reported-by: Philipp Rudo <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: f738f296eaaed719508207ba36b995ba73fe27db
      
https://github.com/qemu/qemu/commit/f738f296eaaed719508207ba36b995ba73fe27db
  Author: Christian Borntraeger <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M target/s390x/arch_dump.c

  Log Message:
  -----------
  s390x/arch_dump: pass cpuid into notes sections

we need to pass the cpuid into the pid field of the notes
section, otherwise the notes for different CPUs all have 0:

e.g. objdump -h shows:
old:
  5 .reg-s390-prefix/0 00000004  0000000000000000  0000000000000000
  6 .reg-s390-prefix 00000004  0000000000000000  0000000000000000
 21 .reg-s390-prefix/0 00000004  0000000000000000  0000000000000000
new:
  5 .reg-s390-prefix/1 00000004  0000000000000000  0000000000000000
  6 .reg-s390-prefix 00000004  0000000000000000  0000000000000000
 21 .reg-s390-prefix/2 00000004  0000000000000000  0000000000000000

Reported-by: Philipp Rudo <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 9f94f84ce7df633142953806cc4c102765cabc0e
      
https://github.com/qemu/qemu/commit/9f94f84ce7df633142953806cc4c102765cabc0e
  Author: Dong Jia Shi <address@hidden>
  Date:   2017-02-24 (Fri, 24 Feb 2017)

  Changed paths:
    M hw/s390x/css.c

  Log Message:
  -----------
  s390x/css: handle format-0 TIC CCW correctly

For TIC CCW, bit positions 8-32 of the format-1 CCW must contain zeros;
otherwise, a program-check condition is generated. For format-0 TIC CCWs,
bits 32-63 are ignored.

To convert TIC from format-0 CCW to format-1 CCW correctly, let's clear
bits 8-32 to guarantee compatibility.

Reviewed-by: Pierre Morel <address@hidden>
Signed-off-by: Dong Jia Shi <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>


  Commit: 2421f381dc38a8a6d12477c08c2f74a35a0698f8
      
https://github.com/qemu/qemu/commit/2421f381dc38a8a6d12477c08c2f74a35a0698f8
  Author: Peter Maydell <address@hidden>
  Date:   2017-02-25 (Sat, 25 Feb 2017)

  Changed paths:
    M hw/intc/s390_flic.c
    M hw/intc/s390_flic_kvm.c
    M hw/s390x/css.c
    M hw/s390x/s390-virtio-ccw.c
    M hw/s390x/s390-virtio.c
    M hw/s390x/virtio-ccw.c
    M hw/s390x/virtio-ccw.h
    M include/hw/s390x/s390_flic.h
    M target/s390x/arch_dump.c
    M target/s390x/kvm.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20170224' into staging

A selection of s390x patches:
- cleanups, fixes and improvements
- program check loop detection (useful with the corresponding kernel
  patch)
- wire up virtio-crypto for ccw
- and finally support many virtqueues for virtio-ccw

# gpg: Signature made Fri 24 Feb 2017 09:19:19 GMT
# gpg:                using RSA key 0xDECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <address@hidden>"
# gpg:                 aka "Cornelia Huck <address@hidden>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20170224:
  s390x/css: handle format-0 TIC CCW correctly
  s390x/arch_dump: pass cpuid into notes sections
  s390x/arch_dump: use proper note name and note size
  virtio-ccw: support VIRTIO_QUEUE_MAX virtqueues
  s390x: bump ADAPTER_ROUTES_MAX_GSI
  virtio-ccw: check flic->adapter_routes_max_batch
  s390x: add property adapter_routes_max_batch
  virtio-ccw: Check the number of vqs in CCW_CMD_SET_IND
  virtio-ccw: add virtio-crypto-ccw device
  virtio-ccw: handle virtio 1 only devices
  s390x/flic: fail migration on source already
  s390x/kvm: detect some program check loops
  s390x/s390-virtio: get rid of DPRINTF

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/f62ab6bb8f6f...2421f381dc38