All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Florian Hofhammer <florian.hofhammer@epfl.ch>
Cc: pierrick.bouvier@linaro.org,  qemu-devel@nongnu.org,
	richard.henderson@linaro.org,  laurent@vivier.eu,
	 imp@bsdimp.com
Subject: Re: New capabilities for plugins
Date: Tue, 05 Aug 2025 15:16:26 +0100	[thread overview]
Message-ID: <874iul26rp.fsf@draig.linaro.org> (raw)
In-Reply-To: <1016eeb7-57d8-4d80-ba25-42cda2d63b0f@epfl.ch> (Florian Hofhammer's message of "Tue, 5 Aug 2025 15:22:35 +0200")

Florian Hofhammer <florian.hofhammer@epfl.ch> writes:

> Hi Alex, hi Pierrick,
>
> I'm taking the freedom to reply to both of you at the same time, I
> hope you don't mind :)
>
> On 04/08/2025 18:05, Alex Bennée wrote:
>>> I was wondering whether the QEMU community would be open to extending
>>> the plugin API so that a plugin can fully emulate a syscall without
>>> the original syscall being executed by QEMU.
>>
<snip>
>> Another option would be to have a set_pc function that would restart
>> the execution at new PC. Then the vcpu_syscall_cb callback could set
>> the PC to post the syscall with whatever state it wants to set up.
>
> Such a set_pc functionality is already covered with the register write
> API, as long as I have a handle to the PC register, right? Please do
> correct me if I'm misunderstanding something here!

Ahh we should make that clear. It requires special handling as the PC
isn't automatically updated every instruction. For analysis this isn't a
problem as the TB itself knows the vaddr of each instruction so can save
it if it wants.

Currently if you write to the PC it won't change flow - and it will
likely be reset as we exit the syscall.

c.f. https://gitlab.com/qemu-project/qemu/-/issues/2208

>
> Thanks for your input,
> Florian

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  reply	other threads:[~2025-08-05 14:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04 10:14 New capabilities for plugins Florian Hofhammer
2025-08-04 16:05 ` Alex Bennée
2025-08-05 13:22   ` Florian Hofhammer
2025-08-05 14:16     ` Alex Bennée [this message]
2025-08-05 14:30       ` Florian Hofhammer
2025-08-05 15:30         ` Alex Bennée
2025-08-21 16:02           ` Florian Hofhammer
2025-08-22  8:44             ` Alex Bennée
2025-08-26 14:37               ` Florian Hofhammer
2025-08-05 16:12   ` Daniel P. Berrangé
2025-08-21 15:58     ` Florian Hofhammer
2025-08-22  8:41       ` Alex Bennée
2025-08-04 17:01 ` Pierrick Bouvier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874iul26rp.fsf@draig.linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=florian.hofhammer@epfl.ch \
    --cc=imp@bsdimp.com \
    --cc=laurent@vivier.eu \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.