[UBUNTU 20.04] KVM hardware diagnose data improvements for guest kernel - qemu part
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Skipper Bug Screeners | ||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Canonical Server | ||
Focal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
SRU Justification:
==================
[Impact]
* Hardware diagnose data (diag 318) of KVM guest kernel cannot be handled.
* A fix is needed to enhance problem determination of guest kernel under KVM using DIAG 0x318 instruction execution.
* The s390x diagnose 318 instruction sets the control program name code (CPNC) and control program version code (CPVC) to provide useful information regarding the OS during debugging.
* The CPNC is explicitly set to 4 to indicate a Linux/KVM environment.
* The user story to this is, that s390x clearly is a platform that has
virtualization for ages, and as part of that established diag calls to
allow you add data to guests. This helps live management and/or guest
debugging in case of problems. For KVM guests this data is
wrong/incomplete so far and this is the fix for it.
You might want to see [1] for the base-feature that this fixes. And do
not say it is ugly, I did not send the PoP page about diags :-)
[1]: https:/
[Fix]
* In general the following 9 patches (backports) are needed:
* "[PATCH 1/9] s390/sclp: get machine once during read scp/cpu info"
https:/
* "[PATCH 2/9] s390/sclp: rework sclp boundary checks"
https:/
* "[PATCH 3/9] s390/sclp: read sccb from mem based on provided length"
https:/
* "[PATCH 4/9] s390/sclp: check sccb len before filling in data"
https:/
* "[PATCH 5/9] s390/sclp: use cpu offset to locate cpu entries"
https:/
* "[PATCH 6/9] s390/sclp: add extended-length sccb support for kvm guest"
https:/
* "[PATCH 7/9] s390: guest support for diagnose 0x318"
https:/
* "[PATCH 8/9] s390x: pv: Remove sclp boundary checks"
https:/
* "[PATCH 9/9] s390x: pv: Fix diag318 PV fencing"
https:/
[Test Case]
* Setup an IBM Z or LinuxONE LPAR with Ubuntu Server as KVM host.
* And setup an Ubuntu KVM virtual machine on top.
* It can then be observed if the CPNC (diag318 data) has been successfully set by looking at the s390dbf messages for the KVM guest.
* The CPNC will always be 4 (denotes Linux environment).
* Another way to test this is by running the sync_regs_test under tools/testing/
* It is important that the patched qemu is tested with correct patched kernel, since one required the other - they can be found here:
qemu: https:/
kernel: https:/
[Where problems could occur]
* The approach here is to provide additional debug and diagnose information on top.
* Hence even if the diag318 changes are broken, the existing functionality shouldn't be harmed.
* However, with the functional changes broken code could be introduced (e.g. due to erroneous pointer arithmetic for example) that does not compile or causes crashes. But this is what the test builds are for
qemu: https:/
(kernel: https:/
* On top the diag318 diagnose data might not properly provided - maybe empty or wrong. Again that is what the test builds and the verification later is targeted at.
[Other]
* LP#1953334 is related to this bug and covers the Kernel part.
__________
Hardware diagnose data (diag 318) of KVM guest kernel cannot be handled.
Fix needed to enhance problem determination of guest kernel under KVM
Solution provided by Collin:
All patches are provided to enable the DIAGNOSE 0x318 problem determination aid for a QEMU guest. Analogous KVM patches are required.
This solution required the prerequisite Extended-Length SCCB patches as well.
I've applied a bugfix related to resetting the diag318 to one of the patches (one line fix -- upstream conversation here: https:/
CVE References
tags: | added: architecture-s39064 bugnameltc-195467 severity-high targetmilestone-inin2004 |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
affects: | linux (Ubuntu) → qemu (Ubuntu) |
Changed in ubuntu-z-systems: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
Changed in qemu (Ubuntu): | |
assignee: | Skipper Bug Screeners (skipper-screen-team) → Canonical Server Team (canonical-server) |
Changed in ubuntu-z-systems: | |
importance: | Undecided → High |
Changed in qemu (Ubuntu): | |
status: | Incomplete → New |
Changed in ubuntu-z-systems: | |
status: | New → Triaged |
description: | updated |
Changed in qemu (Ubuntu Focal): | |
status: | Incomplete → In Progress |
description: | updated |
Changed in ubuntu-z-systems: | |
status: | Triaged → In Progress |
Changed in ubuntu-z-systems: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → Fix Released |
Thanks for the heads up,
Please let us know when the upstream discussion settled and there is a commit id we shall import.
Furthermore as usual if this shall go to older active releases I wanted to ask from your dev/testing what the best way to trigger/fake diag 318 for testing would be?