Re: [RFC] xen/arm64: livepatch: enable attaching callbacks

[Ryo Takakura <takakura@xxxxxxxxxxxxx>]

On Wed, 1 Jul 2026 15:50:59 +0200, Roger Pau Monné wrote:
>On Wed, Jul 01, 2026 at 06:09:08PM +0900, Ryo Takakura wrote:
>> On Tue, 30 Jun 2026 08:47:14 +0000, Roger Pau Monné wrote:
>> >On Mon, Jun 29, 2026 at 11:01:28AM +0900, Ryo Takakura wrote:
>> >> Linux ftrace allows registering callbacks which is useful
>> >> for debugging and tracing events. On Linux, it is done by
>> >> reserving function entry points at compile time which can
>> >> later be patched to branch to a trampoline.
>> >> 
>> >> This patch implements similar callback feature, but with
>> >> different approach using existing livepatch infrastructure.
>> >> Instead of reserving function entry points at compile time,
>> >> the traced function will be livepatched so that it branches
>> >> to the trampoline.
>> >
>> >While this is an interesting usage of the livepatch logic in new ways,
>> >may I ask why not do as Linux and add an empty function preamble that
>> >can be replaced at run-time with calls to hooks?
>> >
>> >You could still re-use most of the livepatch logic for handling the
>> >addition of the hook calls, but it would be nicer in that we won't
>> >need to move the original function.
>> 
>> I agree that we can reuse a lot of livepatch logic.
>> 
>> >> The role of the trampoline(illustrated below) is to preserve
>> >> the context while jumping to the tracer function, and return
>> >> back to the traced function with its context restored.
>> >
>> >Alternatively - why not use livepatch-build-tools against a build with
>> >the added hooks to generate a proper livepatch?  This looks a bit
>> >fragile to me (see the question from Andrew about fixing up
>> >instruction pointer relative references).
>> 
>> Yes, I think proper livepatching would still be preferred
>> given all the concerns Andrew and Roger raised.
>> 
>> >On x86 at least we would also need to adjust the bug frames and
>> >exception table contents, and the contents of the symbol table to
>> >account for the function being moved.
>> >
>> >IOW: it looks like overall this is a lot more work than possibly
>> >reserving a function preamble to add hook calls?
>> 
>> Yes, I agree.
>> (I wasn't aware of this additional work when I replied
>> to Andrew yesterday, thanks!)
>> 
>> And if I were to summarize the discussion so far, assuming we
>> still want to add a tracing-feature, I think we are in agreement
>> adding an empty function preamble like Linux.
>> (I personally would still like to see a framework on Xen
>> that is more convenient and tracing-friendly which can be used
>> reliably at the same time)
>> 
>> If this sounds reasonable, I will try preparing one based on
>> the feedbacks I was given so far:
>> - Use of Linux-like reserved function preamble
>> - Use of __attribute__((no_caller_saved_registers))
>> - Split replacement and preamble-hook handling in common code
>> 
>> Let me know your thoughts!
>
>I think the above approach is easier to implement, and more reliable
>than the current proposal.

Good!

>Do you also have the intention to integrate this with existing tracing
>tools used by Linux or other OSes?  That would be very useful IMO.

Although I don't have anything specific in mind yet,
I also hope for more tools to be integrated in the future :-)

Sincerely,
Ryo Takakura