Rusty Russell wrote:
> On Tue, 2007-07-24 at 13:19 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
>>> --- a/drivers/kvm/kvm_main.c        Tue Jul 24 16:22:39 2007 +1000
>>> +++ b/drivers/kvm/kvm_main.c        Tue Jul 24 16:28:33 2007 +1000
>>> @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
>>>     va_list args;
>>>  
>>>     va_start(args, why_fmt);
>>> -   printk(KERN_DEBUG "kvm: #GP ");
>>> -   vprintk(why_fmt, args);
>>> +   if (pr_guest(vcpu, "#GP "))
>>> +           vprintk(why_fmt, args);
>>>     va_end(args);
>>>     kvm_arch_ops->inject_gp(vcpu, 0);
>>>  }
>>>   
>>>       
>> Why go through this optimization?  If it happens frequently, we can just 
>> remove the printk().  The printk()s are mostly on not-expected-to-happen 
>> exceptions, and should just be removed if guests do exercise them.
>>     
>
> It's not an optimization, just being thorough.  It raises it to
> KERN_WARN and makes it a common format.  Importantly there should be no
> unlimited printks which can be triggered by the guest.
>
> KVM *will* be used to run malicious guests.  That's going to be hard to
> lock down later, so I figure we should start now.

There's no reason to make this KERN_WARN.  There's nothing wrong with 
the host, and there may not be anything wrong with the guest.  These are 
only used to see if the guest did something unexpected, which may or may 
not be a problem (a kvm test suite would certainly trigger them).

Perhaps we should make them conditional on a debug flag, or remove them 
completely.  Most of them don't ever trigger, and i don't expect we can 
bring up a new guest solely using these printks.


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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to