On 10/29/2012 10:45 PM, Marcelo Tosatti wrote:
> On Mon, Oct 29, 2012 at 07:04:59PM +0400, Glauber Costa wrote:
>> On 10/24/2012 05:13 PM, Marcelo Tosatti wrote:
>>> Allow the caller to pass host tsc value to kvm_x86_ops->read_l1_tsc().
>>>
>>> Signed-off-by: Marcelo Tosatti
>>
>> Would you mind explaining why?
>>
>> it seems to me that rdtscll() here would be perfectly safe: the only
>> case in which they wouldn't, is in a nested-vm environment running
>> paravirt-linux with a paravirt tsc. In this case, it is quite likely
>> that we'll want rdtscll *anyway*, instead of going to tsc directly.
>
> Its something different (from a future patch):
>
> "KVM added a global variable to guarantee monotonicity in the guest.
> One of the reasons for that is that the time between
>
> 1. ktime_get_ts(×pec);
> 2. rdtscll(tsc);
>
> Is variable. That is, given a host with stable TSC, suppose that
> two VCPUs read the same time via ktime_get_ts() above.
>
> The time required to execute 2. is not the same on those two instances
> executing in different VCPUS (cache misses, interrupts...)."
>
>
> Think step 1. returning the same value on both vcpus (to read the
> explanation above).
>
This still doesn't go the core of the question. You are replacing
rdtscll with native_read_tsc(). They are equivalent most of the time for
the host (except in the case I outlined). So the logic you exposed, is
valid for both. But the real problem is another one:
Although I am not very skilled in C, I rock in the Logo programming
language (http://en.wikipedia.org/wiki/Logo_(programming_language) ),
and with that knowledge, I can understand your C code - with a bit of
effort. After reading it, it becomes very clear that what you do is
"Allow the caller to pass host tsc value to kvm_x86_ops->read_l1_tsc",
so your changelog doesn't really add any data. It would be great if it
explained us, readers, why instead of what!
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
