Functions marked with __attribute__((__constructor__)) will be
invoked in linker order. In theory this is well defined, but
in practice, it is hard to determine what this order will be
with the layers of indirection through meson, ninja and the
static libraries QEMU builds.

Notably, the order currently appears different between Linux
and Windows (as tested with Wine on Linux). This can cause
problems when certain QEMU constructors have a dependancy on
other QEMU constructors.

To address this define a QEMU_CONSTRUCTOR_EARLY constant which
provides a priority value that will run before other default
constructors. This is to be used for QEMU constructors that
are themselves self-contained, but may be relied upon by other
constructors.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 include/qemu/compiler.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 1c2b673c05..4c49f52eb0 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -194,6 +194,14 @@
 # define QEMU_USED
 #endif
 
+/*
+ * A priority for __attribute__((constructor(...))) that
+ * will run earlier than the default constructors. Must
+ * only be used for functions that have no dependency
+ * on global initialization of other QEMU subsystems.
+ */
+#define QEMU_CONSTRUCTOR_EARLY 101
+
 /*
  * Disable -ftrivial-auto-var-init on a local variable.
  *
-- 
2.52.0

On 1/8/26 18:03, Daniel P. Berrangé wrote:
> Functions marked with __attribute__((__constructor__)) will be
> invoked in linker order. In theory this is well defined, but
> in practice, it is hard to determine what this order will be
> with the layers of indirection through meson, ninja and the
> static libraries QEMU builds.
> 
> Notably, the order currently appears different between Linux
> and Windows (as tested with Wine on Linux). This can cause
> problems when certain QEMU constructors have a dependancy on
> other QEMU constructors.

What dependency are you seeing, or introducing?

In theory QEMU constructors should not have any dependency, as we only 
use them to initialize static data structures (such as the various 
*_init macros).

Not an objection, but I'd like to understand this better.

Paolo

> To address this define a QEMU_CONSTRUCTOR_EARLY constant which
> provides a priority value that will run before other default
> constructors. This is to be used for QEMU constructors that
> are themselves self-contained, but may be relied upon by other
> constructors.
> 
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   include/qemu/compiler.h | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
> index 1c2b673c05..4c49f52eb0 100644
> --- a/include/qemu/compiler.h
> +++ b/include/qemu/compiler.h
> @@ -194,6 +194,14 @@
>   # define QEMU_USED
>   #endif
>   
> +/*
> + * A priority for __attribute__((constructor(...))) that
> + * will run earlier than the default constructors. Must
> + * only be used for functions that have no dependency
> + * on global initialization of other QEMU subsystems.
> + */
> +#define QEMU_CONSTRUCTOR_EARLY 101
> +
>   /*
>    * Disable -ftrivial-auto-var-init on a local variable.
>    *

On Fri, Jan 09, 2026 at 12:39:59PM +0100, Paolo Bonzini wrote:
> On 1/8/26 18:03, Daniel P. Berrangé wrote:
> > Functions marked with __attribute__((__constructor__)) will be
> > invoked in linker order. In theory this is well defined, but
> > in practice, it is hard to determine what this order will be
> > with the layers of indirection through meson, ninja and the
> > static libraries QEMU builds.
> > 
> > Notably, the order currently appears different between Linux
> > and Windows (as tested with Wine on Linux). This can cause
> > problems when certain QEMU constructors have a dependancy on
> > other QEMU constructors.
> 
> What dependency are you seeing, or introducing?
> 
> In theory QEMU constructors should not have any dependency, as we only use
> them to initialize static data structures (such as the various *_init
> macros).
> 
> Not an objection, but I'd like to understand this better.

See the commit message in patch 2.   Essentially the RCU thread
gets spawned from a constructor, and if anything it does results
in an error_report() call, it will trigger use of monitor APIs
before the monitor constructor has had a chance to run.

IMHO the root problem is that it is pretty dubious for us to be
spawning the RCU thread from a constructor. Constructors should
be limited to minimal initialization of state. Spawning threads
is outside the boundary of what I'd consider reasonable for
a constructor todo. I didn't want try to tackle refactoring the
RCU thread creation though, hence this gross workaround.

> 
> Paolo
> 
> > To address this define a QEMU_CONSTRUCTOR_EARLY constant which
> > provides a priority value that will run before other default
> > constructors. This is to be used for QEMU constructors that
> > are themselves self-contained, but may be relied upon by other
> > constructors.
> > 
> > Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> > Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >   include/qemu/compiler.h | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
> > index 1c2b673c05..4c49f52eb0 100644
> > --- a/include/qemu/compiler.h
> > +++ b/include/qemu/compiler.h
> > @@ -194,6 +194,14 @@
> >   # define QEMU_USED
> >   #endif
> > +/*
> > + * A priority for __attribute__((constructor(...))) that
> > + * will run earlier than the default constructors. Must
> > + * only be used for functions that have no dependency
> > + * on global initialization of other QEMU subsystems.
> > + */
> > +#define QEMU_CONSTRUCTOR_EARLY 101
> > +
> >   /*
> >    * Disable -ftrivial-auto-var-init on a local variable.
> >    *
> 

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 :|

On 1/9/26 12:46, Daniel P. Berrangé wrote:
> IMHO the root problem is that it is pretty dubious for us to be
> spawning the RCU thread from a constructor. Constructors should
> be limited to minimal initialization of state. Spawning threads
> is outside the boundary of what I'd consider reasonable for
> a constructor todo. I didn't want try to tackle refactoring the
> RCU thread creation though, hence this gross workaround.

I see.  Maybe we could (just as gross but smaller) do the RCU 
constructor late.  Not something that you need to do now, of course.

Paolo

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 1/9/26 12:46, Daniel P. Berrangé wrote:
>> IMHO the root problem is that it is pretty dubious for us to be
>> spawning the RCU thread from a constructor. Constructors should
>> be limited to minimal initialization of state.

Yes!  Discussed in review of v3:

    https://lore.kernel.org/qemu-devel/87frck1dds.fsf@pond.sub.org/
    Message-ID: <87frck1dds.fsf@pond.sub.org>

>>                                                Spawning threads
>> is outside the boundary of what I'd consider reasonable for
>> a constructor todo. I didn't want try to tackle refactoring the
>> RCU thread creation though, hence this gross workaround.
>
> I see.  Maybe we could (just as gross but smaller) do the RCU constructor late.  Not something that you need to do now, of course.

Could we use an old-fashioned initialization function instead of a
constructor for RCU?

Il mar 13 gen 2026, 10:04 Markus Armbruster <armbru@redhat.com> ha scritto:

> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > On 1/9/26 12:46, Daniel P. Berrangé wrote:
> >> IMHO the root problem is that it is pretty dubious for us to be
> >> spawning the RCU thread from a constructor. Constructors should
> >> be limited to minimal initialization of state.
>
> Yes!  Discussed in review of v3:
>
>     https://lore.kernel.org/qemu-devel/87frck1dds.fsf@pond.sub.org/
>     Message-ID: <87frck1dds.fsf@pond.sub.org>
>
> >>                                                Spawning threads
> >> is outside the boundary of what I'd consider reasonable for
> >> a constructor todo. I didn't want try to tackle refactoring the
> >> RCU thread creation though, hence this gross workaround.
> >
> > I see.  Maybe we could (just as gross but smaller) do the RCU
> constructor late.  Not something that you need to do now, of course.
>
> Could we use an old-fashioned initialization function instead of a
> constructor for RCU?
>

You have to do it in all main()s, which make it unwieldy for tests etc.

Another possibility is to do it lazily on first call_rcu, and just clear
the flag in the atfork callbacks.

Paolo


>

On Tue, Jan 13, 2026 at 10:32:48AM +0100, Paolo Bonzini wrote:
> Il mar 13 gen 2026, 10:04 Markus Armbruster <armbru@redhat.com> ha scritto:
> 
> > Paolo Bonzini <pbonzini@redhat.com> writes:
> >
> > > On 1/9/26 12:46, Daniel P. Berrangé wrote:
> > >> IMHO the root problem is that it is pretty dubious for us to be
> > >> spawning the RCU thread from a constructor. Constructors should
> > >> be limited to minimal initialization of state.
> >
> > Yes!  Discussed in review of v3:
> >
> >     https://lore.kernel.org/qemu-devel/87frck1dds.fsf@pond.sub.org/
> >     Message-ID: <87frck1dds.fsf@pond.sub.org>
> >
> > >>                                                Spawning threads
> > >> is outside the boundary of what I'd consider reasonable for
> > >> a constructor todo. I didn't want try to tackle refactoring the
> > >> RCU thread creation though, hence this gross workaround.
> > >
> > > I see.  Maybe we could (just as gross but smaller) do the RCU
> > constructor late.  Not something that you need to do now, of course.
> >
> > Could we use an old-fashioned initialization function instead of a
> > constructor for RCU?
> >
> 
> You have to do it in all main()s, which make it unwieldy for tests etc.
> 
> Another possibility is to do it lazily on first call_rcu, and just clear
> the flag in the atfork callbacks.

I'd be concerned that we would not be able to rationalize what thread is
starting the RCU thread. It will probably be the main thread, but proving
that will be difficult. A thread which is not the main thread may have
undesirable CPU affinity set which we don't have the RCU thread to inherit.

IMHO if we remove the constructor, then we need to have a strong guarantee
that it is spawned from the main() method and not from any other background
thread.

I wouldn't rule our doing it manually from every main() method. We could
probably come up with something to make it less of a burden for test
programs.

eg replace g_test_init() with q_test_init() which combines g_test_init
with RCU thread creation.

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 :|