** Description changed:
+ [Impact]
+
+ * Needlessly slow systemctl daemon-reload on baremetal s390x machines
+ * Wipes information about auxilary bits, by force resetting kernel version
+
+ [Test Case]
+
+ $ cat /sys/firmware/cpi/system_level
+ 0x0000000000041200
+
+ Note the 41200 digits, this is hex-encoded kernel version number. Can be
+ different depending on the kernel in use
+
+ $ sudo /lib/s390-tools/cpictl -b kvm
+ $ cat /sys/firmware/cpi/system_level
+ 0x8000000000041200
+
+ # Note the leading bit is now 0x8, instead of 0x0
+
+ $ sudo systemctl daemon-reload
+ $ cat /sys/firmware/cpi/system_level
+ 0x8000000000041200 -> is correct, 0x8 is preserved
+ 0x0000000000041200 -> is wrong, 0x8 got reset to 0x0
+
+ [Solution]
+ In Ubuntu, cpi vars are set using systemd generator on early boot, thus HMC
displays correct information about an LPAR very early on.
+ However, setting them takes about 1s, and at the moment was done upon every
systemctl daemon-reload.
+ In addition, when kvm is used, cplictl -b kvm is called to update the leading
kvm usage bit, this was getting lost upon every systemctl daemon-reload.
+
+ Instead, modify the generator to guard against re-setting cpi vars, if
+ they were ever set once.
+
+ [Regression Potential]
+
+ * At worst case scenario, cpi-vars would not be set, leading to
+ cosmetic issue of not able to see auxilary information (e.g. UBUNTU,
+ running kernel version, Ubuntu release version) in the HMC console. As
+ the variables form /sys/firmware/cpi/* are displayed in the HMC.
+
+ [Other Info]
+
+ * Original bug report
+
---Problem Description---
CPI information about kvm usage is lost during apt upgrade
-
+
---uname output---
4.15.0-42-generic
-
- Machine Type = s390x lpar
-
+
+ Machine Type = s390x lpar
+
---Steps to Reproduce---
# cat /sys/firmware/cpi/*
cat: /sys/firmware/cpi/set: Permission denied
-
+
0x0000000000040f00
-
- LINUX
+
+ LINUX
root@m83lp52:~# virsh start guest # starting a guest does set the highest
bit in
- /sys/firmware/cpi/system_leveln
+ /sys/firmware/cpi/system_leveln
root@m83lp52:~# cat /sys/firmware/cpi/*
cat: /sys/firmware/cpi/set: Permission denied
-
+
0x8000000000040f00 <---- see the 8
-
- LINUX
+
+ LINUX
root@m83lp52:~# apt upgrade
[....]
has to upgrade at least one package, that will trigger some other code.
[....]
Now. some other code seems to have set values in /sys/firmware/cpi as
well dropping the kvm information.
root@m83lp52:~# cat /sys/firmware/cpi/*
cat: /sys/firmware/cpi/set: Permission denied
- 18 04 1
+ 18 04 1
0x0000000000040f00
- UBUNTU
- LINUX
-
+ UBUNTU
+ LINUX
The canonical place to handle /sys/firmware/cpi should be
/lib/s390-tools/cpictl and /lib/systemd/system/cpi.service. So can we put the
additional features (setting 18 04 1 and UBUNTU things also into
/etc/sysconfig/cpi
or
/lib/s390-tools/cpictl
)
and can we disable the other code that also sets /sys/firmware/cpi (I have
not found out which code sets these values). This seems to be
/lib/systemd/system-generators/s390-cpi-vars
** Changed in: s390-tools (Ubuntu)
Status: New => Fix Committed
** Also affects: s390-tools (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: s390-tools (Ubuntu Disco)
Importance: Undecided
Assignee: Skipper Bug Screeners (skipper-screen-team)
Status: Fix Committed
** Also affects: s390-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805841
Title:
CPI information about kvm usage is lost during apt upgrade
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1805841/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
