Hi, Thank you for your inputs. Let me check with the information you provided. Will let you know if I am stuck with something.
Regards Saanjh Sengupta ________________________________ From: Pierrick Bouvier <pierrick.bouv...@linaro.org> Sent: Wednesday, March 5, 2025 5:20:38 AM To: Saanjh Sengupta <saanjhsengu...@outlook.com>; Philippe Mathieu-Daudé <phi...@linaro.org>; Paolo Bonzini <pbonz...@redhat.com>; Marc-André Lureau <marcandre.lur...@redhat.com> Cc: amir.gon...@neuroblade.ai <amir.gon...@neuroblade.ai>; qemu-devel@nongnu.org <qemu-devel@nongnu.org>; Alex Bennée <alex.ben...@linaro.org> Subject: Re: Building QEMU as a Shared Library 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.bouv...@linaro.org> > *Sent:* Tuesday, February 25, 2025 6:29:44 AM > *To:* Philippe Mathieu-Daudé <phi...@linaro.org>; Paolo Bonzini > <pbonz...@redhat.com>; Marc-André Lureau <marcandre.lur...@redhat.com> > *Cc:* amir.gon...@neuroblade.ai <amir.gon...@neuroblade.ai>; qemu- > de...@nongnu.org <qemu-devel@nongnu.org>; Saanjh Sengupta > <saanjhsengu...@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 >> >