Eric W. Biederman wrote:
> Avi Kivity <avi at redhat.com> writes:
>
>
>> Eric W. Biederman wrote:
>>
>>> Most of the reason I was wondering is that the cpu hardware probing
>>> largely seems to be a duplicate of what we have in the core for
>>> probing cpu capabilities already, and could likely be made smaller
>>> by building upon the existing codebase.
>>>
>>>
>>>
>> We use the core cpuid functions, or are you referring to something else?
>>
>
> I was referring to the arch/x86/kernel/cpu/*
> and arch/x86/include/asm/cpufeature.h
>
> The core functions that are responsible for detecting all of the cpu features,
> and disabling them if there are cpu errata.
>
> The usual pattern is that code does all of the magic detection logic and
> then the code that would use it would just need to test: cpu_has_vmx or cpu_has_svm.
>
>
vmx is much more complicated than that, with some features define in
read-only msrs.
> At least in part that allows us to show the working cpu features in /proc/cpuinfo.
>
>
Yes that's a problem now; you can only tell if you have vmx or not,
without any information as to the various vmx subfeatures.
> Cool. I forget if we have to test for EFER on 32bit, or if we can just wrmsr
> and be done with it. Regardless that sounds easy to do on the kexec path.
>
if (cpu_has_svm())
disable_svme();
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
