Le 12/11/2025 à 16:25, Alejandro Vallejo a écrit : > A couple of branches rely on PV being the "else" branch, making it > be compiled even when PV support is not itself compiled-in. > > Add a explicit conditional on CONFIG_PV in those cases to remove the > code in !CONFIG_PV builds. > > Not a functional change. > > Signed-off-by: Alejandro Vallejo <[email protected]> > --- > xen/arch/x86/cpuid.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c > index b63a82dd38..2e24c84708 100644 > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -297,7 +297,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, > if ( v->arch.hvm.guest_cr[4] & X86_CR4_OSXSAVE ) > res->c |= cpufeat_mask(X86_FEATURE_OSXSAVE); > } > - else /* PV domain */ > + else if ( IS_ENABLED(CONFIG_PV) ) > { > regs = guest_cpu_user_regs(); > > @@ -509,7 +509,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, > if ( !hap_enabled(d) && !hvm_pae_enabled(v) ) > res->d &= ~cpufeat_mask(X86_FEATURE_PSE36); > } > - else /* PV domain */ > + else if ( IS_ENABLED(CONFIG_PV) ) > { > /* > * MTRR used to unconditionally leak into PV guests. They > cannot
I don't like having IS_ENABLED(CONFIG_PV) here, but I don't think of a better solution as using e.g is_pv_domain isn't really better as it would make us evaluate d->options twice. That said, Reviewed-by: Teddy Astie <[email protected]> Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
