Hi,
You can find the image attached. Regards Saanjh Sengupta ________________________________ From: Saanjh Sengupta <saanjhsengu...@outlook.com> Sent: Tuesday, March 11, 2025 3:20:48 PM To: Pierrick Bouvier <pierrick.bouv...@linaro.org>; 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, I have a couple of questions: 1. When I use the libstoptrigger.so: in that case the QEMU 's emulation stops after executing the defined number of instructions. Post this, the whole QEMU terminates. And while using the libips.so I am assuming that the QEMU doesn't execute no more than the defined instructions. Please correct me if I am wrong. 2. In my case, I want the QEMU to start emulation for some time and PAUSE it's emulation for some time; after it is Paused (it's virtual time is also to be paused) and then let's say for after 'x' time period it should resume it's virtual time. [image] I have added this segment inside the update_system_time function inside the ipsPlugin.c. but once the instructions reach to the defined limit the virtual time does not seem to stop. Do you have any suggestions on that front? 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 >> >
