Re: Building QEMU as a Shared Library
Hi,
Unable to view this. Any GitHub repository diff page I could view for the same?
Regards
Saanjh Sengupta
From: Alex Bennée
Sent: Tuesday, March 18, 2025 1:48:01 PM
To: Saanjh Sengupta
Cc: Pierrick Bouvier ; Philippe Mathieu-Daudé
; Paolo Bonzini ; Marc-André Lureau
; amir.gon...@neuroblade.ai
; qemu-devel@nongnu.org
Subject: Re: Building QEMU as a Shared Library
Saanjh Sengupta 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?=
>
> If so, could you please direct me to the same ?
>
> On 14 Mar 2025, at 12:11 AM, Alex Bennée wrote:
>
> Saanjh Sengupta 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
> 1 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
> Sent: Wednesday, March 12, 2025 11:50:23 am
> To: Saanjh Sengupta ; Philippe Mathieu-Daudé
> ; Paolo Bonzini
> ; Marc-André Lureau
> Cc: amir.gon...@neuroblade.ai ;
> qemu-devel@nongnu.org
> ; Alex
> Bennée
> 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 1 instructions executed after that it should
> pause and after some time it should then resume again execute till 2
> instructions (because previously it executed till 1 and then it must
> execute till 2). How do I do this? How do I state the code to pause
> the qemu's emulation after 1 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
Re: Building QEMU as a Shared Library
Hi Alex,
You mentioned about a patch series; do you have it handy with you?
If so, could you please direct me to the same ?
On 14 Mar 2025, at 12:11 AM, Alex Bennée wrote:
Saanjh Sengupta mailto: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
1 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
Sent: Wednesday, March 12, 2025 11:50:23 am
To: Saanjh Sengupta ; Philippe Mathieu-Daudé
; Paolo Bonzini
; Marc-André Lureau
Cc: amir.gon...@neuroblade.ai ;
qemu-devel@nongnu.org ; Alex
Bennée
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 1 instructions executed after that it should
pause and after some time it should then resume again execute till 2
instructions (because previously it executed till 1 and then it must
execute till 2). How do I do this? How do I state the code to pause
the qemu's emulation after 1 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
*Sent:* Wednesday, March 12, 2025 2:14:47 AM
*To:* Saanjh Sengupta ; Philippe Mathieu-
Daudé ; Paolo Bonzini ; Marc-
André Lureau
*Cc:* amir.gon...@neuroblade.ai ; qemu-
de...@nongnu.o
Re: Issue with stoptrigger.c Plugin in QEMU Emulation
Hi, Thank you for responding. The error is consistent while executing a command on the latest master branch (commit ID: 56c6e249b6988c1b6edc2dd34ebb0f1e570a1365) for the v10.0.0-rc3 release. Could you please confirm if you are using the same command (like I do in my case), and if possible, share it for reference? Also, what OS are you emulating in QEMU and what is your host machine configuration over which QEMU is running ? Regards Saanjh Sengupta Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: Pierrick Bouvier Sent: Thursday, April 10, 2025 8:55:32 PM To: Saanjh Sengupta Cc: phi...@linaro.org ; pbonz...@redhat.com ; marcandre.lur...@redhat.com ; amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; aabhashswai...@gmail.com ; anian...@gmail.com ; guptapriyanshi...@gmail.com ; harshitgupta5...@gmail.com Subject: Re: Issue with stoptrigger.c Plugin in QEMU Emulation Hi Saanjh, I have not been able to reproduce the issue with current master branch. Is it an error you see for every run? Regards, Pierrick On 4/10/25 04:10, Saanjh Sengupta wrote: > Hi, > > I am writing to seek assistance with an issue I am experiencing while > using the stoptrigger.c plugin in QEMU emulation. I am currently > utilising the latest QEMU version, 9.2.92, and attempting to emulate the > Debian 11 as the operating system. > > The command I am using to emulate QEMU is as follows: > *./build/qemu-system-x86_64 -m 2048M -smp 2 -boot c -nographic -serial > mon:stdio -nic tap,ifname=tap0,script=no,downscript=no -hda > debian11.qcow2 -icount shift=0 -plugin ./build/contrib/plugins/ > libstoptrigger.so,icount=90 -d plugin -qmp > tcp:localhost:,server,wait=off* > > However, when I attempt to use the -icount shift=0 option, the plugin > fails with the error "*Basic icount read*". I have attached a screenshot > of the error for your reference. > > error.png > > When I remove the -plugin argument from the command the OS boots up > perfectly, as expected. Command utilised in that context was somewhat > like *./build/qemu-system-x86_64 -m 2048M -smp 2 -boot c -nographic - > serial mon:stdio -nic tap,ifname=tap0,script=no,downscript=no -hda > debian11.qcow2 -icount shift=0 -qmp tcp:localhost:,server,wait=off* > > > I would greatly appreciate it if you could provide guidance on resolving > this issue. Specifically, I would like to know the cause of the error > and any potential solutions or workarounds that could be implemented to > successfully use the stoptrigger.c plugin with the -icount shift=0 option. > > > Regards > > Saanjh Sengupta >
Re: Issue with stoptrigger.c Plugin in QEMU Emulation
Hi Alex,
The below command line argument works perfectly.
./build/qemu-system-x86_64 -m 2048M -boot c -nographic -serial mon:stdio -nic
tap,ifname=tap0,script=no,downscript=no -hda debian11.qcow2 -icount shift=0
-plugin ./build/contrib/plugins/libstoptrigger.so,icount=90 -d plugin
-qmp tcp:localhost:,server,wait=off
If the QEMU command contains the -smp argument that is when the code crashes.
Would you let me know why the same happens and if there are any fixes towards
this problem?
Regards
Saanjh Sengupta
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
From: Alex Bennée
Sent: Friday, April 11, 2025 6:07:16 pm
To: Saanjh Sengupta
Cc: pierrick.bouv...@linaro.org ;
phi...@linaro.org ; pbonz...@redhat.com
; marcandre.lur...@redhat.com
; amir.gon...@neuroblade.ai
; qemu-devel@nongnu.org ;
aabhashswai...@gmail.com ; anian...@gmail.com
; guptapriyanshi...@gmail.com
; harshitgupta5...@gmail.com
Subject: Re: Issue with stoptrigger.c Plugin in QEMU Emulation
Saanjh Sengupta writes:
> Hi,
>
> I am writing to seek assistance with an issue I am experiencing while using
> the stoptrigger.c plugin in QEMU emulation. I am
> currently utilising the latest QEMU version, 9.2.92, and attempting to
> emulate the Debian 11 as the operating system.
>
> The command I am using to emulate QEMU is as follows:
> ./build/qemu-system-x86_64 -m 2048M -smp 2 -boot c -nographic -serial
> mon:stdio -nic
> tap,ifname=tap0,script=no,downscript=no -hda debian11.qcow2 -icount shift=0
> -plugin .
> /build/contrib/plugins/libstoptrigger.so,icount=90 -d plugin -qmp
> tcp:localhost:,server,wait=off
>
> However, when I attempt to use the -icount shift=0 option, the plugin fails
> with the error "Basic icount read". I have
> attached a screenshot of the error for your reference.
icount and libstoptrigger are independent of each other. You do not need
to enable icount to use libstoptrigger.
>
> error.png
>
>
> When I remove the -plugin argument from the command the OS boots up
> perfectly, as expected. Command utilised in that
> context was somewhat like ./build/qemu-system-x86_64 -m 2048M -smp 2 -boot c
> -nographic -serial mon:stdio -nic
> tap,ifname=tap0,script=no,downscript=no -hda debian11.qcow2 -icount shift=0
> -qmp
> tcp:localhost:,server,wait=off
>
> I would greatly appreciate it if you could provide guidance on resolving this
> issue. Specifically, I would like to know the cause
> of the error and any potential solutions or workarounds that could be
> implemented to successfully use the stoptrigger.c
> plugin with the -icount shift=0 option.
It's likely the instrumentation libstoptrigger does has changed the size
of some of the translation blocks leading to the error being triggered.
To know exactly what is going wrong we would need to see a backtrace of
the failure. The case:
if (!cpu->neg.can_do_io) {
error_report("Bad icount read");
exit(1);
}
is basically saying you are trying to read icount at a point its not a
known precise value. Any attempt to do a device access should trigger a
TB recompile so the device access is on the last translated instruction
of the block. However if a TCG helper queries time and its not the last
instruction in a block that would trigger it.
>
> Regards
>
> Saanjh Sengupta
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Re: Building QEMU as a Shared Library
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 Sent: Tuesday, February 25, 2025 6:29:44 AM To: Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Saanjh Sengupta 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 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 >
Re: Building QEMU as a Shared Library
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 Sent: Wednesday, March 5, 2025 5:20:38 AM To: Saanjh Sengupta ; Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Alex Bennée 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=100 -d plugin # execute no more than 1'000'000 instructions per second: $ ./build/qemu-system-x86_64 -plugin ./build/contrib/plugins/libips.so,ips=100 -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 > *Sent:* Tuesday, February 25, 2025 6:29:44 AM > *To:* Philippe Mathieu-Daudé ; Paolo Bonzini > ; Marc-André Lureau > *Cc:* amir.gon...@neuroblade.ai ; qemu- > de...@nongnu.org ; Saanjh Sengupta > > *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 >> >
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 Sent: Wednesday, March 5, 2025 5:20:38 AM To: Saanjh Sengupta ; Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Alex Bennée 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=100 -d plugin # execute no more than 1'000'000 instructions per second: $ ./build/qemu-system-x86_64 -plugin ./build/contrib/plugins/libips.so,ips=100 -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 > *Sent:* Tuesday, February 25, 2025 6:29:44 AM > *To:* Philippe Mathieu-Daudé ; Paolo Bonzini > ; Marc-André Lureau > *Cc:* amir.gon...@neuroblade.ai ; qemu- > de...@nongnu.org ; Saanjh Sengupta > > *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 >> >
Re: Building QEMU as a Shared Library
Hi, You can find the image attached. Regards Saanjh Sengupta From: Saanjh Sengupta Sent: Tuesday, March 11, 2025 3:20:48 PM To: Pierrick Bouvier ; Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Alex Bennée 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 Sent: Wednesday, March 5, 2025 5:20:38 AM To: Saanjh Sengupta ; Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Alex Bennée 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=100 -d plugin # execute no more than 1'000'000 instructions per second: $ ./build/qemu-system-x86_64 -plugin ./build/contrib/plugins/libips.so,ips=100 -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 > *Sent:* Tuesday, February 25, 2025 6:29:44 AM > *To:* Philippe Mathieu-Daudé ; Paolo Bonzini > ; Marc-André Lureau > *Cc:* amir.gon...@neuroblade.ai ; qemu- > de...@nongnu.org ; Saanjh Sengupta > > *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, P
Re: Building QEMU as a Shared Library
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 1 instructions executed after that it should pause and after some time it should then resume again execute till 2 instructions (because previously it executed till 1 and then it must execute till 2). How do I do this? How do I state the code to pause the qemu's emulation after 1 instructions? 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? Regards Saanjh Sengupta From: Pierrick Bouvier Sent: Wednesday, March 12, 2025 2:14:47 AM To: Saanjh Sengupta ; Philippe Mathieu-Daudé ; Paolo Bonzini ; Marc-André Lureau Cc: amir.gon...@neuroblade.ai ; qemu-devel@nongnu.org ; Alex Bennée 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 > *Sent:* Wednesday, March 5, 2025 5:20:38 AM > *To:* Saanjh Sengupta ; Philippe Mathieu- > Daudé ; Paolo Bonzini ; Marc- > André Lureau > *Cc:* amir.gon...@neuroblade.ai ; qemu- > de...@nongnu.org ; Alex Bennée > > *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=100 -d plugin > > # execute no more than 1'000'000 instructions per second: > $ ./build/qemu-system-x86_64 -plugin > ./build/contrib/plugins/libips.so,ips=100 -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
Re: Building QEMU as a Shared Library
Hi,
What we are trying to achieve is that the QEMU should run for a particular
number of instructions, let's say for example 1 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).
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
Sent: Wednesday, March 12, 2025 11:50:23 am
To: Saanjh Sengupta ; Philippe Mathieu-Daudé
; Paolo Bonzini ; Marc-André Lureau
Cc: amir.gon...@neuroblade.ai ;
qemu-devel@nongnu.org ; Alex Bennée
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 1 instructions executed after that it should
> pause and after some time it should then resume again execute till 2
> instructions (because previously it executed till 1 and then it must
> execute till 2). How do I do this? How do I state the code to pause
> the qemu's emulation after 1 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
> *Sent:* Wednesday, March 12, 2025 2:14:47 AM
> *To:* Saanjh Sengupta ; Philippe Mathieu-
> Daudé ; Paolo Bonzini ; Marc-
> André Lureau
> *Cc:* amir.gon...@neuroblade.ai ; qemu-
> de...@nongnu.org ; Alex Bennée
>
> *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
Building QEMU as a Shared Library
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
