Re: [RFC 0/5] Introduce dynamic tracer using Livepatch

[Ryo Takakura <takakura@xxxxxxxxxxxxx>]

Hi Andrew!

On Mon, 26 Oct 2026 09:29:04 +0000, Andrew Cooper wrote:
>On 23/10/2026 5:48 am, Ryo Takakura wrote:
>> # Configuration
>> In addition to Livepatch and HypFS:
>>
>> CONFIG_LIVEPATCH=y
>> CONFIG_HYPFS=y
>>
>> Enable the following configs:
>>
>> CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY=y
>> or
>> CONFIG_X86_PATCHABLE_FUNCTION_ENTRY=y
>>
>> CONFIG_LIVEPATCH_TRACER=y
>
>
>This ends up having two almost-identical symbols, depending on
>architecture, where really this is a common piece of functionality.  It
>also conflates several different tasks.

Thank you for the feedback in detail. It was very helpful.
The suggested config layout makes much more sense.

>I think what you want is something like this:
>
>In xen/Kconfig, create CC_HAS_PATCHABLE_FUNCTION_ENTRY which performs
>the $(cc-option,-fpatchable-function-entry=0,0) check.

Understood.

>You are also going to need a GCC_PATCHABLE_FUNCTION_ENTRY_BROKEN symbol,
>because of https://godbolt.org/z/sde4faxaz.  See the ASM_GOTO_OUTPUT for
>another example of this pattern.  Just use a plain version check rather
>than tying it to XEN_IBT; this is a new feature and people wanting to
>use it can use a new enough compiler, and it avoids variability
>depending on other options.

I didn't know about the compiler behaviour. Thank you for the detail.
I'll make sure to check the acceptable compiler version and add a version
check as you suggest.

>You also want a HAS_PATCHABLE_FUNCTION_ENTRY in xen/common/Kconfig,
>which you select from the main config x86/ARM/etc in each patch where
>you add the architecture support.

Understood.

>You want the single visible entry LIVEPATCH_TRACER which depends on
>HAS_PATCHABLE_FUNCTION_ENTRY and CC_HAS_PATCHABLE_FUNCTION_ENTRY.  You
>want to make the text architecture-neutral.  Instead of the exact number
>of NOPs, just say "reserves space" which will be entirely fine; the
>target audience for Kconfig text is sysadmins/distro integrators, not
>developers.

Understood.
And I'll revise the feature description as well.

>Finally, you want PATCHABLE_FUNCTION_ENTRY which is selected by
>LIVEPATCH_TRACER, which triggers the Makefile changes.

Understood.

>As a general note, you don't need "default n" lines in Kconfig.  That is
>the default.

I see. I'll make sure to remove them.

>All together, this separates "can the compiler do it?" from "does the
>user want it?" from "what to do when the user wants it".

Understood!
I'll make those changes in the next version.

>Separately, you have a number of MISRA violations which you're
>introducing in your series.  I see you've got cf_check, which suggests
>you have built in GitlabCI.  Have you also run Eclair?

Thank you for pointing this out.
My apologies for the violations. I wasn't aware of the tests
and haven't run either of them. I added the cf_check following
the existing code that I referred to when preparing this series.
I'll make sure to run those tests before sending next version.

Sincerely,
Ryo Takakura