On Tue, Dec 02, 2008 at 02:23:52PM +0200, Avi Kivity wrote:
> Luis Henriques wrote:
>> On Sun, Nov 30, 2008 at 10:44:55PM +0200, Avi Kivity wrote:
>>   
>>> Luis Henriques wrote:
>>>     
>>>> No, I was not able to reproduce the issue.  Please let me know if you need 
>>>> some
>>>> more information on my system (.config, for instance).
>>>>         
>>> Were you using some other virtualization product?  Were you running   
>>> suspend/resume?
>>>     
>>
>> No for both questions.  However, I had compiled support for suspend (not 
>> sure if
>> this is what you mean by "running suspend/resume") - This is a feature I used
>> only once or twice...
>>   
>
> The underlying problem is that an svm instruction has been executed, but  
> svm is disabled.  Since kvm enables svm unconditionally on all  
> processors on startup, there are only a few paths that can potentially  
> trigger this:
>
> - another virtualization module turned svm off
> - cpu hotadd/hotremove (suspend/resume triggers this)
> - something did a read-modify-write cycle on cr4 (which contains the svm  
> enable bit) while kvm enabled that bit
> - core was turned off (does linux power management do that?)
>
> Anything ring a bell?

Ok, I am not sure but there is a possibility of having the vboxdrv driver
loaded. _But_ I was not using, i.e., I do not use VirtualBox.  In my
attempts to reproduce the issue, I tried to load this module but, unfortunatly,
my distro has this package broken ATM (err... in fact, the problem is not the
distro but me - I am using an unstable version).

vboxdrv could be a problem if I was using it, but I believe it shouldn't cause
this if it is not being used... but it's just a guess.

-- 
Luis Henriques

--
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

Reply via email to