search for: msr_tsc_adjust

...ruct vcpu *v, u64 guest_tsc) { uint64_t tsc; + uint64_t delta_tsc; if ( v->domain->arch.vtsc ) { @@ -255,10 +256,23 @@ rdtscll(tsc); } - v->arch.hvm_vcpu.cache_tsc_offset = guest_tsc - tsc; + delta_tsc = guest_tsc - tsc; + + v->arch.hvm_vcpu.msr_tsc_adjust += delta_tsc + - v->arch.hvm_vcpu.cache_tsc_offset; + v->arch.hvm_vcpu.cache_tsc_offset = delta_tsc; + hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset); } +void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust) +{ + v->arch.hvm...

...PoS firmware people put on it. > > Ever since Nehalem TSC is stable (unless you get to >4 socket systems, > after which it still can be, but bets are off). But even relatively > recent systems fail the TSC sync test because firmware messes it up by > writing to either MSR_TSC or MSR_TSC_ADJUST. > > But the thing is, if the TSC is not synced, you cannot use it for > timekeeping, full stop. So having a single page is fine, it either > contains a mult/shift that is valid, or it indicates TSC is messed up > and you fall back to something else. > > There is no inbetween...

...PoS firmware people put on it. > > Ever since Nehalem TSC is stable (unless you get to >4 socket systems, > after which it still can be, but bets are off). But even relatively > recent systems fail the TSC sync test because firmware messes it up by > writing to either MSR_TSC or MSR_TSC_ADJUST. > > But the thing is, if the TSC is not synced, you cannot use it for > timekeeping, full stop. So having a single page is fine, it either > contains a mult/shift that is valid, or it indicates TSC is messed up > and you fall back to something else. > > There is no inbetween...

Marcelo Tosatti <mtosatti at redhat.com> writes: > On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: >> >> There is a very long history of different (hardware) issues Marcelo was >> fighting with and the current code is the survived Frankenstein. > > Right, the code has to handle different TSC modes. > >> E.g. it >> is very, very

Marcelo Tosatti <mtosatti at redhat.com> writes: > On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: >> >> There is a very long history of different (hardware) issues Marcelo was >> fighting with and the current code is the survived Frankenstein. > > Right, the code has to handle different TSC modes. > >> E.g. it >> is very, very

...stly), it is the frigging PoS firmware people put on it. Ever since Nehalem TSC is stable (unless you get to >4 socket systems, after which it still can be, but bets are off). But even relatively recent systems fail the TSC sync test because firmware messes it up by writing to either MSR_TSC or MSR_TSC_ADJUST. But the thing is, if the TSC is not synced, you cannot use it for timekeeping, full stop. So having a single page is fine, it either contains a mult/shift that is valid, or it indicates TSC is messed up and you fall back to something else. There is no inbetween there. For sched_clock we can sti...

...on it. > > > > Ever since Nehalem TSC is stable (unless you get to >4 socket systems, > > after which it still can be, but bets are off). But even relatively > > recent systems fail the TSC sync test because firmware messes it up by > > writing to either MSR_TSC or MSR_TSC_ADJUST. > > > > But the thing is, if the TSC is not synced, you cannot use it for > > timekeeping, full stop. So having a single page is fine, it either > > contains a mult/shift that is valid, or it indicates TSC is messed up > > and you fall back to something else. > &g...

...> >>> Ever since Nehalem TSC is stable (unless you get to >4 socket systems, >>> after which it still can be, but bets are off). But even relatively >>> recent systems fail the TSC sync test because firmware messes it up by >>> writing to either MSR_TSC or MSR_TSC_ADJUST. >>> >>> But the thing is, if the TSC is not synced, you cannot use it for >>> timekeeping, full stop. So having a single page is fine, it either >>> contains a mult/shift that is valid, or it indicates TSC is messed up >>> and you fall back to somethin...

...> >>> Ever since Nehalem TSC is stable (unless you get to >4 socket systems, >>> after which it still can be, but bets are off). But even relatively >>> recent systems fail the TSC sync test because firmware messes it up by >>> writing to either MSR_TSC or MSR_TSC_ADJUST. >>> >>> But the thing is, if the TSC is not synced, you cannot use it for >>> timekeeping, full stop. So having a single page is fine, it either >>> contains a mult/shift that is valid, or it indicates TSC is messed up >>> and you fall back to somethin...