2019-06-01 01:08:55 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2010-05-06 12:08:41 -07:00
|
|
|
/*
|
|
|
|
|
* HyperV Detection code.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2010, Novell, Inc.
|
|
|
|
|
* Author : K. Y. Srinivasan <ksrinivasan@novell.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2011-09-07 15:25:10 -07:00
|
|
|
#include <linux/time.h>
|
|
|
|
|
#include <linux/clocksource.h>
|
2016-07-13 17:18:56 -07:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/export.h>
|
2013-02-03 18:22:39 -07:00
|
|
|
#include <linux/hardirq.h>
|
2013-09-30 08:28:52 -07:00
|
|
|
#include <linux/efi.h>
|
2013-02-03 18:22:39 -07:00
|
|
|
#include <linux/interrupt.h>
|
2014-02-23 14:40:22 -07:00
|
|
|
#include <linux/irq.h>
|
2015-08-01 16:08:07 -07:00
|
|
|
#include <linux/kexec.h>
|
2019-06-30 21:25:56 -07:00
|
|
|
#include <linux/random.h>
|
2010-05-06 12:08:41 -07:00
|
|
|
#include <asm/processor.h>
|
2010-05-07 16:57:28 -07:00
|
|
|
#include <asm/hypervisor.h>
|
2018-03-20 07:02:05 -07:00
|
|
|
#include <asm/hyperv-tlfs.h>
|
2010-05-06 12:08:41 -07:00
|
|
|
#include <asm/mshyperv.h>
|
2013-02-03 18:22:39 -07:00
|
|
|
#include <asm/desc.h>
|
2020-05-21 13:05:43 -07:00
|
|
|
#include <asm/idtentry.h>
|
2013-02-03 18:22:39 -07:00
|
|
|
#include <asm/irq_regs.h>
|
2013-09-30 08:28:52 -07:00
|
|
|
#include <asm/i8259.h>
|
2013-10-11 16:07:31 -07:00
|
|
|
#include <asm/apic.h>
|
2014-02-27 20:30:29 -07:00
|
|
|
#include <asm/timer.h>
|
2015-08-01 16:08:07 -07:00
|
|
|
#include <asm/reboot.h>
|
2016-12-02 03:07:20 -07:00
|
|
|
#include <asm/nmi.h>
|
2019-08-14 05:32:16 -07:00
|
|
|
#include <clocksource/hyperv_timer.h>
|
2021-02-03 08:04:29 -07:00
|
|
|
#include <asm/numa.h>
|
2023-08-18 03:29:18 -07:00
|
|
|
#include <asm/svm.h>
|
2010-05-06 12:08:41 -07:00
|
|
|
|
2021-02-03 08:04:21 -07:00
|
|
|
/* Is Linux running as the root partition? */
|
|
|
|
|
bool hv_root_partition;
|
2023-01-02 00:12:51 -07:00
|
|
|
/* Is Linux running on nested Microsoft Hypervisor */
|
|
|
|
|
bool hv_nested;
|
2010-05-07 16:57:28 -07:00
|
|
|
struct ms_hyperv_info ms_hyperv;
|
2010-05-06 12:08:41 -07:00
|
|
|
|
x86/hyperv: Introduce a global variable hyperv_paravisor_present
The new variable hyperv_paravisor_present is set only when the VM
is a SNP/TDX VM with the paravisor running: see ms_hyperv_init_platform().
We introduce hyperv_paravisor_present because we can not use
ms_hyperv.paravisor_present in arch/x86/include/asm/mshyperv.h:
struct ms_hyperv_info is defined in include/asm-generic/mshyperv.h, which
is included at the end of arch/x86/include/asm/mshyperv.h, but at the
beginning of arch/x86/include/asm/mshyperv.h, we would already need to use
struct ms_hyperv_info in hv_do_hypercall().
We use hyperv_paravisor_present only in include/asm-generic/mshyperv.h,
and use ms_hyperv.paravisor_present elsewhere. In the future, we'll
introduce a hypercall function structure for different VM types, and
at boot time, the right function pointers would be written into the
structure so that runtime testing of TDX vs. SNP vs. normal will be
avoided and hyperv_paravisor_present will no longer be needed.
Call hv_vtom_init() when it's a VBS VM or when ms_hyperv.paravisor_present
is true, i.e. the VM is a SNP VM or TDX VM with the paravisor.
Enhance hv_vtom_init() for a TDX VM with the paravisor.
In hv_common_cpu_init(), don't decrypt the hyperv_pcpu_input_arg
for a TDX VM with the paravisor, just like we don't decrypt the page
for a SNP VM with the paravisor.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20230824080712.30327-7-decui@microsoft.com
2023-08-24 01:07:08 -07:00
|
|
|
/* Used in modules via hv_do_hypercall(): see arch/x86/include/asm/mshyperv.h */
|
|
|
|
|
bool hyperv_paravisor_present __ro_after_init;
|
|
|
|
|
EXPORT_SYMBOL_GPL(hyperv_paravisor_present);
|
|
|
|
|
|
2014-03-04 15:39:58 -07:00
|
|
|
#if IS_ENABLED(CONFIG_HYPERV)
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
static inline unsigned int hv_get_nested_msr(unsigned int reg)
|
2023-01-02 00:12:52 -07:00
|
|
|
{
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
if (hv_is_sint_msr(reg))
|
|
|
|
|
return reg - HV_X64_MSR_SINT0 + HV_X64_MSR_NESTED_SINT0;
|
2023-02-09 15:02:52 -07:00
|
|
|
|
2023-01-02 00:12:52 -07:00
|
|
|
switch (reg) {
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
case HV_X64_MSR_SIMP:
|
|
|
|
|
return HV_X64_MSR_NESTED_SIMP;
|
|
|
|
|
case HV_X64_MSR_SIEFP:
|
|
|
|
|
return HV_X64_MSR_NESTED_SIEFP;
|
|
|
|
|
case HV_X64_MSR_SVERSION:
|
|
|
|
|
return HV_X64_MSR_NESTED_SVERSION;
|
|
|
|
|
case HV_X64_MSR_SCONTROL:
|
|
|
|
|
return HV_X64_MSR_NESTED_SCONTROL;
|
|
|
|
|
case HV_X64_MSR_EOM:
|
|
|
|
|
return HV_X64_MSR_NESTED_EOM;
|
2023-01-02 00:12:52 -07:00
|
|
|
default:
|
|
|
|
|
return reg;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
u64 hv_get_non_nested_msr(unsigned int reg)
|
2023-01-02 00:12:52 -07:00
|
|
|
{
|
|
|
|
|
u64 value;
|
|
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present)
|
2023-08-24 01:07:10 -07:00
|
|
|
hv_ivm_msr_read(reg, &value);
|
2023-01-02 00:12:52 -07:00
|
|
|
else
|
|
|
|
|
rdmsrl(reg, value);
|
|
|
|
|
return value;
|
|
|
|
|
}
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(hv_get_non_nested_msr);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
void hv_set_non_nested_msr(unsigned int reg, u64 value)
|
2023-01-02 00:12:52 -07:00
|
|
|
{
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present) {
|
2023-08-24 01:07:10 -07:00
|
|
|
hv_ivm_msr_write(reg, value);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
|
|
|
|
/* Write proxy bit via wrmsl instruction */
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
if (hv_is_sint_msr(reg))
|
2023-01-02 00:12:52 -07:00
|
|
|
wrmsrl(reg, value | 1 << 20);
|
|
|
|
|
} else {
|
|
|
|
|
wrmsrl(reg, value);
|
|
|
|
|
}
|
|
|
|
|
}
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(hv_set_non_nested_msr);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
u64 hv_get_msr(unsigned int reg)
|
2023-01-02 00:12:52 -07:00
|
|
|
{
|
|
|
|
|
if (hv_nested)
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
reg = hv_get_nested_msr(reg);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
return hv_get_non_nested_msr(reg);
|
2023-01-02 00:12:52 -07:00
|
|
|
}
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(hv_get_msr);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
void hv_set_msr(unsigned int reg, u64 value)
|
2023-01-02 00:12:52 -07:00
|
|
|
{
|
|
|
|
|
if (hv_nested)
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
reg = hv_get_nested_msr(reg);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
hv_set_non_nested_msr(reg, value);
|
2023-01-02 00:12:52 -07:00
|
|
|
}
|
hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*
The HV_REGISTER_ are used as arguments to hv_set/get_register(), which
delegate to arch-specific mechanisms for getting/setting synthetic
Hyper-V MSRs.
On arm64, HV_REGISTER_ defines are synthetic VP registers accessed via
the get/set vp registers hypercalls. The naming matches the TLFS
document, although these register names are not specific to arm64.
However, on x86 the prefix HV_REGISTER_ indicates Hyper-V MSRs accessed
via rdmsrl()/wrmsrl(). This is not consistent with the TLFS doc, where
HV_REGISTER_ is *only* used for used for VP register names used by
the get/set register hypercalls.
To fix this inconsistency and prevent future confusion, change the
arch-generic aliases used by callers of hv_set/get_register() to have
the prefix HV_MSR_ instead of HV_REGISTER_.
Use the prefix HV_X64_MSR_ for the x86-only Hyper-V MSRs. On x86, the
generic HV_MSR_'s point to the corresponding HV_X64_MSR_.
Move the arm64 HV_REGISTER_* defines to the asm-generic hyperv-tlfs.h,
since these are not specific to arm64. On arm64, the generic HV_MSR_'s
point to the corresponding HV_REGISTER_.
While at it, rename hv_get/set_registers() and related functions to
hv_get/set_msr(), hv_get/set_nested_msr(), etc. These are only used for
Hyper-V MSRs and this naming makes that clear.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1708440933-27125-1-git-send-email-nunodasneves@linux.microsoft.com>
2024-02-20 07:55:33 -07:00
|
|
|
EXPORT_SYMBOL_GPL(hv_set_msr);
|
2023-01-02 00:12:52 -07:00
|
|
|
|
2014-03-05 05:42:14 -07:00
|
|
|
static void (*vmbus_handler)(void);
|
2018-03-04 22:17:18 -07:00
|
|
|
static void (*hv_stimer0_handler)(void);
|
2015-09-23 03:02:57 -07:00
|
|
|
static void (*hv_kexec_handler)(void);
|
|
|
|
|
static void (*hv_crash_handler)(struct pt_regs *regs);
|
2014-02-23 14:40:22 -07:00
|
|
|
|
2020-05-21 13:05:43 -07:00
|
|
|
DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
|
2014-02-23 14:40:22 -07:00
|
|
|
{
|
|
|
|
|
struct pt_regs *old_regs = set_irq_regs(regs);
|
|
|
|
|
|
|
|
|
|
inc_irq_stat(irq_hv_callback_count);
|
|
|
|
|
if (vmbus_handler)
|
|
|
|
|
vmbus_handler();
|
|
|
|
|
|
2018-06-05 13:37:54 -07:00
|
|
|
if (ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED)
|
2023-08-09 08:16:46 -07:00
|
|
|
apic_eoi();
|
2017-03-28 17:16:53 -07:00
|
|
|
|
2014-02-23 14:40:22 -07:00
|
|
|
set_irq_regs(old_regs);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-02 14:38:18 -07:00
|
|
|
void hv_setup_vmbus_handler(void (*handler)(void))
|
2014-02-23 14:40:22 -07:00
|
|
|
{
|
|
|
|
|
vmbus_handler = handler;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-02 14:38:18 -07:00
|
|
|
void hv_remove_vmbus_handler(void)
|
2014-02-23 14:40:22 -07:00
|
|
|
{
|
|
|
|
|
/* We have no way to deallocate the interrupt gate */
|
|
|
|
|
vmbus_handler = NULL;
|
|
|
|
|
}
|
2015-08-01 16:08:07 -07:00
|
|
|
|
2018-03-04 22:17:18 -07:00
|
|
|
/*
|
|
|
|
|
* Routines to do per-architecture handling of stimer0
|
|
|
|
|
* interrupts when in Direct Mode
|
|
|
|
|
*/
|
2020-05-21 13:05:43 -07:00
|
|
|
DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_stimer0)
|
2018-03-04 22:17:18 -07:00
|
|
|
{
|
|
|
|
|
struct pt_regs *old_regs = set_irq_regs(regs);
|
|
|
|
|
|
|
|
|
|
inc_irq_stat(hyperv_stimer0_count);
|
|
|
|
|
if (hv_stimer0_handler)
|
|
|
|
|
hv_stimer0_handler();
|
2021-12-07 05:17:33 -07:00
|
|
|
add_interrupt_randomness(HYPERV_STIMER0_VECTOR);
|
2023-08-09 08:16:46 -07:00
|
|
|
apic_eoi();
|
2018-03-04 22:17:18 -07:00
|
|
|
|
|
|
|
|
set_irq_regs(old_regs);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-02 14:38:22 -07:00
|
|
|
/* For x86/x64, override weak placeholders in hyperv_timer.c */
|
|
|
|
|
void hv_setup_stimer0_handler(void (*handler)(void))
|
2018-03-04 22:17:18 -07:00
|
|
|
{
|
|
|
|
|
hv_stimer0_handler = handler;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-02 14:38:22 -07:00
|
|
|
void hv_remove_stimer0_handler(void)
|
2018-03-04 22:17:18 -07:00
|
|
|
{
|
|
|
|
|
/* We have no way to deallocate the interrupt gate */
|
|
|
|
|
hv_stimer0_handler = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-01 16:08:07 -07:00
|
|
|
void hv_setup_kexec_handler(void (*handler)(void))
|
|
|
|
|
{
|
|
|
|
|
hv_kexec_handler = handler;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void hv_remove_kexec_handler(void)
|
|
|
|
|
{
|
|
|
|
|
hv_kexec_handler = NULL;
|
|
|
|
|
}
|
2015-08-01 16:08:09 -07:00
|
|
|
|
|
|
|
|
void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs))
|
|
|
|
|
{
|
|
|
|
|
hv_crash_handler = handler;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void hv_remove_crash_handler(void)
|
|
|
|
|
{
|
|
|
|
|
hv_crash_handler = NULL;
|
|
|
|
|
}
|
2014-02-23 14:40:22 -07:00
|
|
|
|
2015-09-23 03:02:57 -07:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2015-08-01 16:08:07 -07:00
|
|
|
static void hv_machine_shutdown(void)
|
|
|
|
|
{
|
|
|
|
|
if (kexec_in_progress && hv_kexec_handler)
|
|
|
|
|
hv_kexec_handler();
|
2020-12-21 23:55:41 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Call hv_cpu_die() on all the CPUs, otherwise later the hypervisor
|
|
|
|
|
* corrupts the old VP Assist Pages and can crash the kexec kernel.
|
|
|
|
|
*/
|
2024-08-28 04:21:56 -07:00
|
|
|
if (kexec_in_progress)
|
|
|
|
|
cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);
|
2020-12-21 23:55:41 -07:00
|
|
|
|
|
|
|
|
/* The function calls stop_other_cpus(). */
|
2015-08-01 16:08:07 -07:00
|
|
|
native_machine_shutdown();
|
2020-12-21 23:55:41 -07:00
|
|
|
|
|
|
|
|
/* Disable the hypercall page when there is only 1 active CPU. */
|
|
|
|
|
if (kexec_in_progress)
|
|
|
|
|
hyperv_cleanup();
|
2015-08-01 16:08:07 -07:00
|
|
|
}
|
2024-01-23 22:12:46 -07:00
|
|
|
#endif /* CONFIG_KEXEC_CORE */
|
2015-08-01 16:08:07 -07:00
|
|
|
|
2024-01-23 22:12:46 -07:00
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
2015-08-01 16:08:09 -07:00
|
|
|
static void hv_machine_crash_shutdown(struct pt_regs *regs)
|
|
|
|
|
{
|
|
|
|
|
if (hv_crash_handler)
|
|
|
|
|
hv_crash_handler(regs);
|
2020-12-21 23:55:41 -07:00
|
|
|
|
|
|
|
|
/* The function calls crash_smp_send_stop(). */
|
2015-08-01 16:08:09 -07:00
|
|
|
native_machine_crash_shutdown(regs);
|
2020-12-21 23:55:41 -07:00
|
|
|
|
|
|
|
|
/* Disable the hypercall page when there is only 1 active CPU. */
|
|
|
|
|
hyperv_cleanup();
|
2015-08-01 16:08:09 -07:00
|
|
|
}
|
2024-01-23 22:12:46 -07:00
|
|
|
#endif /* CONFIG_CRASH_DUMP */
|
2015-09-23 03:02:57 -07:00
|
|
|
#endif /* CONFIG_HYPERV */
|
2015-08-01 16:08:09 -07:00
|
|
|
|
2013-07-25 01:54:35 -07:00
|
|
|
static uint32_t __init ms_hyperv_platform(void)
|
2010-05-06 12:08:41 -07:00
|
|
|
{
|
2010-05-07 16:57:28 -07:00
|
|
|
u32 eax;
|
|
|
|
|
u32 hyp_signature[3];
|
2010-05-06 12:08:41 -07:00
|
|
|
|
2010-05-07 16:57:28 -07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
|
2013-07-25 01:54:35 -07:00
|
|
|
return 0;
|
2010-05-06 12:08:41 -07:00
|
|
|
|
2010-05-07 16:57:28 -07:00
|
|
|
cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
|
|
|
|
|
&eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
|
2010-05-06 12:08:41 -07:00
|
|
|
|
2021-11-04 11:22:39 -07:00
|
|
|
if (eax < HYPERV_CPUID_MIN || eax > HYPERV_CPUID_MAX ||
|
|
|
|
|
memcmp("Microsoft Hv", hyp_signature, 12))
|
|
|
|
|
return 0;
|
2013-07-25 01:54:35 -07:00
|
|
|
|
2021-11-04 11:22:39 -07:00
|
|
|
/* HYPERCALL and VP_INDEX MSRs are mandatory for all features. */
|
|
|
|
|
eax = cpuid_eax(HYPERV_CPUID_FEATURES);
|
|
|
|
|
if (!(eax & HV_MSR_HYPERCALL_AVAILABLE)) {
|
|
|
|
|
pr_warn("x86/hyperv: HYPERCALL MSR not available.\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
if (!(eax & HV_MSR_VP_INDEX_AVAILABLE)) {
|
|
|
|
|
pr_warn("x86/hyperv: VP_INDEX MSR not available.\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS;
|
2010-05-06 12:08:41 -07:00
|
|
|
}
|
|
|
|
|
|
2016-12-02 03:07:20 -07:00
|
|
|
#ifdef CONFIG_X86_LOCAL_APIC
|
|
|
|
|
/*
|
|
|
|
|
* Prior to WS2016 Debug-VM sends NMIs to all CPUs which makes
|
2021-03-18 07:28:01 -07:00
|
|
|
* it difficult to process CHANNELMSG_UNLOAD in case of crash. Handle
|
2016-12-02 03:07:20 -07:00
|
|
|
* unknown NMI on the first CPU which gets it.
|
|
|
|
|
*/
|
|
|
|
|
static int hv_nmi_unknown(unsigned int val, struct pt_regs *regs)
|
|
|
|
|
{
|
|
|
|
|
static atomic_t nmi_cpu = ATOMIC_INIT(-1);
|
x86/hyperv: Use atomic_try_cmpxchg() to micro-optimize hv_nmi_unknown()
Use atomic_try_cmpxchg() instead of atomic_cmpxchg(*ptr, old, new) == old
in hv_nmi_unknown(). On x86 the CMPXCHG instruction returns success in
the ZF flag, so this change saves a compare after CMPXCHG. The generated
asm code improves from:
3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx
45: b8 ff ff ff ff mov $0xffffffff,%eax
4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip)
51: 00
52: 83 f8 ff cmp $0xffffffff,%eax
55: 0f 95 c0 setne %al
to:
3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx
45: b8 ff ff ff ff mov $0xffffffff,%eax
4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip)
51: 00
52: 0f 95 c0 setne %al
No functional change intended.
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20231114170038.381634-1-ubizjak@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20231114170038.381634-1-ubizjak@gmail.com>
2023-11-14 09:59:28 -07:00
|
|
|
unsigned int old_cpu, this_cpu;
|
2016-12-02 03:07:20 -07:00
|
|
|
|
|
|
|
|
if (!unknown_nmi_panic)
|
|
|
|
|
return NMI_DONE;
|
|
|
|
|
|
x86/hyperv: Use atomic_try_cmpxchg() to micro-optimize hv_nmi_unknown()
Use atomic_try_cmpxchg() instead of atomic_cmpxchg(*ptr, old, new) == old
in hv_nmi_unknown(). On x86 the CMPXCHG instruction returns success in
the ZF flag, so this change saves a compare after CMPXCHG. The generated
asm code improves from:
3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx
45: b8 ff ff ff ff mov $0xffffffff,%eax
4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip)
51: 00
52: 83 f8 ff cmp $0xffffffff,%eax
55: 0f 95 c0 setne %al
to:
3e: 65 8b 15 00 00 00 00 mov %gs:0x0(%rip),%edx
45: b8 ff ff ff ff mov $0xffffffff,%eax
4a: f0 0f b1 15 00 00 00 lock cmpxchg %edx,0x0(%rip)
51: 00
52: 0f 95 c0 setne %al
No functional change intended.
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20231114170038.381634-1-ubizjak@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20231114170038.381634-1-ubizjak@gmail.com>
2023-11-14 09:59:28 -07:00
|
|
|
old_cpu = -1;
|
|
|
|
|
this_cpu = raw_smp_processor_id();
|
|
|
|
|
if (!atomic_try_cmpxchg(&nmi_cpu, &old_cpu, this_cpu))
|
2016-12-02 03:07:20 -07:00
|
|
|
return NMI_HANDLED;
|
|
|
|
|
|
|
|
|
|
return NMI_DONE;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-06-22 03:07:30 -07:00
|
|
|
static unsigned long hv_get_tsc_khz(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned long freq;
|
|
|
|
|
|
|
|
|
|
rdmsrl(HV_X64_MSR_TSC_FREQUENCY, freq);
|
|
|
|
|
|
|
|
|
|
return freq / 1000;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-08 01:29:34 -07:00
|
|
|
#if defined(CONFIG_SMP) && IS_ENABLED(CONFIG_HYPERV)
|
|
|
|
|
static void __init hv_smp_prepare_boot_cpu(void)
|
|
|
|
|
{
|
|
|
|
|
native_smp_prepare_boot_cpu();
|
|
|
|
|
#if defined(CONFIG_X86_64) && defined(CONFIG_PARAVIRT_SPINLOCKS)
|
|
|
|
|
hv_init_spinlocks();
|
|
|
|
|
#endif
|
|
|
|
|
}
|
2021-02-03 08:04:29 -07:00
|
|
|
|
|
|
|
|
static void __init hv_smp_prepare_cpus(unsigned int max_cpus)
|
|
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
|
int i;
|
|
|
|
|
int ret;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
native_smp_prepare_cpus(max_cpus);
|
|
|
|
|
|
2023-08-18 03:29:17 -07:00
|
|
|
/*
|
|
|
|
|
* Override wakeup_secondary_cpu_64 callback for SEV-SNP
|
|
|
|
|
* enlightened guest.
|
|
|
|
|
*/
|
2023-08-24 01:07:11 -07:00
|
|
|
if (!ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
|
2023-08-18 03:29:17 -07:00
|
|
|
apic->wakeup_secondary_cpu_64 = hv_snp_boot_ap;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-03 08:04:29 -07:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
|
for_each_present_cpu(i) {
|
|
|
|
|
if (i == 0)
|
|
|
|
|
continue;
|
2021-07-21 08:55:43 -07:00
|
|
|
ret = hv_call_add_logical_proc(numa_cpu_node(i), i, cpu_physical_id(i));
|
2021-02-03 08:04:29 -07:00
|
|
|
BUG_ON(ret);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for_each_present_cpu(i) {
|
|
|
|
|
if (i == 0)
|
|
|
|
|
continue;
|
|
|
|
|
ret = hv_call_create_vp(numa_cpu_node(i), hv_current_partition_id, i, i);
|
|
|
|
|
BUG_ON(ret);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
}
|
2018-10-08 01:29:34 -07:00
|
|
|
#endif
|
|
|
|
|
|
2023-08-24 01:07:06 -07:00
|
|
|
/*
|
|
|
|
|
* When a fully enlightened TDX VM runs on Hyper-V, the firmware sets the
|
|
|
|
|
* HW_REDUCED flag: refer to acpi_tb_create_local_fadt(). Consequently ttyS0
|
|
|
|
|
* interrupts can't work because request_irq() -> ... -> irq_to_desc() returns
|
|
|
|
|
* NULL for ttyS0. This happens because mp_config_acpi_legacy_irqs() sees a
|
|
|
|
|
* nr_legacy_irqs() of 0, so it doesn't initialize the array 'mp_irqs[]', and
|
|
|
|
|
* later setup_IO_APIC_irqs() -> find_irq_entry() fails to find the legacy irqs
|
|
|
|
|
* from the array and hence doesn't create the necessary irq description info.
|
|
|
|
|
*
|
|
|
|
|
* Clone arch/x86/kernel/acpi/boot.c: acpi_generic_reduced_hw_init() here,
|
|
|
|
|
* except don't change 'legacy_pic', which keeps its default value
|
|
|
|
|
* 'default_legacy_pic'. This way, mp_config_acpi_legacy_irqs() sees a non-zero
|
|
|
|
|
* nr_legacy_irqs() and eventually serial console interrupts works properly.
|
|
|
|
|
*/
|
|
|
|
|
static void __init reduced_hw_init(void)
|
|
|
|
|
{
|
|
|
|
|
x86_init.timers.timer_init = x86_init_noop;
|
|
|
|
|
x86_init.irqs.pre_vector_init = x86_init_noop;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-07 16:03:38 -07:00
|
|
|
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
|
|
|
|
|
{
|
|
|
|
|
unsigned int hv_max_functions;
|
|
|
|
|
|
|
|
|
|
hv_max_functions = cpuid_eax(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS);
|
|
|
|
|
if (hv_max_functions < HYPERV_CPUID_VERSION) {
|
|
|
|
|
pr_err("%s: Could not detect Hyper-V version\n", __func__);
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cpuid(HYPERV_CPUID_VERSION, &info->eax, &info->ebx, &info->ecx, &info->edx);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-05-07 16:57:28 -07:00
|
|
|
static void __init ms_hyperv_init_platform(void)
|
2010-05-06 12:08:41 -07:00
|
|
|
{
|
2021-06-03 08:14:34 -07:00
|
|
|
int hv_max_functions_eax;
|
2017-01-19 11:51:47 -07:00
|
|
|
|
2019-10-15 03:35:02 -07:00
|
|
|
#ifdef CONFIG_PARAVIRT
|
|
|
|
|
pv_info.name = "Hyper-V";
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-05-06 12:08:41 -07:00
|
|
|
/*
|
2010-05-07 16:57:28 -07:00
|
|
|
* Extract the features and hints
|
2010-05-06 12:08:41 -07:00
|
|
|
*/
|
2010-05-07 16:57:28 -07:00
|
|
|
ms_hyperv.features = cpuid_eax(HYPERV_CPUID_FEATURES);
|
2021-03-23 11:47:16 -07:00
|
|
|
ms_hyperv.priv_high = cpuid_ebx(HYPERV_CPUID_FEATURES);
|
2015-08-01 16:08:20 -07:00
|
|
|
ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
|
2010-05-07 16:57:28 -07:00
|
|
|
ms_hyperv.hints = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
|
2010-05-06 12:08:41 -07:00
|
|
|
|
2021-06-03 08:14:34 -07:00
|
|
|
hv_max_functions_eax = cpuid_eax(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS);
|
|
|
|
|
|
2021-03-23 11:47:16 -07:00
|
|
|
pr_info("Hyper-V: privilege flags low 0x%x, high 0x%x, hints 0x%x, misc 0x%x\n",
|
|
|
|
|
ms_hyperv.features, ms_hyperv.priv_high, ms_hyperv.hints,
|
|
|
|
|
ms_hyperv.misc_features);
|
2011-09-07 15:25:10 -07:00
|
|
|
|
2018-03-20 07:02:06 -07:00
|
|
|
ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS);
|
|
|
|
|
ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS);
|
2017-06-25 10:06:41 -07:00
|
|
|
|
|
|
|
|
pr_debug("Hyper-V: max %u virtual processors, %u logical processors\n",
|
|
|
|
|
ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
|
|
|
|
|
|
2021-02-03 08:04:21 -07:00
|
|
|
/*
|
|
|
|
|
* Check CPU management privilege.
|
|
|
|
|
*
|
|
|
|
|
* To mirror what Windows does we should extract CPU management
|
|
|
|
|
* features and use the ReservedIdentityBit to detect if Linux is the
|
|
|
|
|
* root partition. But that requires negotiating CPU management
|
2023-03-15 08:34:13 -07:00
|
|
|
* interface (a process to be finalized). For now, use the privilege
|
|
|
|
|
* flag as the indicator for running as root.
|
2021-02-03 08:04:21 -07:00
|
|
|
*
|
2023-03-15 08:34:13 -07:00
|
|
|
* Hyper-V should never specify running as root and as a Confidential
|
|
|
|
|
* VM. But to protect against a compromised/malicious Hyper-V trying
|
|
|
|
|
* to exploit root behavior to expose Confidential VM memory, ignore
|
|
|
|
|
* the root partition setting if also a Confidential VM.
|
2021-02-03 08:04:21 -07:00
|
|
|
*/
|
2023-03-15 08:34:13 -07:00
|
|
|
if ((ms_hyperv.priv_high & HV_CPU_MANAGEMENT) &&
|
|
|
|
|
!(ms_hyperv.priv_high & HV_ISOLATION)) {
|
2021-02-03 08:04:21 -07:00
|
|
|
hv_root_partition = true;
|
|
|
|
|
pr_info("Hyper-V: running as root partition\n");
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-02 00:12:51 -07:00
|
|
|
if (ms_hyperv.hints & HV_X64_HYPERV_NESTED) {
|
|
|
|
|
hv_nested = true;
|
|
|
|
|
pr_info("Hyper-V: running on a nested hypervisor\n");
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-26 07:26:26 -07:00
|
|
|
if (ms_hyperv.features & HV_ACCESS_FREQUENCY_MSRS &&
|
2017-06-22 03:07:30 -07:00
|
|
|
ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) {
|
|
|
|
|
x86_platform.calibrate_tsc = hv_get_tsc_khz;
|
|
|
|
|
x86_platform.calibrate_cpu = hv_get_tsc_khz;
|
2024-06-05 19:55:59 -07:00
|
|
|
setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
|
2017-06-22 03:07:30 -07:00
|
|
|
}
|
|
|
|
|
|
2021-03-23 11:47:16 -07:00
|
|
|
if (ms_hyperv.priv_high & HV_ISOLATION) {
|
2021-02-01 07:48:11 -07:00
|
|
|
ms_hyperv.isolation_config_a = cpuid_eax(HYPERV_CPUID_ISOLATION_CONFIG);
|
|
|
|
|
ms_hyperv.isolation_config_b = cpuid_ebx(HYPERV_CPUID_ISOLATION_CONFIG);
|
x86/hyperv: Change vTOM handling to use standard coco mechanisms
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves.
vTOM is the dividing line where the uppermost bit of the physical
address space is set; e.g., with 47 bits of guest physical address
space, vTOM is 0x400000000000 (bit 46 is set). Guest physical memory is
accessible at two parallel physical addresses -- one below vTOM and one
above vTOM. Accesses below vTOM are private (encrypted) while accesses
above vTOM are shared (decrypted). In this sense, vTOM is like the
GPA.SHARED bit in Intel TDX.
Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.
A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms.
When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit in the
guest physical address, just as with TDX. The hypercalls to change the
memory status on the host side are made using the existing callback
mechanism. Everything just works, with a minor tweak to map the IO-APIC
to use private accesses.
To accomplish the switch in approach, the following must be done:
* Update Hyper-V initialization to set the cc_mask based on vTOM
and do other coco initialization.
* Update physical_mask so the vTOM bit is no longer treated as part
of the physical address
* Remove CC_VENDOR_HYPERV and merge the associated vTOM functionality
under CC_VENDOR_AMD. Update cc_mkenc() and cc_mkdec() to set/clear
the vTOM bit as a protection flag.
* Code already exists to make hypercalls to inform Hyper-V about pages
changing between shared and private. Update this code to run as a
callback from __set_memory_enc_pgtable().
* Remove the Hyper-V special case from __set_memory_enc_dec()
* Remove the Hyper-V specific call to swiotlb_update_mem_attributes()
since mem_encrypt_init() will now do it.
* Add a Hyper-V specific implementation of the is_private_mmio()
callback that returns true for the IO-APIC and vTPM MMIO addresses
[1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@gmail.com/
[2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@gmail.com/
[ bp: Touchups. ]
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/1679838727-87310-7-git-send-email-mikelley@microsoft.com
2023-03-26 06:52:01 -07:00
|
|
|
|
|
|
|
|
if (ms_hyperv.shared_gpa_boundary_active)
|
|
|
|
|
ms_hyperv.shared_gpa_boundary =
|
|
|
|
|
BIT_ULL(ms_hyperv.shared_gpa_boundary_bits);
|
2021-02-01 07:48:11 -07:00
|
|
|
|
x86/hyperv: Introduce a global variable hyperv_paravisor_present
The new variable hyperv_paravisor_present is set only when the VM
is a SNP/TDX VM with the paravisor running: see ms_hyperv_init_platform().
We introduce hyperv_paravisor_present because we can not use
ms_hyperv.paravisor_present in arch/x86/include/asm/mshyperv.h:
struct ms_hyperv_info is defined in include/asm-generic/mshyperv.h, which
is included at the end of arch/x86/include/asm/mshyperv.h, but at the
beginning of arch/x86/include/asm/mshyperv.h, we would already need to use
struct ms_hyperv_info in hv_do_hypercall().
We use hyperv_paravisor_present only in include/asm-generic/mshyperv.h,
and use ms_hyperv.paravisor_present elsewhere. In the future, we'll
introduce a hypercall function structure for different VM types, and
at boot time, the right function pointers would be written into the
structure so that runtime testing of TDX vs. SNP vs. normal will be
avoided and hyperv_paravisor_present will no longer be needed.
Call hv_vtom_init() when it's a VBS VM or when ms_hyperv.paravisor_present
is true, i.e. the VM is a SNP VM or TDX VM with the paravisor.
Enhance hv_vtom_init() for a TDX VM with the paravisor.
In hv_common_cpu_init(), don't decrypt the hyperv_pcpu_input_arg
for a TDX VM with the paravisor, just like we don't decrypt the page
for a SNP VM with the paravisor.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20230824080712.30327-7-decui@microsoft.com
2023-08-24 01:07:08 -07:00
|
|
|
hyperv_paravisor_present = !!ms_hyperv.paravisor_present;
|
|
|
|
|
|
2021-02-01 07:48:11 -07:00
|
|
|
pr_info("Hyper-V: Isolation Config: Group A 0x%x, Group B 0x%x\n",
|
|
|
|
|
ms_hyperv.isolation_config_a, ms_hyperv.isolation_config_b);
|
2021-10-25 05:21:06 -07:00
|
|
|
|
2023-08-18 03:29:11 -07:00
|
|
|
|
2023-08-22 20:20:08 -07:00
|
|
|
if (hv_get_isolation_type() == HV_ISOLATION_TYPE_SNP) {
|
2021-10-25 05:21:06 -07:00
|
|
|
static_branch_enable(&isolation_type_snp);
|
2023-08-24 01:07:03 -07:00
|
|
|
} else if (hv_get_isolation_type() == HV_ISOLATION_TYPE_TDX) {
|
|
|
|
|
static_branch_enable(&isolation_type_tdx);
|
2023-08-24 01:07:05 -07:00
|
|
|
|
|
|
|
|
/* A TDX VM must use x2APIC and doesn't use lazy EOI. */
|
|
|
|
|
ms_hyperv.hints &= ~HV_X64_APIC_ACCESS_RECOMMENDED;
|
|
|
|
|
|
|
|
|
|
if (!ms_hyperv.paravisor_present) {
|
2024-06-20 23:16:14 -07:00
|
|
|
/*
|
|
|
|
|
* Mark the Hyper-V TSC page feature as disabled
|
|
|
|
|
* in a TDX VM without paravisor so that the
|
|
|
|
|
* Invariant TSC, which is a better clocksource
|
|
|
|
|
* anyway, is used instead.
|
|
|
|
|
*/
|
2023-08-24 01:07:05 -07:00
|
|
|
ms_hyperv.features &= ~HV_MSR_REFERENCE_TSC_AVAILABLE;
|
|
|
|
|
|
2024-06-20 23:16:14 -07:00
|
|
|
/*
|
|
|
|
|
* The Invariant TSC is expected to be available
|
|
|
|
|
* in a TDX VM without paravisor, but if not,
|
|
|
|
|
* print a warning message. The slower Hyper-V MSR-based
|
|
|
|
|
* Ref Counter should end up being the clocksource.
|
|
|
|
|
*/
|
|
|
|
|
if (!(ms_hyperv.features & HV_ACCESS_TSC_INVARIANT))
|
|
|
|
|
pr_warn("Hyper-V: Invariant TSC is unavailable\n");
|
|
|
|
|
|
2024-03-12 16:21:27 -07:00
|
|
|
/* HV_MSR_CRASH_CTL is unsupported. */
|
2023-08-24 01:07:05 -07:00
|
|
|
ms_hyperv.misc_features &= ~HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE;
|
|
|
|
|
|
|
|
|
|
/* Don't trust Hyper-V's TLB-flushing hypercalls. */
|
|
|
|
|
ms_hyperv.hints &= ~HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED;
|
2023-08-24 01:07:06 -07:00
|
|
|
|
|
|
|
|
x86_init.acpi.reduced_hw_early_init = reduced_hw_init;
|
2023-08-24 01:07:05 -07:00
|
|
|
}
|
2023-08-18 03:29:11 -07:00
|
|
|
}
|
2021-02-01 07:48:11 -07:00
|
|
|
}
|
|
|
|
|
|
2021-06-03 08:14:34 -07:00
|
|
|
if (hv_max_functions_eax >= HYPERV_CPUID_NESTED_FEATURES) {
|
2018-03-20 07:02:10 -07:00
|
|
|
ms_hyperv.nested_features =
|
|
|
|
|
cpuid_eax(HYPERV_CPUID_NESTED_FEATURES);
|
2021-06-03 08:14:34 -07:00
|
|
|
pr_info("Hyper-V: Nested features: 0x%x\n",
|
|
|
|
|
ms_hyperv.nested_features);
|
2018-03-20 07:02:10 -07:00
|
|
|
}
|
|
|
|
|
|
2013-10-10 15:30:24 -07:00
|
|
|
#ifdef CONFIG_X86_LOCAL_APIC
|
2020-09-26 07:26:26 -07:00
|
|
|
if (ms_hyperv.features & HV_ACCESS_FREQUENCY_MSRS &&
|
2017-06-22 03:07:29 -07:00
|
|
|
ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) {
|
2013-09-30 08:28:52 -07:00
|
|
|
/*
|
|
|
|
|
* Get the APIC frequency.
|
|
|
|
|
*/
|
2013-11-06 11:00:05 -07:00
|
|
|
u64 hv_lapic_frequency;
|
|
|
|
|
|
2013-09-30 08:28:52 -07:00
|
|
|
rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
|
|
|
|
|
hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
|
2019-05-08 22:54:16 -07:00
|
|
|
lapic_timer_period = hv_lapic_frequency;
|
2017-06-25 10:06:41 -07:00
|
|
|
pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
|
2019-05-08 22:54:16 -07:00
|
|
|
lapic_timer_period);
|
2013-09-30 08:28:52 -07:00
|
|
|
}
|
2016-12-02 03:07:20 -07:00
|
|
|
|
|
|
|
|
register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST,
|
|
|
|
|
"hv_nmi_unknown");
|
2013-10-10 15:30:24 -07:00
|
|
|
#endif
|
2013-09-30 08:28:52 -07:00
|
|
|
|
2014-02-27 20:30:29 -07:00
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
|
|
|
|
no_timer_check = 1;
|
|
|
|
|
#endif
|
|
|
|
|
|
2024-01-23 22:12:46 -07:00
|
|
|
#if IS_ENABLED(CONFIG_HYPERV)
|
|
|
|
|
#if defined(CONFIG_KEXEC_CORE)
|
2015-08-01 16:08:07 -07:00
|
|
|
machine_ops.shutdown = hv_machine_shutdown;
|
2024-01-23 22:12:46 -07:00
|
|
|
#endif
|
|
|
|
|
#if defined(CONFIG_CRASH_DUMP)
|
2015-08-01 16:08:09 -07:00
|
|
|
machine_ops.crash_shutdown = hv_machine_crash_shutdown;
|
2024-01-23 22:12:46 -07:00
|
|
|
#endif
|
2015-09-23 03:02:57 -07:00
|
|
|
#endif
|
2020-09-26 07:26:26 -07:00
|
|
|
if (ms_hyperv.features & HV_ACCESS_TSC_INVARIANT) {
|
2021-07-16 06:32:45 -07:00
|
|
|
/*
|
|
|
|
|
* Writing to synthetic MSR 0x40000118 updates/changes the
|
|
|
|
|
* guest visible CPUIDs. Setting bit 0 of this MSR enables
|
|
|
|
|
* guests to report invariant TSC feature through CPUID
|
|
|
|
|
* instruction, CPUID 0x800000007/EDX, bit 8. See code in
|
|
|
|
|
* early_init_intel() where this bit is examined. The
|
|
|
|
|
* setting of this MSR bit should happen before init_intel()
|
|
|
|
|
* is called.
|
|
|
|
|
*/
|
2022-10-13 02:58:43 -07:00
|
|
|
wrmsrl(HV_X64_MSR_TSC_INVARIANT_CONTROL, HV_EXPOSE_INVARIANT_TSC);
|
2019-10-03 08:52:00 -07:00
|
|
|
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
|
|
|
|
|
}
|
2016-04-15 06:50:32 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Generation 2 instances don't support reading the NMI status from
|
|
|
|
|
* 0x61 port.
|
|
|
|
|
*/
|
|
|
|
|
if (efi_enabled(EFI_BOOT))
|
|
|
|
|
x86_platform.get_nmi_reason = hv_get_nmi_reason;
|
2017-01-18 16:45:02 -07:00
|
|
|
|
|
|
|
|
#if IS_ENABLED(CONFIG_HYPERV)
|
x86/hyperv: Change vTOM handling to use standard coco mechanisms
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves.
vTOM is the dividing line where the uppermost bit of the physical
address space is set; e.g., with 47 bits of guest physical address
space, vTOM is 0x400000000000 (bit 46 is set). Guest physical memory is
accessible at two parallel physical addresses -- one below vTOM and one
above vTOM. Accesses below vTOM are private (encrypted) while accesses
above vTOM are shared (decrypted). In this sense, vTOM is like the
GPA.SHARED bit in Intel TDX.
Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.
A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms.
When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit in the
guest physical address, just as with TDX. The hypercalls to change the
memory status on the host side are made using the existing callback
mechanism. Everything just works, with a minor tweak to map the IO-APIC
to use private accesses.
To accomplish the switch in approach, the following must be done:
* Update Hyper-V initialization to set the cc_mask based on vTOM
and do other coco initialization.
* Update physical_mask so the vTOM bit is no longer treated as part
of the physical address
* Remove CC_VENDOR_HYPERV and merge the associated vTOM functionality
under CC_VENDOR_AMD. Update cc_mkenc() and cc_mkdec() to set/clear
the vTOM bit as a protection flag.
* Code already exists to make hypercalls to inform Hyper-V about pages
changing between shared and private. Update this code to run as a
callback from __set_memory_enc_pgtable().
* Remove the Hyper-V special case from __set_memory_enc_dec()
* Remove the Hyper-V specific call to swiotlb_update_mem_attributes()
since mem_encrypt_init() will now do it.
* Add a Hyper-V specific implementation of the is_private_mmio()
callback that returns true for the IO-APIC and vTPM MMIO addresses
[1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@gmail.com/
[2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@gmail.com/
[ bp: Touchups. ]
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/1679838727-87310-7-git-send-email-mikelley@microsoft.com
2023-03-26 06:52:01 -07:00
|
|
|
if ((hv_get_isolation_type() == HV_ISOLATION_TYPE_VBS) ||
|
x86/hyperv: Introduce a global variable hyperv_paravisor_present
The new variable hyperv_paravisor_present is set only when the VM
is a SNP/TDX VM with the paravisor running: see ms_hyperv_init_platform().
We introduce hyperv_paravisor_present because we can not use
ms_hyperv.paravisor_present in arch/x86/include/asm/mshyperv.h:
struct ms_hyperv_info is defined in include/asm-generic/mshyperv.h, which
is included at the end of arch/x86/include/asm/mshyperv.h, but at the
beginning of arch/x86/include/asm/mshyperv.h, we would already need to use
struct ms_hyperv_info in hv_do_hypercall().
We use hyperv_paravisor_present only in include/asm-generic/mshyperv.h,
and use ms_hyperv.paravisor_present elsewhere. In the future, we'll
introduce a hypercall function structure for different VM types, and
at boot time, the right function pointers would be written into the
structure so that runtime testing of TDX vs. SNP vs. normal will be
avoided and hyperv_paravisor_present will no longer be needed.
Call hv_vtom_init() when it's a VBS VM or when ms_hyperv.paravisor_present
is true, i.e. the VM is a SNP VM or TDX VM with the paravisor.
Enhance hv_vtom_init() for a TDX VM with the paravisor.
In hv_common_cpu_init(), don't decrypt the hyperv_pcpu_input_arg
for a TDX VM with the paravisor, just like we don't decrypt the page
for a SNP VM with the paravisor.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20230824080712.30327-7-decui@microsoft.com
2023-08-24 01:07:08 -07:00
|
|
|
ms_hyperv.paravisor_present)
|
x86/hyperv: Change vTOM handling to use standard coco mechanisms
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves.
vTOM is the dividing line where the uppermost bit of the physical
address space is set; e.g., with 47 bits of guest physical address
space, vTOM is 0x400000000000 (bit 46 is set). Guest physical memory is
accessible at two parallel physical addresses -- one below vTOM and one
above vTOM. Accesses below vTOM are private (encrypted) while accesses
above vTOM are shared (decrypted). In this sense, vTOM is like the
GPA.SHARED bit in Intel TDX.
Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.
A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms.
When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit in the
guest physical address, just as with TDX. The hypercalls to change the
memory status on the host side are made using the existing callback
mechanism. Everything just works, with a minor tweak to map the IO-APIC
to use private accesses.
To accomplish the switch in approach, the following must be done:
* Update Hyper-V initialization to set the cc_mask based on vTOM
and do other coco initialization.
* Update physical_mask so the vTOM bit is no longer treated as part
of the physical address
* Remove CC_VENDOR_HYPERV and merge the associated vTOM functionality
under CC_VENDOR_AMD. Update cc_mkenc() and cc_mkdec() to set/clear
the vTOM bit as a protection flag.
* Code already exists to make hypercalls to inform Hyper-V about pages
changing between shared and private. Update this code to run as a
callback from __set_memory_enc_pgtable().
* Remove the Hyper-V special case from __set_memory_enc_dec()
* Remove the Hyper-V specific call to swiotlb_update_mem_attributes()
since mem_encrypt_init() will now do it.
* Add a Hyper-V specific implementation of the is_private_mmio()
callback that returns true for the IO-APIC and vTPM MMIO addresses
[1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@gmail.com/
[2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@gmail.com/
[ bp: Touchups. ]
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/1679838727-87310-7-git-send-email-mikelley@microsoft.com
2023-03-26 06:52:01 -07:00
|
|
|
hv_vtom_init();
|
2017-01-18 16:45:02 -07:00
|
|
|
/*
|
|
|
|
|
* Setup the hook to get control post apic initialization.
|
|
|
|
|
*/
|
|
|
|
|
x86_platform.apic_post_init = hyperv_init;
|
2017-08-02 09:09:19 -07:00
|
|
|
hyperv_setup_mmu_ops();
|
2018-01-24 06:23:33 -07:00
|
|
|
|
2023-12-05 03:50:16 -07:00
|
|
|
/* Install system interrupt handler for hypervisor callback */
|
|
|
|
|
sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_hyperv_callback);
|
|
|
|
|
|
|
|
|
|
/* Install system interrupt handler for reenlightenment notifications */
|
2020-09-26 07:26:26 -07:00
|
|
|
if (ms_hyperv.features & HV_ACCESS_REENLIGHTENMENT) {
|
2023-12-05 03:50:16 -07:00
|
|
|
sysvec_install(HYPERV_REENLIGHTENMENT_VECTOR, sysvec_hyperv_reenlightenment);
|
2020-05-21 13:05:43 -07:00
|
|
|
}
|
2018-01-24 06:23:33 -07:00
|
|
|
|
2023-12-05 03:50:16 -07:00
|
|
|
/* Install system interrupt handler for stimer0 */
|
2020-05-21 13:05:43 -07:00
|
|
|
if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE) {
|
2023-12-05 03:50:16 -07:00
|
|
|
sysvec_install(HYPERV_STIMER0_VECTOR, sysvec_hyperv_stimer0);
|
2020-05-21 13:05:43 -07:00
|
|
|
}
|
2018-10-08 01:29:34 -07:00
|
|
|
|
|
|
|
|
# ifdef CONFIG_SMP
|
|
|
|
|
smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
|
2023-08-24 01:07:11 -07:00
|
|
|
if (hv_root_partition ||
|
|
|
|
|
(!ms_hyperv.paravisor_present && hv_isolation_type_snp()))
|
2021-02-03 08:04:29 -07:00
|
|
|
smp_ops.smp_prepare_cpus = hv_smp_prepare_cpus;
|
2018-10-08 01:29:34 -07:00
|
|
|
# endif
|
2019-02-27 07:54:03 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
|
2021-03-18 07:28:01 -07:00
|
|
|
* set x2apic destination mode to physical mode when x2apic is available
|
2019-02-27 07:54:03 -07:00
|
|
|
* and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs
|
|
|
|
|
* have 8-bit APIC id.
|
|
|
|
|
*/
|
|
|
|
|
# ifdef CONFIG_X86_X2APIC
|
|
|
|
|
if (x2apic_supported())
|
|
|
|
|
x2apic_phys = 1;
|
|
|
|
|
# endif
|
|
|
|
|
|
2019-08-14 05:32:16 -07:00
|
|
|
/* Register Hyper-V specific clocksource */
|
|
|
|
|
hv_init_clocksource();
|
2023-04-10 22:55:32 -07:00
|
|
|
hv_vtl_init_platform();
|
2017-01-18 16:45:02 -07:00
|
|
|
#endif
|
2021-07-12 20:05:21 -07:00
|
|
|
/*
|
|
|
|
|
* TSC should be marked as unstable only after Hyper-V
|
|
|
|
|
* clocksource has been initialized. This ensures that the
|
|
|
|
|
* stability of the sched_clock is not altered.
|
|
|
|
|
*/
|
|
|
|
|
if (!(ms_hyperv.features & HV_ACCESS_TSC_INVARIANT))
|
|
|
|
|
mark_tsc_unstable("running on Hyper-V");
|
2022-05-09 08:44:23 -07:00
|
|
|
|
|
|
|
|
hardlockup_detector_disable();
|
2010-05-06 12:08:41 -07:00
|
|
|
}
|
2010-05-07 16:57:28 -07:00
|
|
|
|
x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it
When a Linux VM runs on Hyper-V, if the VM has CPUs with >255 APIC IDs,
the CPUs can't be the destination of IOAPIC interrupts, because the
IOAPIC RTE's Dest Field has only 8 bits. Currently the hackery driver
drivers/iommu/hyperv-iommu.c is used to ensure IOAPIC interrupts are
only routed to CPUs that don't have >255 APIC IDs. However, there is
an issue with kdump, because the kdump kernel can run on any CPU, and
hence IOAPIC interrupts can't work if the kdump kernel run on a CPU
with a >255 APIC ID.
The kdump issue can be fixed by the Extended Dest ID, which is introduced
recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in
struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the
support of the underlying hypervisor. The latest Hyper-V has added the
support recently: with this commit, on such a Hyper-V host, Linux VM
does not use hyperv-iommu.c because hyperv_prepare_irq_remapping()
returns -ENODEV; instead, Linux kernel's generic support of Extended Dest
ID from David is used, meaning that Linux VM is able to support up to
32K CPUs, and IOAPIC interrupts can be routed to all the CPUs.
On an old Hyper-V host that doesn't support the Extended Dest ID, nothing
changes with this commit: Linux VM is still able to bring up the CPUs with
> 255 APIC IDs with the help of hyperv-iommu.c, but IOAPIC interrupts still
can not go to such CPUs, and the kdump kernel still can not work properly
on such CPUs.
[ tglx: Updated comment as suggested by David ]
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/20201103011136.59108-1-decui@microsoft.com
2020-11-02 18:11:36 -07:00
|
|
|
static bool __init ms_hyperv_x2apic_available(void)
|
|
|
|
|
{
|
|
|
|
|
return x2apic_supported();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If ms_hyperv_msi_ext_dest_id() returns true, hyperv_prepare_irq_remapping()
|
|
|
|
|
* returns -ENODEV and the Hyper-V IOMMU driver is not used; instead, the
|
|
|
|
|
* generic support of the 15-bit APIC ID is used: see __irq_msi_compose_msg().
|
|
|
|
|
*
|
|
|
|
|
* Note: for a VM on Hyper-V, the I/O-APIC is the only device which
|
|
|
|
|
* (logically) generates MSIs directly to the system APIC irq domain.
|
|
|
|
|
* There is no HPET, and PCI MSI/MSI-X interrupts are remapped by the
|
|
|
|
|
* pci-hyperv host bridge.
|
2022-11-17 13:11:39 -07:00
|
|
|
*
|
|
|
|
|
* Note: for a Hyper-V root partition, this will always return false.
|
|
|
|
|
* The hypervisor doesn't expose these HYPERV_CPUID_VIRT_STACK_* cpuids by
|
|
|
|
|
* default, they are implemented as intercepts by the Windows Hyper-V stack.
|
|
|
|
|
* Even a nested root partition (L2 root) will not get them because the
|
|
|
|
|
* nested (L1) hypervisor filters them out.
|
x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it
When a Linux VM runs on Hyper-V, if the VM has CPUs with >255 APIC IDs,
the CPUs can't be the destination of IOAPIC interrupts, because the
IOAPIC RTE's Dest Field has only 8 bits. Currently the hackery driver
drivers/iommu/hyperv-iommu.c is used to ensure IOAPIC interrupts are
only routed to CPUs that don't have >255 APIC IDs. However, there is
an issue with kdump, because the kdump kernel can run on any CPU, and
hence IOAPIC interrupts can't work if the kdump kernel run on a CPU
with a >255 APIC ID.
The kdump issue can be fixed by the Extended Dest ID, which is introduced
recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in
struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the
support of the underlying hypervisor. The latest Hyper-V has added the
support recently: with this commit, on such a Hyper-V host, Linux VM
does not use hyperv-iommu.c because hyperv_prepare_irq_remapping()
returns -ENODEV; instead, Linux kernel's generic support of Extended Dest
ID from David is used, meaning that Linux VM is able to support up to
32K CPUs, and IOAPIC interrupts can be routed to all the CPUs.
On an old Hyper-V host that doesn't support the Extended Dest ID, nothing
changes with this commit: Linux VM is still able to bring up the CPUs with
> 255 APIC IDs with the help of hyperv-iommu.c, but IOAPIC interrupts still
can not go to such CPUs, and the kdump kernel still can not work properly
on such CPUs.
[ tglx: Updated comment as suggested by David ]
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/20201103011136.59108-1-decui@microsoft.com
2020-11-02 18:11:36 -07:00
|
|
|
*/
|
|
|
|
|
static bool __init ms_hyperv_msi_ext_dest_id(void)
|
|
|
|
|
{
|
|
|
|
|
u32 eax;
|
|
|
|
|
|
|
|
|
|
eax = cpuid_eax(HYPERV_CPUID_VIRT_STACK_INTERFACE);
|
|
|
|
|
if (eax != HYPERV_VS_INTERFACE_EAX_SIGNATURE)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
eax = cpuid_eax(HYPERV_CPUID_VIRT_STACK_PROPERTIES);
|
|
|
|
|
return eax & HYPERV_VS_PROPERTIES_EAX_EXTENDED_IOAPIC_RTE;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-18 03:29:18 -07:00
|
|
|
#ifdef CONFIG_AMD_MEM_ENCRYPT
|
|
|
|
|
static void hv_sev_es_hcall_prepare(struct ghcb *ghcb, struct pt_regs *regs)
|
|
|
|
|
{
|
|
|
|
|
/* RAX and CPL are already in the GHCB */
|
|
|
|
|
ghcb_set_rcx(ghcb, regs->cx);
|
|
|
|
|
ghcb_set_rdx(ghcb, regs->dx);
|
|
|
|
|
ghcb_set_r8(ghcb, regs->r8);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool hv_sev_es_hcall_finish(struct ghcb *ghcb, struct pt_regs *regs)
|
|
|
|
|
{
|
|
|
|
|
/* No checking of the return state needed */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-11-09 06:27:36 -07:00
|
|
|
const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
|
2017-06-25 10:06:41 -07:00
|
|
|
.name = "Microsoft Hyper-V",
|
2010-05-07 16:57:28 -07:00
|
|
|
.detect = ms_hyperv_platform,
|
2017-11-09 06:27:36 -07:00
|
|
|
.type = X86_HYPER_MS_HYPERV,
|
x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it
When a Linux VM runs on Hyper-V, if the VM has CPUs with >255 APIC IDs,
the CPUs can't be the destination of IOAPIC interrupts, because the
IOAPIC RTE's Dest Field has only 8 bits. Currently the hackery driver
drivers/iommu/hyperv-iommu.c is used to ensure IOAPIC interrupts are
only routed to CPUs that don't have >255 APIC IDs. However, there is
an issue with kdump, because the kdump kernel can run on any CPU, and
hence IOAPIC interrupts can't work if the kdump kernel run on a CPU
with a >255 APIC ID.
The kdump issue can be fixed by the Extended Dest ID, which is introduced
recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in
struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the
support of the underlying hypervisor. The latest Hyper-V has added the
support recently: with this commit, on such a Hyper-V host, Linux VM
does not use hyperv-iommu.c because hyperv_prepare_irq_remapping()
returns -ENODEV; instead, Linux kernel's generic support of Extended Dest
ID from David is used, meaning that Linux VM is able to support up to
32K CPUs, and IOAPIC interrupts can be routed to all the CPUs.
On an old Hyper-V host that doesn't support the Extended Dest ID, nothing
changes with this commit: Linux VM is still able to bring up the CPUs with
> 255 APIC IDs with the help of hyperv-iommu.c, but IOAPIC interrupts still
can not go to such CPUs, and the kdump kernel still can not work properly
on such CPUs.
[ tglx: Updated comment as suggested by David ]
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/20201103011136.59108-1-decui@microsoft.com
2020-11-02 18:11:36 -07:00
|
|
|
.init.x2apic_available = ms_hyperv_x2apic_available,
|
|
|
|
|
.init.msi_ext_dest_id = ms_hyperv_msi_ext_dest_id,
|
2017-11-09 06:27:35 -07:00
|
|
|
.init.init_platform = ms_hyperv_init_platform,
|
2024-03-18 08:54:08 -07:00
|
|
|
.init.guest_late_init = ms_hyperv_late_init,
|
2023-08-18 03:29:18 -07:00
|
|
|
#ifdef CONFIG_AMD_MEM_ENCRYPT
|
|
|
|
|
.runtime.sev_es_hcall_prepare = hv_sev_es_hcall_prepare,
|
|
|
|
|
.runtime.sev_es_hcall_finish = hv_sev_es_hcall_finish,
|
|
|
|
|
#endif
|
2010-05-07 16:57:28 -07:00
|
|
|
};
|