From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm/ia64: Add printk support for kvm-intel modules. Date: Thu, 11 Sep 2008 11:12:59 +0300 Message-ID: <48C8D30B.9040008@qumranet.com> References: <42DFA526FC41B1429CE7279EF83C6BDC0196D6BB@pdsmsx415.ccr.corp.intel.com> <48C7E59C.2020000@qumranet.com> <42DFA526FC41B1429CE7279EF83C6BDC0196DC8D@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-ia64@vger.kernel.org, kvm@vger.kernel.org To: "Zhang, Xiantao" Return-path: Received: from il.qumranet.com ([212.179.150.194]:28948 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751787AbYIKIPY (ORCPT ); Thu, 11 Sep 2008 04:15:24 -0400 In-Reply-To: <42DFA526FC41B1429CE7279EF83C6BDC0196DC8D@pdsmsx415.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Zhang, Xiantao wrote: > >>> +static void vcpu_print_vmm_log(void) >>> +{ >>> + unsigned int slot; >>> + >>> + spin_lock(&vmm_log->log_lock); >>> >>> >> You're going to impact scalability with this. Are per-vcpu logs >> workable? >> > > OK, I will change it to per-vcpu style to avoid this possible > scalability issue. > > Actually, per-vcpu logs have a deficiency where log lines become unordered. So I suggest a per-vcpu flag that says "there may be something in the log", but keep a single log buffer. Since printk()s are rare (and slow), it's enough that we make the case where the log is empty fast. >> I suspect this will start breaking when people start using the new >> printk("%pBLAH") functionality, which will require linking additional >> files. >> > > If the format string works with vsnprintf, it should be covered. > > vsnprintf() may start to be linked with other stuff. Well, we'll deal with that when it happens. >> I can't think of a way on x86, but maybe ia64 varargs are different. >> >> (worst case you can limit the number of arguments and just copy a >> bunch of stack). >> > > That maybe infeasible, since some args may be transferred by pointer, > and this pointer can't be reached in host side. > Okay. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.