Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1967905
Summary: | Fatal glibc error: CPU lacks VXE support (z14 or later required) | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | YongkuiGuo <yoguo> | ||||
Component: | libguestfs | Assignee: | Virtualization Maintenance <virt-maint> | ||||
Status: | ASSIGNED --- | QA Contact: | YongkuiGuo <yoguo> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 9.0 | CC: | cohuck, dhildenb, qzhang, rjones, thuth, virt-maint | ||||
Target Milestone: | rc | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | s390x | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | Type: | Bug | |||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 910269 | ||||||
Attachments: |
|
Description
YongkuiGuo
2021-06-04 11:01:49 UTC
The glibc message is intentional: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/s390-64/dl-hwcap-check.h;h=87e18be6bd0c512bfffe0421fe243524193abdcf;hb=HEAD#l35 The question is whether TCG is able to or will be able to emulate this feature now or in future. It's generally useful for us to be able to run libguestfs nested w/o nested KVM support, although it's not something that we would support specifically on s390x (because we don't ship virt-v2v there). (In reply to Richard W.M. Jones from comment #1) > The glibc message is intentional: > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/s390-64/dl- > hwcap-check.h;h=87e18be6bd0c512bfffe0421fe243524193abdcf;hb=HEAD#l35 > > The question is whether TCG is able to or will be able to emulate this > feature now or in future. TCG already supports most z14 instructions. A handful of Vector FPU instructions are missing. With that, we can enable VXE and switch to a z14. z14 support is on its way upstream: https://lore.kernel.org/qemu-devel/20210517142739.38597-1-david@redhat.com/ The latest state lives at: https://github.com/davidhildenbrand/qemu/tree/z14 With that, latest/greatest rhel9 should boot just fine. Could reproduce the bug with this guest command: /usr/libexec/qemu-kvm \ -global virtio-blk-ccw.scsi=off \ -no-user-config \ -nodefaults \ -display none \ -machine accel=tcg \ -cpu max \ -m 1280 \ -no-reboot \ -rtc driftfix=slew \ -kernel /var/tmp/.guestfs-0/appliance.d/kernel \ -initrd /var/tmp/.guestfs-0/appliance.d/initrd \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-ccw,rng=rng0 \ -device virtio-scsi-ccw,id=scsi \ -drive file=/home/bfu/RHEL-8.5.0-20210506.n.0-s390x.qcow2,cache=unsafe,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/var/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw \ -device scsi-hd,drive=appliance \ -device virtio-serial-ccw \ -chardev stdio,id=charconsole0 \ -device sclpconsole,chardev=charconsole0 \ -append "panic=1 console=ttysclp0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=UUID=9e192f01-def5-40cc-aab2-743d668be445 selinux=0 guestfs_verbose=1 TERM=xterm-256color" (In reply to bfu from comment #3) > Could reproduce the bug with this guest command: > /usr/libexec/qemu-kvm \ > -global virtio-blk-ccw.scsi=off \ > -no-user-config \ > -nodefaults \ > -display none \ > -machine accel=tcg \ > -cpu max \ > -m 1280 \ > -no-reboot \ > -rtc driftfix=slew \ > -kernel /var/tmp/.guestfs-0/appliance.d/kernel \ > -initrd /var/tmp/.guestfs-0/appliance.d/initrd \ > -object rng-random,filename=/dev/urandom,id=rng0 \ > -device virtio-rng-ccw,rng=rng0 \ > -device virtio-scsi-ccw,id=scsi \ > -drive > file=/home/bfu/RHEL-8.5.0-20210506.n.0-s390x.qcow2,cache=unsafe,format=raw, > id=hd0,if=none \ > -device scsi-hd,drive=hd0 \ > -drive > file=/var/tmp/.guestfs-0/appliance.d/root,snapshot=on,id=appliance, > cache=unsafe,if=none,format=raw \ > -device scsi-hd,drive=appliance \ > -device virtio-serial-ccw \ > -chardev stdio,id=charconsole0 \ > -device sclpconsole,chardev=charconsole0 \ > -append "panic=1 console=ttysclp0 edd=off udevtimeout=6000 > udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory > usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 > root=UUID=9e192f01-def5-40cc-aab2-743d668be445 selinux=0 guestfs_verbose=1 > TERM=xterm-256color" qemu version: qemu-kvm-6.0.0-5.el9.s390x host kernel: 5.13.0-0.rc2.19.el9.s390x guest kernel: 5.13.0-0.rc2.19.el9.s390x libguestfs: libguestfs-1.45.6-6.el9.s390x VXE support has been merged into upstream QEMU; it should flow into el9 qemu-kvm naturally via the next rebase. Can you guys retry with upstream QEMU? Make sure not use a recent rhel9 kernel in the guest, because there was a VXE mis-detection BUG that I just recently fixed upstream. I will close this as RAWHIDE if nobody objects. Maybe better to leave it open, reassigned to libguestfs if necessary, so that we ensure that it is tested before RHEL 9 is released. I don't have the time nor the s390 machine to test it right now. (In reply to Richard W.M. Jones from comment #6) > Maybe better to leave it open, reassigned to libguestfs if necessary, > so that we ensure that it is tested before RHEL 9 is released. Sure, I can reassign then. > > I don't have the time nor the s390 machine to test it right now. You don't need a s390x machine, because we're talking about TCG ... but you'll most certainly need time. :) |