Re: Generic way to detect qemu linux-user emulation

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Mar 18, 2025 at 10:53:27AM +0000, Peter Maydell wrote:
> On Tue, 18 Mar 2025 at 10:36, Helge Deller <deller@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...

It also isn't future proof. People will change their program behaviour
based on the limitations of the particular QEMU version they tested
against. QEMU later changes/fixes its impl, and apps are not eithuer
applying a redundant workaround, or worse, applying a workaround that
is now actively harmful.

Whereever practical, it is preferrable to check a discrete feature
or behaviour in a functional way, rather than matching on "is it QEMU"

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|