On 03.10.2010, at 10:35, Nadav Har'El wrote: > On Sun, Oct 03, 2010, Alexander Graf wrote about "Re: TSC in nested SVM and VMX": >> Looking through the spec, the only indicator I've found is this passage: >> >> TSC_OFFSET - an offset to add when the guest reads the TSC (time stamp >> counter). Guest writes to the TSC can be intercepted and emulated by >> changing the offset (without writing the physical TSC). This offset is >> cleared when the guest exits back to the host. >> >> So apparently writes to TSC don't affect tsc_offset, but instead affect >> the host's tsc skew. So with nesting a non-intercepted tsc write affects >> L1's tsc_offset. This means the code is correct. Sorry for the fuss :). > > I don't understand, how does this passage imply that writes to the TSC don't > affect the tsc_offset? It says that "writes to the TSC" can (I don't know why > this word was used...) "changing the offset". I don't understand why a guest > should be allowed to ruin its host's TSC (or in the nested case, why an L2 > should be allowed to ruin L1's TSC without L1's knowledge) - isn't this > exactly why the TSC offset exists? Yes, it is. But because except for that passage no other indication exists that tsc_offset gets changed by a tsc write, it probably won't happen. Also, L2 affecting the host's TSC can make sense at times. Hyper-V for example runs its Dom0 inside of a VM context. If that wants to change the system's tsc offset, it should be allowed to, no? Unless the hypervisor wants to use the TSC too of course - in which case hell breaks lose. Alex -- 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
