[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1042d77-eb5a-6577-9ec6-e6a7997f15d7@suse.com>
Date: Mon, 21 Nov 2022 15:02:30 +0100
From: Jan Beulich <jbeulich@...e.com>
To: Roger Pau Monne <roger.pau@...rix.com>
Cc: xen-devel@...ts.xenproject.org, 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>, Alex Chiang <achiang@...com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] acpi/processor: fix evaluating _PDC method when
running as Xen dom0
On 21.11.2022 11:21, Roger Pau Monne wrote:
> @@ -47,6 +49,15 @@ static bool __init processor_physically_present(acpi_handle handle)
> return false;
> }
>
> + if (xen_initial_domain())
> + /*
> + * When running as a Xen dom0 the number of processors Linux
> + * sees can be different from the real number of processors on
> + * the system, and we still need to execute _PDC for all of
> + * them.
> + */
> + return xen_processor_present(acpi_id);
> +
> type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
> cpuid = acpi_get_cpuid(handle, type, acpi_id);
We had to deal with this in our XenoLinux forward ports as well, but at
the time it appeared upstream I decided to make use of acpi_get_apicid()
(which meanwhile was renamed to acpi_get_phys_id()). Wouldn't than be an
option, eliminating the need for a Xen-specific new function?
Jan
Powered by blists - more mailing lists