[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 94b502: s390x/s390-virtio: get rid of DPRINTF
From: |
GitHub |
Subject: |
[Qemu-commits] [qemu/qemu] 94b502: s390x/s390-virtio: get rid of DPRINTF |
Date: |
Sat, 25 Feb 2017 10:45:08 -0800 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 94b502: s390x/s390-virtio: get rid of DPRINTF,
GitHub <=