[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca0e9ac3-1f7b-cefb-a0fe-cc8e6f938c6c@redhat.com>
Date: Thu, 12 Apr 2018 22:21:51 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: "Raslan, KarimAllah" <karahmed@...zon.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Cc: "jmattson@...gle.com" <jmattson@...gle.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>
Subject: Re: [PATCH 1/2] X86/KVM: Properly restore 'tsc_offset' when running
an L2 guest
On 12/04/2018 19:21, Raslan, KarimAllah wrote:
> Now looking further at the code, it seems that everywhere in the code
> tsc_offset is treated as the L01 TSC_OFFSET.
>
> Like here:
>
> if (vmcs12->cpu_based_vm_exec_control &
> CPU_BASED_USE_TSC_OFFSETING)
> vmcs_write64(TSC_OFFSET,
> vcpu->arch.tsc_offset + vmcs12->tsc_offset);
>
> and here:
>
> vmcs_write64(TSC_OFFSET, vcpu->arch.tsc_offset);
>
> and here:
>
> u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc)
> {
> return vcpu->arch.tsc_offset + kvm_scale_tsc(vcpu, host_tsc);
> }
> EXPORT_SYMBOL_GPL(kvm_read_l1_tsc);
>
> ... would not it be simpler and more inline with the current code to
> just do what I did above + remove the "+ l1_tsc_offset" + probably
> document tsc_offset ?
Problem is, I don't think it's correct. :) A good start would be to try
disabling MSR_IA32_TSC interception in KVM, prepare a kvm-unit-tests
test that reads the MSR, and see if you get the host or guest TSC...
Paolo
Powered by blists - more mailing lists