On Tue, 18 Mar 2025 at 10:36, Helge Deller <del...@gmx.de> wrote: > > On 3/18/25 11:18, Andreas Schwab wrote: > > Is there a generic way for a program to detect that is it being run > > inside the linux-user emulation? > > Yes, having a reliable way to detect it would be good. > > My current (unreliable) way to detect it is using uname.
Yes, I don't believe there's currently an "intended" mechanism for detecting QEMU, only ways of noticing long-standing deviations from how the real kernel behaves. > > The purpose for that would be to work around limitations of the > > emulation, like CLONE_VFORK being unsupported. > > yes, and robust futexes aren't supported either. You don't need to detect QEMU for that one, though -- you can just try the get_robust_list syscall and if it fails ENOSYS then fall back to a codepath that doesn't use them (same as you would on an ancient kernel that didn't implement the syscall). Robust futexes are in the "technically extremely hard to impossible to support" bucket, per the comment in syscall.c. > In qemu-user emulation we could change the return values of > "uname --processor" and/or "uname --hardware-platform". > Currently both always return "unknown", but in qemu we could > return the arch of the host. As a mechanism that feels a bit risky to me -- at some point somebody may come along and say "my guest program requires that these return the expected values for the target CPU", and then you have a conflict between whether you want them to behave correctly for the target or to give you the "tell me it's QEMU" behaviour... -- PMM
