[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] acpi/processor: sanitize _OSC/_PDC capabilities for Xen dom0


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
  • From: "Wilczynski, Michal" <michal.wilczynski@xxxxxxxxx>
  • Date: Fri, 13 Oct 2023 18:13:54 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OKGOPoYc+Vmy8Wkj5yd8LNwmF9fv8cA2cWQwjipk08w=; b=TEaZj87rNTeFotkgKzTXBhLP0SHJAERodph4IY+JclhUFnSptxp5IEamHVTvZxiLGCtxdhQl7RtJ+s7pIYGrLMRVsrTVZTAwdACLrRAqsFY/5NwmPqx2KIP44Ok1EIC2U1uDcdPx1AlVWNXBbzgTRuFT/Hs+mkLBWmTbbBTHg9pEZQvjr6Xw980p2qFRQ14Z/CUzXBRXh4OVr2FtvODr1HRMQig93Ebh7RcDp5FeXeYt1olC/l9AAOGdC3rFiyW2r9XZuPPqP0rAt32Kx9LJYbU64wFJUo/2cI2Id03dCLx9WN3X/vNntgdi7eRX7IZMhO56H6cST9n5O8cATCP4OA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PW/G21K3yVgpHL7XEWC0CS1n16U8mrmk7kVIOi7ZlRwmiAOHyxn3BvdAA33Kz7Adaj0PxgmFUB92DvpynaQHzWwN8+cmzqDXtGXl7R1Eh/l+E7CT+UCbg3yk7nRY+K11n7KoUIlxZmlbts/7KAPw0Irg7sk+9EmFfxgAM2GRupkTTWvWmETTmzxfJ0h+gmxNR0CKdRuxbZaowapqPePQ3GjqIKjLJqYV9mKCFP9Yk+x4Dx5x6C+E72d4CPx7COI1Q7/e1AzRPWT+rD/xp8wURO0bY5lWp880/mSNn6QOKwL2RscwNRUaMfrNCThMB9LCgWneYNJbwdUmvergJgzI6w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, <stable@xxxxxxxxxxxxxxx>, "Thomas Gleixner" <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, "Borislav Petkov" <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, <x86@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 13 Oct 2023 16:17:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi,

On 10/10/2023 7:39 PM, Jason Andryuk wrote:
> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
>
> The Processor capability bits notify ACPI of the OS capabilities, and
> so ACPI can adjust the return of other Processor methods taking the OS
> capabilities into account.
>
> When Linux is running as a Xen dom0, the hypervisor is the entity
> in charge of processor power management, and hence Xen needs to make
> sure the capabilities reported by _OSC/_PDC match the capabilities of
> the driver in Xen.
>
> Introduce a small helper to sanitize the buffer when running as Xen
> dom0.
>
> When Xen supports HWP, this serves as the equivalent of commit
> a21211672c9a ("ACPI / processor: Request native thermal interrupt
> handling via _OSC") to avoid SMM crashes.  Xen will set bit
> ACPI_PROC_CAP_COLLAB_PROC_PERF (bit 12) in the capability bits and the
> _OSC/_PDC call will apply it.
>
> [ jandryuk: Mention Xen HWP's need.  Support _OSC & _PDC ]
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Jason Andryuk <jandryuk@xxxxxxxxx>
> ---
> v3:
> Move xen_sanitize_pdc() call to arch_acpi_set_proc_cap_bits() to cover
> _OSC and _PDC.
> drivers/xen/pcpu.c is CONFIG_DOM0 && CONFIG_X86
>
> v2:
> Move local variables in acpi_processor_eval_pdc() to reuse in both conditions.
> ---
>  arch/x86/include/asm/acpi.h           | 13 +++++++++++++
>  arch/x86/include/asm/xen/hypervisor.h |  9 +++++++++
>  drivers/xen/pcpu.c                    | 21 +++++++++++++++++++++
>  3 files changed, 43 insertions(+)
>
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index c8a7fc23f63c..cc8d1669d6e8 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -16,6 +16,9 @@
>  #include <asm/x86_init.h>
>  #include <asm/cpufeature.h>
>  #include <asm/irq_vectors.h>
> +#include <asm/xen/hypervisor.h>
> +
> +#include <xen/xen.h>
>  
>  #ifdef CONFIG_ACPI_APEI
>  # include <asm/pgtable_types.h>
> @@ -127,6 +130,16 @@ static inline void arch_acpi_set_proc_cap_bits(u32 *cap)
>       if (!cpu_has(c, X86_FEATURE_MWAIT) ||
>           boot_option_idle_override == IDLE_NOMWAIT)
>               *cap &= ~(ACPI_PROC_CAP_C_C1_FFH | ACPI_PROC_CAP_C_C2C3_FFH);
> +
> +     if (xen_initial_domain()) {
> +             /*
> +              * When Linux is running as Xen dom0, the hypervisor is the
> +              * entity in charge of the processor power management, and so
> +              * Xen needs to check the OS capabilities reported in the _PDC

I would argue the phrasing here is unfortunate - it's not really _PDC buffer 
anymore,
it's more processor capabilities buffer [1]. Your phrasing would indicate that 
this
buffer is somehow _PDC specific.

BTW this file is x86 specific code - are you sure it's appropriate to involve 
Xen
hypervisor here ? I understand this case if x86 specific, but still.

> +              * buffer matches what the hypervisor driver supports.
> +              */
> +             xen_sanitize_pdc(cap);

Same here as in [1], I would call this function xen_sanitize_proc_cap_buffer(),
or something along those lines for better readability and correctness.

> +     }
>  }
>  
>  static inline bool acpi_has_cpu_in_madt(void)
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index 7048dfacc04b..c6c2f174fa30 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -100,4 +100,13 @@ static inline void leave_lazy(enum xen_lazy_mode mode)
>  
>  enum xen_lazy_mode xen_get_lazy_mode(void);
>  
> +#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI)
> +void xen_sanitize_pdc(uint32_t *buf);
> +#else
> +static inline void xen_sanitize_pdc(uint32_t *buf)
> +{
> +     BUG();
> +}
> +#endif
> +
>  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> index b3e3d1bb37f3..859bb6027105 100644
> --- a/drivers/xen/pcpu.c
> +++ b/drivers/xen/pcpu.c
> @@ -47,6 +47,9 @@
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  
> +#ifdef CONFIG_ACPI
> +#include <acpi/processor.h>
> +#endif
>  
>  /*
>   * @cpu_id: Xen physical cpu logic number
> @@ -400,4 +403,22 @@ bool __init xen_processor_present(uint32_t acpi_id)
>  
>       return online;
>  }
> +
> +void xen_sanitize_pdc(uint32_t *cap)
> +{
> +     struct xen_platform_op op = {
> +             .cmd                    = XENPF_set_processor_pminfo,
> +             .u.set_pminfo.id        = -1,
> +             .u.set_pminfo.type      = XEN_PM_PDC,

It would probably be best to rename this constant as well so it's
not misleading.

> +     };
> +     u32 buf[3] = { ACPI_PDC_REVISION_ID, 1, *cap };
> +     int ret;
> +
> +     set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
> +     ret = HYPERVISOR_platform_op(&op);
> +     if (ret)
> +             pr_info("sanitize of _PDC buffer bits from Xen failed: %d\n",
> +                     ret);

Shouldn't an error be pr_err ?

> +     *cap = buf[2];
> +}
>  #endif


Regards,
Michał




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.