On Thu, Mar 16, 2023 at 11:45:47AM +0100, Jan Beulich wrote:
> On 16.03.2023 11:32, Roger Pau Monne wrote:
> > --- a/arch/x86/include/asm/xen/hypervisor.h
> > +++ b/arch/x86/include/asm/xen/hypervisor.h
> > @@ -63,4 +63,14 @@ void __init xen_pvh_init(struct boot_params *boot_params);
> > void __init mem_map_via_hcall(struct boot_params *boot_params_p);
> > #endif
> >
> > +#ifdef CONFIG_XEN_DOM0
>
> Shouldn't you also check CONFIG_X86 here, seeing the condition for when
> pcpu.c would be built?
It's in a x86 specific header, so that's enough I think? (note the
path of the header)
> Additionally CONFIG_ACPI may want checking, which
> - taken together - would amount to checking CONFIG_XEN_ACPI. (For which
> in turn I find odd that it will also be engaged when !DOM0.)
Hm, is it worth making the acpi_id field in struct pcpu or helper
conditional to CONFIG_ACPI? It's just data fetched from Xen so it
doesn't depend on any of the ACPI functionality in Linux.
IMO I don't think it's worth the extra ifdefs.
> > @@ -381,3 +383,20 @@ static int __init xen_pcpu_init(void)
> > return ret;
> > }
> > arch_initcall(xen_pcpu_init);
> > +
> > +bool __init xen_processor_present(uint32_t acpi_id)
> > +{
> > + struct pcpu *pcpu;
> > + bool online = false;
> > +
> > + mutex_lock(&xen_pcpu_lock);
> > + list_for_each_entry(pcpu, &xen_pcpus, list)
> > + if (pcpu->acpi_id == acpi_id) {
> > + online = pcpu->flags & XEN_PCPU_FLAGS_ONLINE;
> > + break;
> > + }
> > +
> > + mutex_unlock(&xen_pcpu_lock);
> > +
> > + return online;
> > +}
>
> Since it is neither natural nor obvious that this function takes an
> ACPI ID as input (could in particular also be an APIC ID), would that
> perhaps better be expressed in its name?
I did wonder the same, but convinced myself that the parameter name
being `acpi_id` was enough of a hint that the function takes an ACPI
ID.
Thanks, Roger.
