From: Grygorii Strashko <grygorii_strashko@epam.com>

Functions:
 - vlapic_apicv_write()
 - vlapic_set_ppr()
are used by Intel VMX code only, so move them under CONFIG_INTEL_VMX ifdef.

Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
---
 xen/arch/x86/hvm/vlapic.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 98a54efc7bdc..4121285daef8 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -215,6 +215,7 @@ static uint32_t vlapic_get_ppr(const struct vlapic *vlapic)
     return ppr;
 }
 
+#ifdef CONFIG_INTEL_VMX
 uint32_t vlapic_set_ppr(struct vlapic *vlapic)
 {
    uint32_t ppr = vlapic_get_ppr(vlapic);
@@ -222,6 +223,7 @@ uint32_t vlapic_set_ppr(struct vlapic *vlapic)
    vlapic_set_reg(vlapic, APIC_PROCPRI, ppr);
    return ppr;
 }
+#endif
 
 static bool vlapic_match_logical_addr(const struct vlapic *vlapic, uint32_t mda)
 {
@@ -984,6 +986,7 @@ static int cf_check vlapic_mmio_write(
     return X86EMUL_OKAY;
 }
 
+#ifdef CONFIG_INTEL_VMX
 int vlapic_apicv_write(struct vcpu *v, unsigned int offset)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1002,6 +1005,7 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int offset)
 
     return X86EMUL_OKAY;
 }
+#endif
 
 int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr, uint64_t val)
 {
-- 
2.34.1

On 23/10/2025 4:20 pm, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@epam.com>
>
> Functions:
>  - vlapic_apicv_write()
>  - vlapic_set_ppr()
> are used by Intel VMX code only, so move them under CONFIG_INTEL_VMX ifdef.
>
> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>

Yes and no.  Yes right now, but this is needed for AMD AVIC, which I
understand is one one of the plans.

Throwing #ifdef's around like this in common files is fragile and will
lead to a randconfig nightmare.

There is an alternative which ought to work.  Turning on
-ffunction-sections (we already have this for livepatching), and
implementing link time --gc-sections (new work).

That way, the compiler/linker simply drops functions that are not
referenced in the final binary.

Personally I think it will be far nicer and more scalable than the
#ifdefary, (not to mention far easier - it gets rid of everything
unreferenced with one fell swoop).

Thoughts?

~Andrew

On 23.10.2025 17:30, Andrew Cooper wrote:
> On 23/10/2025 4:20 pm, Grygorii Strashko wrote:
>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>
>> Functions:
>>  - vlapic_apicv_write()
>>  - vlapic_set_ppr()
>> are used by Intel VMX code only, so move them under CONFIG_INTEL_VMX ifdef.
>>
>> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
> 
> Yes and no.  Yes right now, but this is needed for AMD AVIC, which I
> understand is one one of the plans.
> 
> Throwing #ifdef's around like this in common files is fragile and will
> lead to a randconfig nightmare.
> 
> There is an alternative which ought to work.  Turning on
> -ffunction-sections (we already have this for livepatching), and
> implementing link time --gc-sections (new work).
> 
> That way, the compiler/linker simply drops functions that are not
> referenced in the final binary.
> 
> Personally I think it will be far nicer and more scalable than the
> #ifdefary, (not to mention far easier - it gets rid of everything
> unreferenced with one fell swoop).
> 
> Thoughts?

We'd need to have Misra buy-off on such an approach. I'm not sure if Eclair's
scanning would take --gc-sections effects into account.

Jan

On 2025-10-23 17:37, Jan Beulich wrote:
> On 23.10.2025 17:30, Andrew Cooper wrote:
>> On 23/10/2025 4:20 pm, Grygorii Strashko wrote:
>>> From: Grygorii Strashko <grygorii_strashko@epam.com>
>>> 
>>> Functions:
>>>  - vlapic_apicv_write()
>>>  - vlapic_set_ppr()
>>> are used by Intel VMX code only, so move them under CONFIG_INTEL_VMX 
>>> ifdef.
>>> 
>>> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
>> 
>> Yes and no.  Yes right now, but this is needed for AMD AVIC, which I
>> understand is one one of the plans.
>> 
>> Throwing #ifdef's around like this in common files is fragile and will
>> lead to a randconfig nightmare.
>> 
>> There is an alternative which ought to work.  Turning on
>> -ffunction-sections (we already have this for livepatching), and
>> implementing link time --gc-sections (new work).
>> 
>> That way, the compiler/linker simply drops functions that are not
>> referenced in the final binary.
>> 
>> Personally I think it will be far nicer and more scalable than the
>> #ifdefary, (not to mention far easier - it gets rid of everything
>> unreferenced with one fell swoop).
>> 
>> Thoughts?
> 
> We'd need to have Misra buy-off on such an approach. I'm not sure if 
> Eclair's
> scanning would take --gc-sections effects into account.
> 
> Jan

Currently it doesn't, but we do have plans to implement something 
similar in the future. What might help in the meantime is using ECLAIR 
Code Scout to tag and hide unused program entities. Not sure if the 
mailing list is the best place to present the idea, but I'd be happy to 
illustrate it in a community call or something similar.

Basically the idea is that if something is possibly reachable it will be 
captured by Code Scout, and then a second analysis can use that input to 
selectively find and tag (e.g. "unused") the definitely unreachable 
entities. This could be limited to functions for instance, and then when 
the rule for unreachable code finds something unreachable, it can be 
silenced selectively for tagged functions, because we know that these 
are unreachable due to that reason. It's not 1:1 with the --gc-sections 
behaviour, but realistically it's much closer without resorting to 
#ifdefary all over the place.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253