Summary: | sys-libs/glibc-2.27-r6 build failure : "Illegal instruction" testing 32bit in mixed AMD Intel virtualization environment | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lionel Bouton <lionel-dev> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | slyfox, tamiko, virtualization |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Lionel Bouton
2018-11-25 15:34:37 UTC
by default glibc attempts to infer best instruction set from runtime CPU at application startup. Does dmesg show you which instruction is attempted to be executed? gdb should should you what causes SIGILL. (In reply to Sergei Trofimovich from comment #1) > by default glibc attempts to infer best instruction set from runtime CPU at > application startup. Does dmesg show you which instruction is attempted to > be executed? > > gdb should should you what causes SIGILL. As I wrote it reports this (gdb> layout asm) : 0xf77d6c65 <__kernel_vsyscall+5> syscal Nothing in dmesg. I thought about restarting qemu without detaching from the terminal in case it reports attempts to use unsupported opcodes but this is a production system which doesn't make it easy. Then my guess would be that one of your host CPUs does not support SYSCALL emulation at least in 32-bit mode. (In reply to Sergei Trofimovich from comment #3) > Then my guess would be that one of your host CPUs does not support SYSCALL > emulation at least in 32-bit mode. I started reading about SYSCALL emulation and this seems like a mess with several implementations according to which cpu vendor and model you are using. I've found one KVM patch addressing this : https://lists.ubuntu.com/archives/kernel-team/2012-March/018646.html. Extract : Depending on the architecture (AMD or Intel) pretended by guests, various checks according to vendor's documentation are implemented to overcome the current issue and behave like the CPUs physical counterparts. I'm not familiar with this subject at all but in my case the CPU identifies as AuthenticAMD although QEMU was asked to emulate SandyBridge (probably copying the vendor_id from the initial host before live migration). So this could be triggered because of a mismatch between the vendor_id QEMU reports and how it handles the syscall emulation. This would make it a QEMU bug (running qemu-2.10.0 on hosts, couldn't find any recent bugfix for syscall emulation). Should I report this to QEMU devs directly (I didn't find a relevant bug report on https://launchpad.net/qemu at first glance) or do you think there's another possibility ? (In reply to Lionel Bouton from comment #4) > Should I report this to QEMU devs directly (I didn't find a relevant bug > report on https://launchpad.net/qemu at first glance) or do you think > there's another possibility ? Sounds like a good next step. I also suggest asking qemu upstream explicitly if it's a supported path to migrate like that. It might be that you need to pass more options to qemu (like, disable more host leaks) to make it work. Making vendorstring matching emulated sandybridge would make some sense on qemu side. Don't know if it's feasible or would fix your problem. Host kernel, guest kernel and guest userspace all can be subtly persisting initial VM CPU. CCing our qemu maintainers in case they might already know. Closing as INVALID assuming qemu is able to change CPU features underneath running glibc/kernel. |