early_init_amd() is called on all AMD processors, both 64 and 32 bit.
Presently 32 bit processors get the X86_FEATURE_VMMCALL feature set, which
they do not support. Add conditionals to restrict it to 64 bit processors.
Cc: Paolo Bonzini <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
---
arch/x86/kernel/cpu/amd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 38915fbfae73..df06919324cd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -662,12 +662,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
}
#endif
+#ifdef CONFIG_X86_64
/*
* This is only needed to tell the kernel whether to use VMCALL
* and VMMCALL. VMMCALL is never executed except under virt, so
* we can set it unconditionally.
*/
set_cpu_cap(c, X86_FEATURE_VMMCALL);
+#endif
/* F16h erratum 793, CVE-2013-6885 */
if (c->x86 == 0x16 && c->x86_model <= 0xf)
--
2.16.1
On 30/07/2018 21:40, Matthew Whitehead wrote:
> early_init_amd() is called on all AMD processors, both 64 and 32 bit.
> Presently 32 bit processors get the X86_FEATURE_VMMCALL feature set, which
> they do not support. Add conditionals to restrict it to 64 bit processors.
This shouldn't be necessary; for systems that don't have virtualization
extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
But it is also wrong, because you can run a 32-bit kernel as a guest on
a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
the processor has the vmmcall instruction and not Intel's vmcall.
Thanks,
Paolo
> Cc: Paolo Bonzini <[email protected]>
> Signed-off-by: Matthew Whitehead <[email protected]>
> ---
> arch/x86/kernel/cpu/amd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 38915fbfae73..df06919324cd 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -662,12 +662,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
> }
> #endif
>
> +#ifdef CONFIG_X86_64
> /*
> * This is only needed to tell the kernel whether to use VMCALL
> * and VMMCALL. VMMCALL is never executed except under virt, so
> * we can set it unconditionally.
> */
> set_cpu_cap(c, X86_FEATURE_VMMCALL);
> +#endif
>
> /* F16h erratum 793, CVE-2013-6885 */
> if (c->x86 == 0x16 && c->x86_model <= 0xf)
>
>
> This shouldn't be necessary; for systems that don't have virtualization
> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
>
> But it is also wrong, because you can run a 32-bit kernel as a guest on
> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
> the processor has the vmmcall instruction and not Intel's vmcall.
>
Paolo,
I'm running this on a bare metal machine (no virtualization) with a
32-bit AMD i486 class cpu. Should the feature be showing up in
/proc/cpuinfo under the 'flags' line? It does on my machine, and it
looked wrong to me.
- Matthew
On 31/07/2018 14:57, tedheadster wrote:
>>
>> This shouldn't be necessary; for systems that don't have virtualization
>> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
>>
>> But it is also wrong, because you can run a 32-bit kernel as a guest on
>> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
>> the processor has the vmmcall instruction and not Intel's vmcall.
>>
>
> Paolo,
> I'm running this on a bare metal machine (no virtualization) with a
> 32-bit AMD i486 class cpu. Should the feature be showing up in
> /proc/cpuinfo under the 'flags' line? It does on my machine, and it
> looked wrong to me.
It's a bit silly, but it's not particularly wrong.
Paolo
On Tue, Jul 31, 2018 at 9:00 AM Paolo Bonzini <[email protected]> wrote:
>
> On 31/07/2018 14:57, tedheadster wrote:
> >>
> >> This shouldn't be necessary; for systems that don't have virtualization
> >> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
> >>
> >> But it is also wrong, because you can run a 32-bit kernel as a guest on
> >> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
> >> the processor has the vmmcall instruction and not Intel's vmcall.
> >>
> >
> > Paolo,
> > I'm running this on a bare metal machine (no virtualization) with a
> > 32-bit AMD i486 class cpu. Should the feature be showing up in
> > /proc/cpuinfo under the 'flags' line? It does on my machine, and it
> > looked wrong to me.
>
> It's a bit silly, but it's not particularly wrong.
Why is there even a specific feature flag for VMMCALL? Isn't
X86_FEATURE_SVM sufficient to differentiate which opcode to use?
--
Brian Gerst
On 01/08/2018 17:21, Brian Gerst wrote:
> On Tue, Jul 31, 2018 at 9:00 AM Paolo Bonzini <[email protected]> wrote:
>>
>> On 31/07/2018 14:57, tedheadster wrote:
>>>>
>>>> This shouldn't be necessary; for systems that don't have virtualization
>>>> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
>>>>
>>>> But it is also wrong, because you can run a 32-bit kernel as a guest on
>>>> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL because
>>>> the processor has the vmmcall instruction and not Intel's vmcall.
>>>>
>>>
>>> Paolo,
>>> I'm running this on a bare metal machine (no virtualization) with a
>>> 32-bit AMD i486 class cpu. Should the feature be showing up in
>>> /proc/cpuinfo under the 'flags' line? It does on my machine, and it
>>> looked wrong to me.
>>
>> It's a bit silly, but it's not particularly wrong.
>
> Why is there even a specific feature flag for VMMCALL? Isn't
> X86_FEATURE_SVM sufficient to differentiate which opcode to use?
No, X86_FEATURE_SVM is there in the host while X86_FEATURE_VMMCALL is
used in the guest.
Paolo