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

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Jul 01, 2026 at 06:09:08PM +0900, Ryo Takakura wrote:
> Hi Roger and Andrew,
> 
> 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.

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.

Thanks, Roger.