Re: [PATCH v3] acpi/processor: fix evaluating _PDC method when running as Xen dom0

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

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.