Re: Building QEMU as a Shared Library

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

Hi Saanjh,

depending what you are trying to achieve exactly, plugins can provide a 
solution. It's convenient and you can stay on top of QEMU upstream, 
without having to create a downstream fork.

We already have plugins for stopping after a given number of 
instructions, or slow down execution of a VM:

# stop after executing 1'000'000 instructions:
$ ./build/qemu-system-x86_64 -plugin 
./build/contrib/plugins/libstoptrigger,icount=1000000 -d plugin

# execute no more than 1'000'000 instructions per second:
$ ./build/qemu-system-x86_64 -plugin 
./build/contrib/plugins/libips.so,ips=1000000 -d plugin

You can see source code associated (./contrib/plugins/stoptrigger.c and 
./contrib/plugins/ips.c), to implement something similar to what you 
want, but based on time.
Would that satisfy your need?

Regards,
Pierrick

On 3/3/25 21:53, Saanjh Sengupta wrote:
> 
> 
> Hi,
> 
> Thank you so much for your inputs. I was able to create the .so file of 
> QEMU.
> 
> Actually, what we are trying is to understand and explore possibilities 
> of Virtual Time Control in QEMU. In short, what I mean to say is an 
> approach via which I can tell QEMU to emulate for XYZ time when the I 
> give a trigger and then pause the emulation by itself after the XYZ time 
> is completed.
> 
> On that front itself, do you have any inputs/ideas regarding the same?
> 
> 
> Regards
> Saanjh Sengupta
> ------------------------------------------------------------------------
> *From:* Pierrick Bouvier <pierrick.bouvier@linaro.org>
> *Sent:* Tuesday, February 25, 2025 6:29:44 AM
> *To:* Philippe Mathieu-Daudé <philmd@linaro.org>; Paolo Bonzini 
> <pbonzini@redhat.com>; Marc-André Lureau <marcandre.lureau@redhat.com>
> *Cc:* amir.gonnen@neuroblade.ai <amir.gonnen@neuroblade.ai>; qemu- 
> devel@nongnu.org <qemu-devel@nongnu.org>; Saanjh Sengupta 
> <saanjhsengupta@outlook.com>
> *Subject:* Re: Building QEMU as a Shared Library
> Hi Saanjh,
> 
> here is a minimal patch that builds one shared library per target (arch,
> mode) where arch is cpu arch, and mode is system or user, and launch
> system-aarch64 through a simple driver:
> 
> https://github.com/pbo-linaro/qemu/commit/ 
> fbb39cc64f77d4bf1e5e50795c75b62735bf5c5f <https://github.com/pbo-linaro/ 
> qemu/commit/fbb39cc64f77d4bf1e5e50795c75b62735bf5c5f>
> 
> With this, it could be possible to create a driver that can execute any
> existing target. It's a sort of single binary for QEMU, but shared
> objects are mandatory, and duplicates all the QEMU state. So there is no
> real benefit compared to having different processes.
> 
> In more, to be able to do concurrent emulations, there are much more
> problems to be solved. QEMU state is correctly kept per target, but all
> other libraries states are shared. There are various issues if you
> launch two emulations at the same time in two threads:
> - glib global context
> - qemu calls exit in many places, which stops the whole process
> - probably other things I didn't explore
> 
> At this point, even though qemu targets can be built as shared objects,
> I would recommend to use different processes, and implement some form on
> IPC to synchronize all this.
> Another possibility is to try to build machines without using the
> existing main, but I'm not sure it's worth all the hassle.
> 
> What are you trying to achieve?
> 
> Regards,
> Pierrick
> 
> On 2/24/25 01:10, Philippe Mathieu-Daudé wrote:
>> Cc'ing our meson experts
>> 
>> On 22/2/25 14:36, Saanjh Sengupta wrote:
>>> Hi,
>>>
>>> I referred to your mailing chains on suggesting QEMU to be built as a
>>> shared library.
>>>
>>> *Change meson.build to build QEMU as a shared library (with PIC enabled
>>> for static libraries)*
>>> *
>>> *
>>> Could you please suggest what exactly has to be enabled in the meson.build?
>>>
>>> I am confused on that front.
>>>
>>> Regards
>>> Saanjh Sengupta
>> 
>