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 <mtosatti@xxxxxxxxxx> >> >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
