Eric W. Biederman wrote:
Avi Kivity <[EMAIL PROTECTED]> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
