Re: [PATCH] SVM: forbid guest to execute monitor/mwait

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Joerg Roedel wrote:
> On Thu, Mar 22, 2007 at 12:42:28PM +0200, Avi Kivity wrote:
>   
>> Joerg Roedel wrote:
>>     
>>> There is no danger for the host kernel but for the guest. If the
>>> userspace sets the monitor bit the guest will receive an #UD when trying
>>> to use it. And we don't want the guest to use it because it is not
>>> virtualized yet.
>>>  
>>>       
>> So, isn't a simpler fix not to set the monitor bit in cpuid?
>>
>> The patch is correct, but I don't see why it's needed as any guest will check the cpuid bit 
>> before using monitor.
>>     
>
> Right. But it is possible for userspace to enable monitor bit for the
> guest. Without virtualization of these 2 instructions the guest would
> idle in the guest state after calling mwait and prevent other processes
> and guests from running in that time. 

Won't an interrupt during mwait cause a vmexit?

> I don't think this is acceptable.
> And if we disable this bit in cpuid we should also prevent the
> guest from executing it to emulate the behavior of a real cpu in host
> mode.
> So I agree we should mask the cpuid monitor bit. The savest way to do so
> is in the kvm-amd module imho. And, also imho, we should the guest
> really forbid to execute it.
>   

I want to understand it exactly first.  I don't see any barrier to 
applying the patch, I just want a full understanding.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV