Saanjh Sengupta <saanjhsengu...@outlook.com> writes: > Hi, > > Unable to view this. Any GitHub repository diff page I could view for > the same?
It was part of this series: https://patchew.org/QEMU/20241022105614.839199-1-alex.ben...@linaro.org/ Specifically this patch: https://patchew.org/QEMU/20241022105614.839199-1-alex.ben...@linaro.org/20241022105614.839199-18-alex.ben...@linaro.org/ > > Regards > Saanjh Sengupta > ------------------------------------------------------------------------------------------------------------------------- > From: Alex Bennée <alex.ben...@linaro.org> > Sent: Tuesday, March 18, 2025 1:48:01 PM > To: Saanjh Sengupta <saanjhsengu...@outlook.com> > Cc: Pierrick Bouvier <pierrick.bouv...@linaro.org>; Philippe Mathieu-Daudé > <phi...@linaro.org>; Paolo Bonzini > <pbonz...@redhat.com>; Marc-André Lureau <marcandre.lur...@redhat.com>; > amir.gon...@neuroblade.ai > <amir.gon...@neuroblade.ai>; qemu-devel@nongnu.org <qemu-devel@nongnu.org> > Subject: Re: Building QEMU as a Shared Library > > Saanjh Sengupta <saanjhsengu...@outlook.com> writes: > >> Hi Alex, >> >> You mentioned about a patch series; do you have it handy with you? > > Message-Id: <20241022105614.839199-18-alex.ben...@linaro.org> > Date: Tue, 22 Oct 2024 11:56:11 +0100 > Subject: [PATCH v2 17/20] plugins: add ability to register a GDB triggered > callback > From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.ben...@linaro.org> > >> >> If so, could you please direct me to the same ? >> >> On 14 Mar 2025, at 12:11 AM, Alex Bennée <alex.ben...@linaro.org> wrote: >> >> Saanjh Sengupta <saanjhsengu...@outlook.com> writes: >> >> Hi, >> >> What we are trying to achieve is that the QEMU should run for a particular >> number of instructions, let's say for >> example >> 10000 instructions and then pause it's emulation. After a resume trigger is >> received to the QEMU it must resume it's >> emulation and start the instruction count from 10001 (which basically >> means that the context should be saved). >> >> I think you want to run under icount and you will need to modify the >> trigger plugin. Under icount we run each vCPU in turn, so if the plugin >> pauses the vCPU will de-facto be paused. >> >> You would have to implement some sort of control interface in the >> plugin. Or you could add an API to trigger the gdbstub. I think I had >> that on a patch series at one point. >> >> In the previous mail when you mentioned g_usleep, I believe this shall not >> work (as per our use-case) since it will >> reset the >> instruction count to 0 (as per what you mentioned). >> >> To achieve the use-case, do you have any leads/suggestions ? >> >> Regards >> Saanjh Sengupta >> >> >> ------------------------------------------------------------------------------------------------------------------------- >> From: Pierrick Bouvier <pierrick.bouv...@linaro.org> >> Sent: Wednesday, March 12, 2025 11:50:23 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 >> >> On 3/11/25 21:31, Saanjh Sengupta wrote: >> >> Hi, >> >> Thank you for the clarification. Regarding the last time >> /"Stoptrigger might be a better fit for what you want to do, and instead >> of exiting, you want to resume emulation after N insn. The function >> qemu_clock_advance_virtual_time() can only be used to move the time >> forward, and you can not stop the "virtual time" by design."/ >> / >> / >> I did not quite understand this. Even if I have to modify the >> stopTrigger plugin, I would want it to pause rather than exiting. >> For example: It gets 10000 instructions executed after that it should >> pause and after some time it should then resume again execute till 20000 >> instructions (because previously it executed till 10000 and then it must >> execute till 20000). How do I do this? How do I state the code to pause >> the qemu's emulation after 10000 instructions? >> >> By using g_usleep to pause the current cpu. >> As well, it's needed to reset insn_count to 0 to count instructions again. >> >> With this command line: >> ./build/qemu-system-x86_64 -plugin >> ./build/contrib/plugins/libstoptrigger.so,icount=1000 -d plugin >> >> And with those changes to stoptrigger: >> >> diff --git a/contrib/plugins/stoptrigger.c b/contrib/plugins/stoptrigger.c >> index b3a6ed66a7b..77fd413cef1 100644 >> --- a/contrib/plugins/stoptrigger.c >> +++ b/contrib/plugins/stoptrigger.c >> @@ -41,11 +41,12 @@ typedef struct { >> int exit_code; >> } ExitInfo; >> >> -static void exit_emulation(int return_code, char *message) >> +static void pause_emulation(int return_code, char *message) >> { >> qemu_plugin_outs(message); >> g_free(message); >> - exit(return_code); >> + /* exit(return_code); */ >> + g_usleep(1 * G_USEC_PER_SEC); >> } >> >> static void exit_icount_reached(unsigned int cpu_index, void *udata) >> @@ -53,7 +54,9 @@ static void exit_icount_reached(unsigned int >> cpu_index, void *udata) >> uint64_t insn_vaddr = qemu_plugin_u64_get(current_pc, cpu_index); >> char *msg = g_strdup_printf("icount reached at 0x%" PRIx64 ", >> exiting\n", >> insn_vaddr); >> - exit_emulation(icount_exit_code, msg); >> + pause_emulation(icount_exit_code, msg); >> + /* reset instruction counter */ >> + qemu_plugin_u64_set(insn_count, cpu_index, 0); >> } >> >> static void exit_address_reached(unsigned int cpu_index, void *udata) >> @@ -61,7 +64,7 @@ static void exit_address_reached(unsigned int >> cpu_index, void *udata) >> ExitInfo *ei = udata; >> g_assert(ei); >> char *msg = g_strdup_printf("0x%" PRIx64 " reached, exiting\n", >> ei->exit_addr); >> - exit_emulation(ei->exit_code, msg); >> + pause_emulation(ei->exit_code, msg); >> } >> >> Moreover, I tried an activity where I was utilising the QMP protocol to >> control the virtual time (with respect to the IPS plugin). In that >> context when the QMP stop is triggered, my virtual time does got freezed >> until the resume is triggered. Does this mean I am able to manipulate >> the virtual time of the QEMU? >> >> I am not sure of how it works, but the plugin interface only allows to >> move time forward. >> >> Regards >> Saanjh Sengupta >> ------------------------------------------------------------------------ >> *From:* Pierrick Bouvier <pierrick.bouv...@linaro.org> >> *Sent:* Wednesday, March 12, 2025 2:14:47 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- >> de...@nongnu.org <qemu-devel@nongnu.org>; Alex Bennée >> <alex.ben...@linaro.org> >> *Subject:* Re: Building QEMU as a Shared Library >> On 3/11/25 02:50, Saanjh Sengupta wrote: >> >> 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. >> >> That's correct for both plugins, with the additional note that libips >> does this per second only. >> >> 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. >> >> The virtual time variable in ips plugin is only related to this plugin, >> and based on how many instructions have been executed, which is >> different from what you want to achieve. >> >> Stoptrigger might be a better fit for what you want to do, and instead >> of exiting, you want to resume emulation after N insn. >> The function qemu_clock_advance_virtual_time() can only be used to move >> the time forward, and you can not stop the "virtual time" by design. >> >> 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- >> de...@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/ <https://github.com/pbo- >> >> linaro/qemu/commit/> <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 >> >> -- >> Alex Bennée >> Virtualisation Tech Lead @ Linaro -- Alex Bennée Virtualisation Tech Lead @ Linaro
