[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kexec
Subject:    [PATCH 0/2] kvm: disable virtualization on kdump
From:       avi () redhat ! com (Avi Kivity)
Date:       2008-10-30 7:52:17
Message-ID: 490967B1.3040209 () redhat ! com
[Download RAW message or body]

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.



[prev in list] [next in list] [prev in thread] [next in thread]