linux-kernel - Re: [PATCH v3] acpi/processor: fix evaluating

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZBL2yosC4LWGdjsn@Air-de-Roger>
Date:   Thu, 16 Mar 2023 12:00:26 +0100
From:   Roger Pau Monné <roger.pau@...rix.com>
To:     Jan Beulich <jbeulich@...e.com>
Cc:     xen-devel@...ts.xenproject.org, josef@...rland.se,
        Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
        Alex Chiang <achiang@...com>, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] acpi/processor: fix evaluating _PDC method when
 running as Xen dom0

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.