[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bc25b31f7af527511599145954615a0d0a6078cf.camel@linux.intel.com>
Date: Wed, 09 Nov 2022 08:15:19 -0800
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Roger Pau Monne <roger.pau@...rix.com>,
linux-kernel@...r.kernel.org
Cc: Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
David E Box <david.e.box@...el.com>,
Hans de Goede <hdegoede@...hat.com>,
Mark Gross <markgross@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] platform/x86: don't unconditionally attach Intel PMC
when virtualized
On Wed, 2022-11-09 at 16:16 +0100, Roger Pau Monne wrote:
> The current logic in the Intel PMC driver will forcefully attach it
> when detecting any CPU on the intel_pmc_core_platform_ids array,
> even if the matching ACPI device is not present.
>
> There's no checking in pmc_core_probe() to assert that the PMC device
> is present, and hence on virtualized environments the PMC device
> probes successfully, even if the underlying registers are not present.
> Previous to 21ae43570940 the driver would check for the presence of a
> specific PCI device, and that prevented the driver from attaching when
> running virtualized.
Yeah, that PCI device was short lived. It was available on Skylake/Kabylake but
then removed on future generations. When this happened we changed the driver to
use ACPI binding instead. But there were several generations of ChromeOS/coreboo
t platforms (listed in intel_pmc_core_platform_ids) that did not have the ACPI
device present in their firmware. This file exists specifically to support those
platforms and uses the forced binding because (given that there's actual
silicon) we know the PMC will be there.
>
> Fix by only forcefully attaching the PMC device when not running
> virtualized. Note that virtualized platforms can still get the device
> to load if the appropriate ACPI device is present on the tables
> provided to the VM.
>
> Make an exception for the Xen initial domain, which does have full
> hardware access, and hence can attach to the PMC if present.
>
> Fixes: 21ae43570940 ('platform/x86: intel_pmc_core: Substitute PCI with CPUID
> enumeration')
> Signed-off-by: Roger Pau Monné <roger.pau@...rix.com>
> Cc: Rajneesh Bhardwaj <irenic.rajneesh@...il.com>
> Cc: David E Box <david.e.box@...el.com>
> Cc: Hans de Goede <hdegoede@...hat.com>
> Cc: Mark Gross <markgross@...nel.org>
> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> Cc: platform-driver-x86@...r.kernel.org
> ---
> drivers/platform/x86/intel/pmc/pltdrv.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/platform/x86/intel/pmc/pltdrv.c
> b/drivers/platform/x86/intel/pmc/pltdrv.c
> index 15ca8afdd973..e284fd34ffdf 100644
> --- a/drivers/platform/x86/intel/pmc/pltdrv.c
> +++ b/drivers/platform/x86/intel/pmc/pltdrv.c
> @@ -18,6 +18,8 @@
> #include <asm/cpu_device_id.h>
> #include <asm/intel-family.h>
>
> +#include <xen/xen.h>
> +
> static void intel_pmc_core_release(struct device *dev)
> {
> kfree(dev);
> @@ -53,6 +55,14 @@ static int __init pmc_core_platform_init(void)
> if (acpi_dev_present("INT33A1", NULL, -1))
> return -ENODEV;
>
> + /*
> + * Skip forcefully attaching the device for VMs. Make an exception for
> + * Xen dom0, which does have full hardware access.
> + */
> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR) &&
> + !xen_initial_domain())
> + return -ENODEV;
> +
> if (!x86_match_cpu(intel_pmc_core_platform_ids))
> return -ENODEV;
>
Acked-by: David E. Box <david.e.box@...ux.intel.com>
Powered by blists - more mailing lists