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