From: Pawan Gupta <[email protected]>
Guests that have different family/model than the host may not be aware
of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
particularly true when guests migrate. To solve this problem Intel
processors have added a virtual MSR interface through which guests can
report their mitigation status and request VMM to deploy relevant
hardware mitigations.
Use this virtualized MSR interface to request relevant hardware controls
for retpoline mitigation.
Signed-off-by: Pawan Gupta <[email protected]>
---
arch/x86/include/asm/msr-index.h | 23 +++++++++++++++++++++++
arch/x86/kernel/cpu/bugs.c | 24 ++++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 1143ac9400c3..1166b472377c 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -165,6 +165,7 @@
* IA32_XAPIC_DISABLE_STATUS MSR
* supported
*/
+#define ARCH_CAP_VIRTUAL_ENUM BIT(63) /* MSR_VIRTUAL_ENUMERATION supported */
#define MSR_IA32_FLUSH_CMD 0x0000010b
#define L1D_FLUSH BIT(0) /*
@@ -1062,6 +1063,28 @@
#define MSR_IA32_VMX_MISC_INTEL_PT (1ULL << 14)
#define MSR_IA32_VMX_MISC_VMWRITE_SHADOW_RO_FIELDS (1ULL << 29)
#define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE 0x1F
+
+/* Intel virtual MSRs */
+#define MSR_VIRTUAL_ENUMERATION 0x50000000
+#define VIRT_ENUM_MITIGATION_CTRL_SUPPORT BIT(0) /*
+ * Mitigation ctrl via virtual
+ * MSRs supported
+ */
+
+#define MSR_VIRTUAL_MITIGATION_ENUM 0x50000001
+#define MITI_ENUM_BHB_CLEAR_SEQ_S_SUPPORT BIT(0) /* VMM supports BHI_DIS_S */
+#define MITI_ENUM_RETPOLINE_S_SUPPORT BIT(1) /* VMM supports RRSBA_DIS_S */
+
+#define MSR_VIRTUAL_MITIGATION_CTRL 0x50000002
+#define MITI_CTRL_BHB_CLEAR_SEQ_S_USED BIT(0) /*
+ * Request VMM to deploy
+ * BHI_DIS_S mitigation
+ */
+#define MITI_CTRL_RETPOLINE_S_USED BIT(1) /*
+ * Request VMM to deploy
+ * RRSBA_DIS_S mitigation
+ */
+
/* AMD-V MSRs */
#define MSR_VM_CR 0xc0010114
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 3e3230cccaa7..a9e869f568ee 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1379,6 +1379,28 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
dump_stack();
}
+/* Speculation control using virtualized MSRs */
+static void __init spec_ctrl_setup_virtualized_msr(void)
+{
+ u64 msr_virt_enum, msr_mitigation_enum, msr_mitigation_ctrl;
+
+ if (!(x86_read_arch_cap_msr() & ARCH_CAP_VIRTUAL_ENUM))
+ return;
+
+ rdmsrl(MSR_VIRTUAL_ENUMERATION, msr_virt_enum);
+ if (!(msr_virt_enum & VIRT_ENUM_MITIGATION_CTRL_SUPPORT))
+ return;
+
+ rdmsrl(MSR_VIRTUAL_MITIGATION_ENUM, msr_mitigation_enum);
+ /* When retpoline is being used, request relevant hardware controls */
+ if (boot_cpu_has(X86_FEATURE_RETPOLINE) &&
+ msr_mitigation_enum & MITI_ENUM_RETPOLINE_S_SUPPORT) {
+ rdmsrl(MSR_VIRTUAL_MITIGATION_CTRL, msr_mitigation_ctrl);
+ msr_mitigation_ctrl |= MITI_CTRL_RETPOLINE_S_USED;
+ wrmsrl(MSR_VIRTUAL_MITIGATION_CTRL, msr_mitigation_ctrl);
+ }
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -1485,6 +1507,8 @@ static void __init spectre_v2_select_mitigation(void)
mode == SPECTRE_V2_RETPOLINE)
spec_ctrl_disable_kernel_rrsba();
+ spec_ctrl_setup_virtualized_msr();
+
spectre_v2_enabled = mode;
pr_info("%s\n", spectre_v2_strings[mode]);
--
2.25.1
On Sun, Dec 11, 2022 at 12:00:42AM +0800, Zhang Chen wrote:
> From: Pawan Gupta <[email protected]>
>
> Guests that have different family/model than the host may not be aware
> of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
> particularly true when guests migrate. To solve this problem Intel
> processors have added a virtual MSR interface through which guests can
> report their mitigation status and request VMM to deploy relevant
> hardware mitigations.
>
> Use this virtualized MSR interface to request relevant hardware controls
> for retpoline mitigation.
>
> Signed-off-by: Pawan Gupta <[email protected]>
> ---
> arch/x86/include/asm/msr-index.h | 23 +++++++++++++++++++++++
> arch/x86/kernel/cpu/bugs.c | 24 ++++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 1143ac9400c3..1166b472377c 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -165,6 +165,7 @@
> * IA32_XAPIC_DISABLE_STATUS MSR
> * supported
> */
> +#define ARCH_CAP_VIRTUAL_ENUM BIT(63) /* MSR_VIRTUAL_ENUMERATION supported */
>
> #define MSR_IA32_FLUSH_CMD 0x0000010b
> #define L1D_FLUSH BIT(0) /*
> @@ -1062,6 +1063,28 @@
> #define MSR_IA32_VMX_MISC_INTEL_PT (1ULL << 14)
> #define MSR_IA32_VMX_MISC_VMWRITE_SHADOW_RO_FIELDS (1ULL << 29)
> #define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE 0x1F
> +
> +/* Intel virtual MSRs */
> +#define MSR_VIRTUAL_ENUMERATION 0x50000000
> +#define VIRT_ENUM_MITIGATION_CTRL_SUPPORT BIT(0) /*
> + * Mitigation ctrl via virtual
> + * MSRs supported
> + */
> +
> +#define MSR_VIRTUAL_MITIGATION_ENUM 0x50000001
> +#define MITI_ENUM_BHB_CLEAR_SEQ_S_SUPPORT BIT(0) /* VMM supports BHI_DIS_S */
> +#define MITI_ENUM_RETPOLINE_S_SUPPORT BIT(1) /* VMM supports RRSBA_DIS_S */
> +
> +#define MSR_VIRTUAL_MITIGATION_CTRL 0x50000002
> +#define MITI_CTRL_BHB_CLEAR_SEQ_S_USED BIT(0) /*
> + * Request VMM to deploy
> + * BHI_DIS_S mitigation
> + */
> +#define MITI_CTRL_RETPOLINE_S_USED BIT(1) /*
> + * Request VMM to deploy
> + * RRSBA_DIS_S mitigation
> + */
> +
> /* AMD-V MSRs */
>
> #define MSR_VM_CR 0xc0010114
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 3e3230cccaa7..a9e869f568ee 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -1379,6 +1379,28 @@ static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
> dump_stack();
> }
>
> +/* Speculation control using virtualized MSRs */
> +static void __init spec_ctrl_setup_virtualized_msr(void)
> +{
> + u64 msr_virt_enum, msr_mitigation_enum, msr_mitigation_ctrl;
> +
> + if (!(x86_read_arch_cap_msr() & ARCH_CAP_VIRTUAL_ENUM))
> + return;
> +
> + rdmsrl(MSR_VIRTUAL_ENUMERATION, msr_virt_enum);
> + if (!(msr_virt_enum & VIRT_ENUM_MITIGATION_CTRL_SUPPORT))
> + return;
> +
> + rdmsrl(MSR_VIRTUAL_MITIGATION_ENUM, msr_mitigation_enum);
> + /* When retpoline is being used, request relevant hardware controls */
> + if (boot_cpu_has(X86_FEATURE_RETPOLINE) &&
> + msr_mitigation_enum & MITI_ENUM_RETPOLINE_S_SUPPORT) {
> + rdmsrl(MSR_VIRTUAL_MITIGATION_CTRL, msr_mitigation_ctrl);
> + msr_mitigation_ctrl |= MITI_CTRL_RETPOLINE_S_USED;
> + wrmsrl(MSR_VIRTUAL_MITIGATION_CTRL, msr_mitigation_ctrl);
> + }
> +}
> +
> static void __init spectre_v2_select_mitigation(void)
> {
> enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> @@ -1485,6 +1507,8 @@ static void __init spectre_v2_select_mitigation(void)
> mode == SPECTRE_V2_RETPOLINE)
> spec_ctrl_disable_kernel_rrsba();
>
> + spec_ctrl_setup_virtualized_msr();
I think this also needs to be called during secondary CPU
initialization.
> -----Original Message-----
> From: Pawan Gupta <[email protected]>
> Sent: Tuesday, December 13, 2022 4:24 AM
> To: Zhang, Chen <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; Gao,
> Chao <[email protected]>; Paolo Bonzini <[email protected]>;
> Christopherson,, Sean <[email protected]>; H. Peter Anvin
> <[email protected]>; Dave Hansen <[email protected]>; Borislav
> Petkov <[email protected]>; Ingo Molnar <[email protected]>; Thomas Gleixner
> <[email protected]>
> Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
> mitigations
>
> On Sun, Dec 11, 2022 at 12:00:42AM +0800, Zhang Chen wrote:
> > From: Pawan Gupta <[email protected]>
> >
> > Guests that have different family/model than the host may not be aware
> > of hardware mitigations(such as RRSBA_DIS_S) available on host. This
> > is particularly true when guests migrate. To solve this problem Intel
> > processors have added a virtual MSR interface through which guests can
> > report their mitigation status and request VMM to deploy relevant
> > hardware mitigations.
> >
> > Use this virtualized MSR interface to request relevant hardware
> > controls for retpoline mitigation.
> >
> > Signed-off-by: Pawan Gupta <[email protected]>
> > ---
> > arch/x86/include/asm/msr-index.h | 23 +++++++++++++++++++++++
> > arch/x86/kernel/cpu/bugs.c | 24 ++++++++++++++++++++++++
> > 2 files changed, 47 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h
> > b/arch/x86/include/asm/msr-index.h
> > index 1143ac9400c3..1166b472377c 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -165,6 +165,7 @@
> > *
> IA32_XAPIC_DISABLE_STATUS MSR
> > * supported
> > */
> > +#define ARCH_CAP_VIRTUAL_ENUM BIT(63) /*
> MSR_VIRTUAL_ENUMERATION supported */
> >
> > #define MSR_IA32_FLUSH_CMD 0x0000010b
> > #define L1D_FLUSH BIT(0) /*
> > @@ -1062,6 +1063,28 @@
> > #define MSR_IA32_VMX_MISC_INTEL_PT (1ULL << 14)
> > #define MSR_IA32_VMX_MISC_VMWRITE_SHADOW_RO_FIELDS (1ULL <<
> 29)
> > #define MSR_IA32_VMX_MISC_PREEMPTION_TIMER_SCALE 0x1F
> > +
> > +/* Intel virtual MSRs */
> > +#define MSR_VIRTUAL_ENUMERATION 0x50000000
> > +#define VIRT_ENUM_MITIGATION_CTRL_SUPPORT BIT(0) /*
> > + * Mitigation ctrl via
> virtual
> > + * MSRs supported
> > + */
> > +
> > +#define MSR_VIRTUAL_MITIGATION_ENUM 0x50000001
> > +#define MITI_ENUM_BHB_CLEAR_SEQ_S_SUPPORT BIT(0) /* VMM
> supports BHI_DIS_S */
> > +#define MITI_ENUM_RETPOLINE_S_SUPPORT BIT(1) /*
> VMM supports RRSBA_DIS_S */
> > +
> > +#define MSR_VIRTUAL_MITIGATION_CTRL 0x50000002
> > +#define MITI_CTRL_BHB_CLEAR_SEQ_S_USED BIT(0) /*
> > + * Request VMM to
> deploy
> > + * BHI_DIS_S
> mitigation
> > + */
> > +#define MITI_CTRL_RETPOLINE_S_USED BIT(1) /*
> > + * Request VMM to
> deploy
> > + * RRSBA_DIS_S
> mitigation
> > + */
> > +
> > /* AMD-V MSRs */
> >
> > #define MSR_VM_CR 0xc0010114
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 3e3230cccaa7..a9e869f568ee 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -1379,6 +1379,28 @@ static void __init
> spectre_v2_determine_rsb_fill_type_at_vmexit(enum spectre_v2_
> > dump_stack();
> > }
> >
> > +/* Speculation control using virtualized MSRs */ static void __init
> > +spec_ctrl_setup_virtualized_msr(void)
> > +{
> > + u64 msr_virt_enum, msr_mitigation_enum, msr_mitigation_ctrl;
> > +
> > + if (!(x86_read_arch_cap_msr() & ARCH_CAP_VIRTUAL_ENUM))
> > + return;
> > +
> > + rdmsrl(MSR_VIRTUAL_ENUMERATION, msr_virt_enum);
> > + if (!(msr_virt_enum & VIRT_ENUM_MITIGATION_CTRL_SUPPORT))
> > + return;
> > +
> > + rdmsrl(MSR_VIRTUAL_MITIGATION_ENUM, msr_mitigation_enum);
> > + /* When retpoline is being used, request relevant hardware controls
> */
> > + if (boot_cpu_has(X86_FEATURE_RETPOLINE) &&
> > + msr_mitigation_enum & MITI_ENUM_RETPOLINE_S_SUPPORT) {
> > + rdmsrl(MSR_VIRTUAL_MITIGATION_CTRL,
> msr_mitigation_ctrl);
> > + msr_mitigation_ctrl |= MITI_CTRL_RETPOLINE_S_USED;
> > + wrmsrl(MSR_VIRTUAL_MITIGATION_CTRL,
> msr_mitigation_ctrl);
> > + }
> > +}
> > +
> > static void __init spectre_v2_select_mitigation(void)
> > {
> > enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> @@
> > -1485,6 +1507,8 @@ static void __init spectre_v2_select_mitigation(void)
> > mode == SPECTRE_V2_RETPOLINE)
> > spec_ctrl_disable_kernel_rrsba();
> >
> > + spec_ctrl_setup_virtualized_msr();
>
> I think this also needs to be called during secondary CPU initialization.
Yes, we need setup virtual MSRs for each CPU.
I will add the " spec_ctrl_setup_virtualized_msr()" to the "start_secondary()" in the arch/x86/kernel/smpboot.c next version.
Thanks
Chen
On Sun, Dec 11, 2022, Zhang Chen wrote:
> From: Pawan Gupta <[email protected]>
>
> Guests that have different family/model than the host may not be aware
> of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
> particularly true when guests migrate. To solve this problem Intel
> processors have added a virtual MSR interface
Is there any actual "processor" support here? To me, this looks like Intel is
foisting a paravirt interface on KVM and other hypervisors without collaborating
with said hypervisors' developers and maintainers.
I get that some of the mitigations are vendor specific, but things like RETPOLINE
aren't vendor specific. I haven't followed all of the mitigation stuff very
closely, but I wouldn't be surprised if there are mitigations now or in the future
that are common across architectures, e.g. arm64 and x86-64. Intel doing its own
thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
multiple paravirt interfaces for very similar things, without having any control
over the APIs. That's all kinds of backwards.
And having to wait for Intel to roll out new documentation when software inevitably
comes up with some clever new mitigation doesn't exactly fill my heart with joy.
On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
>On Sun, Dec 11, 2022, Zhang Chen wrote:
>> From: Pawan Gupta <[email protected]>
>>
>> Guests that have different family/model than the host may not be aware
>> of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
>> particularly true when guests migrate. To solve this problem Intel
>> processors have added a virtual MSR interface
>
>Is there any actual "processor" support here?
No.
> To me, this looks like Intel is
>foisting a paravirt interface on KVM and other hypervisors without collaborating
>with said hypervisors' developers and maintainers.
>
>I get that some of the mitigations are vendor specific, but things like RETPOLINE
>aren't vendor specific. I haven't followed all of the mitigation stuff very
>closely, but I wouldn't be surprised if there are mitigations now or in the future
>that are common across architectures, e.g. arm64 and x86-64. Intel doing its own
>thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
>multiple paravirt interfaces for very similar things, without having any control
>over the APIs. That's all kinds of backwards.
But if the interface is defined by KVM rather than Intel, it will likely end up
with different interfaces for different VMMs, then Linux guest needs to support
all of them. And KVM needs to implement Hyper-V's and Xen's interface to support
Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and
complicates KVM/Linux in a similar way as multiple paravirt interfaces.
The use case of this paravirt interface is specific to Intel CPU microarchitecture.
Supporting multiple paravirt interfaces may not happen in the near future if there
is no use case for AMD and arm64.
>
>And having to wait for Intel to roll out new documentation when software inevitably
>comes up with some clever new mitigation doesn't exactly fill my heart with joy.
There should be some misunderstanding.
A bit for a software mitigation will be added if
1. the software mitigation works well on existing processors. And
2. there will be a new processor on which the software mitigation won't be
fully effective (due to some microarchiecture change).
IOW, the new documentation comes along with a new microarchitecture (new
processor) rather than software mitigations.
On Mon, Dec 19, 2022, Chao Gao wrote:
> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
> > To me, this looks like Intel is foisting a paravirt interface on KVM and other
> > hypervisors without collaborating with said hypervisors' developers and maintainers.
> >
> >I get that some of the mitigations are vendor specific, but things like RETPOLINE
> >aren't vendor specific. I haven't followed all of the mitigation stuff very
> >closely, but I wouldn't be surprised if there are mitigations now or in the future
> >that are common across architectures, e.g. arm64 and x86-64. Intel doing its own
> >thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
> >multiple paravirt interfaces for very similar things, without having any control
> >over the APIs. That's all kinds of backwards.
>
> But if the interface is defined by KVM rather than Intel, it will likely end up
> with different interfaces for different VMMs, then Linux guest needs to support
> all of them. And KVM needs to implement Hyper-V's and Xen's interface to support
> Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and
> complicates KVM/Linux in a similar way as multiple paravirt interfaces.
I never said the PV interfaces should be defined by KVM. I 100% agree that any
one hypervisor defining its own interface will suffer the same problem.
I think having a PV interface for coordinating mitigations between host and guest
is a great idea. What I don't like is tying the interface to "hardware" and defining
the interface without even trying to collaborate with others.
> The use case of this paravirt interface is specific to Intel CPU microarchitecture.
Well yeah, because the interface was designed only to work for Intel CPUs.
> Supporting multiple paravirt interfaces may not happen in the near future if there
> is no use case for AMD and arm64.
I'll take that bet. The vast majority of problems that are solved by PV interfaces
are common to all architectures and vendors, e.g. steal time, PV spinlocks, async
page faults, directed yield, confidential VMs (GHCB vs. GHCI), etc. I highly doubt
Intel is the only hardware vendor that will ever benefit from paravirtualizing
mitigations.
On Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote:
>On Mon, Dec 19, 2022, Chao Gao wrote:
>> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
>> > To me, this looks like Intel is foisting a paravirt interface on KVM and other
>> > hypervisors without collaborating with said hypervisors' developers and maintainers.
>> >
>> >I get that some of the mitigations are vendor specific, but things like RETPOLINE
>> >aren't vendor specific. I haven't followed all of the mitigation stuff very
>> >closely, but I wouldn't be surprised if there are mitigations now or in the future
>> >that are common across architectures, e.g. arm64 and x86-64. Intel doing its own
>> >thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
>> >multiple paravirt interfaces for very similar things, without having any control
>> >over the APIs. That's all kinds of backwards.
>>
>> But if the interface is defined by KVM rather than Intel, it will likely end up
>> with different interfaces for different VMMs, then Linux guest needs to support
>> all of them. And KVM needs to implement Hyper-V's and Xen's interface to support
>> Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and
>> complicates KVM/Linux in a similar way as multiple paravirt interfaces.
>
>I never said the PV interfaces should be defined by KVM. I 100% agree that any
>one hypervisor defining its own interface will suffer the same problem.
I am thinking there are only two options:
1. Intel defines the interface.
2. Every VMM defines its own interface.
Any middle ground between the two options?
>
>I think having a PV interface for coordinating mitigations between host and guest
>is a great idea. What I don't like is tying the interface to "hardware" and defining
Do you think something below is better than the intel-defined interface?
add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to enumerate
the interface. And add a new virtual MSR 0x4b564dxx for guest to report in-use
software mitigations and assign one bit for each software mitigation. On MSR
write emulation, call into vmx code to enable some hardware mitigations if
the corresponding software mitigations are not effective on host.
I am afraid it is late to switch to above approach because e.g., if Hyper-V
decides to support the intel-defined interface, KVM probably needs to support it
for Hyper-V guests.
Can we emulate IA32_ARCH_CAPABILITIES for AMD guests so that AMD can re-use
intel-defined interface?
>the interface without even trying to collaborate with others.
I will pass on this to related Intel folks and ask them to collaborate with
KVM community on future PV interfaces.
On Tue, Dec 20, 2022, Chao Gao wrote:
> On Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote:
> >On Mon, Dec 19, 2022, Chao Gao wrote:
> >> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
> >> > To me, this looks like Intel is foisting a paravirt interface on KVM and other
> >> > hypervisors without collaborating with said hypervisors' developers and maintainers.
> >> >
> >> >I get that some of the mitigations are vendor specific, but things like RETPOLINE
> >> >aren't vendor specific. I haven't followed all of the mitigation stuff very
> >> >closely, but I wouldn't be surprised if there are mitigations now or in the future
> >> >that are common across architectures, e.g. arm64 and x86-64. Intel doing its own
> >> >thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
> >> >multiple paravirt interfaces for very similar things, without having any control
> >> >over the APIs. That's all kinds of backwards.
> >>
> >> But if the interface is defined by KVM rather than Intel, it will likely end up
> >> with different interfaces for different VMMs, then Linux guest needs to support
> >> all of them. And KVM needs to implement Hyper-V's and Xen's interface to support
> >> Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and
> >> complicates KVM/Linux in a similar way as multiple paravirt interfaces.
> >
> >I never said the PV interfaces should be defined by KVM. I 100% agree that any
> >one hypervisor defining its own interface will suffer the same problem.
>
> I am thinking there are only two options:
>
> 1. Intel defines the interface.
> 2. Every VMM defines its own interface.
>
> Any middle ground between the two options?
Work with other x86 hardware vendors to define a common interface? Ask hypervisor
developers to define a common, extensible interface?
Maybe it turns out that it's impossible to abstract anything away and everything
ends up being vendor-specific anyways, but not even trying to provide a common
interace is extremely frustrating, especially since all this mitigation stuff has
been going on for ~5 years. There's been plenty of time to establish relationships
and points of contact.
> >I think having a PV interface for coordinating mitigations between host and guest
> >is a great idea. What I don't like is tying the interface to "hardware" and defining
>
> Do you think something below is better than the intel-defined interface?
No, KVM doing its own thing would only exacerbate the issue.
> add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to enumerate
> the interface. And add a new virtual MSR 0x4b564dxx for guest to report in-use
> software mitigations and assign one bit for each software mitigation. On MSR
> write emulation, call into vmx code to enable some hardware mitigations if
> the corresponding software mitigations are not effective on host.
>
> I am afraid it is late to switch to above approach because e.g., if Hyper-V
> decides to support the intel-defined interface, KVM probably needs to support it
> for Hyper-V guests.
Hence my frustration.
> -----Original Message-----
> From: Sean Christopherson <[email protected]>
> Sent: Friday, December 23, 2022 2:32 AM
> To: Gao, Chao <[email protected]>
> Cc: Zhang, Chen <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; Pawan Gupta
> <[email protected]>; Paolo Bonzini
> <[email protected]>; H. Peter Anvin <[email protected]>; Dave Hansen
> <[email protected]>; Borislav Petkov <[email protected]>; Ingo
> Molnar <[email protected]>; Thomas Gleixner <[email protected]>
> Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
> mitigations
>
> On Tue, Dec 20, 2022, Chao Gao wrote:
> > On Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote:
> > >On Mon, Dec 19, 2022, Chao Gao wrote:
> > >> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
> > >> > To me, this looks like Intel is foisting a paravirt interface on
> > >> > KVM and other hypervisors without collaborating with said hypervisors'
> developers and maintainers.
> > >> >
> > >> >I get that some of the mitigations are vendor specific, but things
> > >> >like RETPOLINE aren't vendor specific. I haven't followed all of
> > >> >the mitigation stuff very closely, but I wouldn't be surprised if
> > >> >there are mitigations now or in the future that are common across
> > >> >architectures, e.g. arm64 and x86-64. Intel doing its own thing
> > >> >means AMD and arm64 will likely follow suit, and suddenly KVM is
> > >> >supporting multiple paravirt interfaces for very similar things, without
> having any control over the APIs. That's all kinds of backwards.
> > >>
> > >> But if the interface is defined by KVM rather than Intel, it will
> > >> likely end up with different interfaces for different VMMs, then
> > >> Linux guest needs to support all of them. And KVM needs to
> > >> implement Hyper-V's and Xen's interface to support Hyper-V
> > >> enlightened and Xen enlightened guest. This is a _real_ problem and
> complicates KVM/Linux in a similar way as multiple paravirt interfaces.
> > >
> > >I never said the PV interfaces should be defined by KVM. I 100%
> > >agree that any one hypervisor defining its own interface will suffer the same
> problem.
> >
> > I am thinking there are only two options:
> >
> > 1. Intel defines the interface.
> > 2. Every VMM defines its own interface.
> >
> > Any middle ground between the two options?
>
> Work with other x86 hardware vendors to define a common interface? Ask
> hypervisor developers to define a common, extensible interface?
>
> Maybe it turns out that it's impossible to abstract anything away and
> everything ends up being vendor-specific anyways, but not even trying to
> provide a common interace is extremely frustrating, especially since all this
> mitigation stuff has been going on for ~5 years. There's been plenty of time to
> establish relationships and points of contact.
>
> > >I think having a PV interface for coordinating mitigations between
> > >host and guest is a great idea. What I don't like is tying the
> > >interface to "hardware" and defining
> >
> > Do you think something below is better than the intel-defined interface?
>
> No, KVM doing its own thing would only exacerbate the issue.
Hi Sean,
Rethink about it and synced with Chao, we didn't think of a better solution than
Intel-defined interface. If you have no more suggestions/comments here,
please review the rest of patches from this series when you have time.
I will try to address comments and push this series to RFC V2.
Thanks
Chen
>
> > add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to
> > enumerate the interface. And add a new virtual MSR 0x4b564dxx for
> > guest to report in-use software mitigations and assign one bit for
> > each software mitigation. On MSR write emulation, call into vmx code
> > to enable some hardware mitigations if the corresponding software
> mitigations are not effective on host.
> >
> > I am afraid it is late to switch to above approach because e.g., if
> > Hyper-V decides to support the intel-defined interface, KVM probably
> > needs to support it for Hyper-V guests.
>
> Hence my frustration.