| Message ID | 20200917110723.820666-2-mlevitsk@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: correctly restore the TSC value on nested migration | expand |
On Thu, Sep 17, 2020 at 02:07:23PM +0300, Maxim Levitsky wrote: > MSR reads/writes should always access the L1 state, since the (nested) > hypervisor should intercept all the msrs it wants to adjust, and these > that it doesn't should be read by the guest as if the host had read it. > > However IA32_TSC is an exception.Even when not intercepted, guest still Missing a space after the period. > reads the value + TSC offset. > The write however does not take any TSC offset in the account. s/in the/into > This is documented in Intel's PRM and seems also to happen on AMD as well. Ideally we'd get confirmation from AMD that this is the correct behavior. > This creates a problem when userspace wants to read the IA32_TSC value and then > write it. (e.g for migration) > > In this case it reads L2 value but write is interpreted as an L1 value. It _may_ read the L2 value, e.g. it's not going to read the L2 value if L1 is active. > To fix this make the userspace initiated reads of IA32_TSC return L1 value > as well. > > Huge thanks to Dave Gilbert for helping me understand this very confusing > semantic of MSR writes. > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > --- > arch/x86/kvm/x86.c | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 17f4995e80a7e..d10d5c6add359 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -2025,6 +2025,11 @@ u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) > } > EXPORT_SYMBOL_GPL(kvm_read_l1_tsc); > > +static u64 kvm_read_l2_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) This is definitely not L2 specific. I would vote to just omit the helper so that we don't need to come up with a name that is correct across the board, e.g. "raw" is also not quite correct. An alternative would be to do: u64 tsc_offset = msr_info->host_initiated ? vcpu->arch.l1_tsc_offset : vcpu->arch.tsc_offset; msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + tsc_offset; Which I kind of like because the behavioral difference is a bit more obvious. > +{ > + return vcpu->arch.tsc_offset + kvm_scale_tsc(vcpu, host_tsc); > +} > + > static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > { > vcpu->arch.l1_tsc_offset = offset; > @@ -3220,7 +3225,19 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > msr_info->data = vcpu->arch.msr_ia32_power_ctl; > break; > case MSR_IA32_TSC: > - msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + vcpu->arch.tsc_offset; > + /* > + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset > + * even when not intercepted. AMD manual doesn't define this > + * but appears to behave the same > + * > + * However when userspace wants to read this MSR, return its > + * real L1 value so that its restore will be correct > + * Extra line is unnecessary. > + */ > + if (msr_info->host_initiated) > + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); > + else > + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); > break; > case MSR_MTRRcap: > case 0x200 ... 0x2ff: > -- > 2.26.2 >
On Thu, Sep 17, 2020 at 02:07:23PM +0300, Maxim Levitsky wrote: > + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset One more nit, "Intel SDM" would be preferred as that's most commonly used in KVM changelogs, and there are multiple PRM acronyms in Intel's dictionary these days. > + * even when not intercepted. AMD manual doesn't define this > + * but appears to behave the same > + * > + * However when userspace wants to read this MSR, return its > + * real L1 value so that its restore will be correct > + * > + */ > + if (msr_info->host_initiated) > + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); > + else > + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); > break; > case MSR_MTRRcap: > case 0x200 ... 0x2ff: > -- > 2.26.2 >
On Thu, 2020-09-17 at 09:11 -0700, Sean Christopherson wrote: > On Thu, Sep 17, 2020 at 02:07:23PM +0300, Maxim Levitsky wrote: > > MSR reads/writes should always access the L1 state, since the (nested) > > hypervisor should intercept all the msrs it wants to adjust, and these > > that it doesn't should be read by the guest as if the host had read it. > > > > However IA32_TSC is an exception.Even when not intercepted, guest still > > Missing a space after the period. Fixed > > > reads the value + TSC offset. > > The write however does not take any TSC offset in the account. > > s/in the/into Fixed. > > > This is documented in Intel's PRM and seems also to happen on AMD as well. > > Ideally we'd get confirmation from AMD that this is the correct behavior. It would be great. This isn't a blocker for this patch however since I didn't change the current emulation behavier which already assumes this. Also we don't really trap TSC reads, so this code isn't really executed. (I haven't checked what corner cases when we do this. It can happen in theory, if MSR read is done from the emulator or something like that). > > > This creates a problem when userspace wants to read the IA32_TSC value and then > > write it. (e.g for migration) > > > > In this case it reads L2 value but write is interpreted as an L1 value. > > It _may_ read the L2 value, e.g. it's not going to read the L2 value if L1 > is active. I didn't thought about this this way. I guess I always thought that L2 is, L2 if L2 is running, otherwise L1, but now I understand what you mean, and I agree. > > > To fix this make the userspace initiated reads of IA32_TSC return L1 value > > as well. > > > > Huge thanks to Dave Gilbert for helping me understand this very confusing > > semantic of MSR writes. > > > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > --- > > arch/x86/kvm/x86.c | 19 ++++++++++++++++++- > > 1 file changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 17f4995e80a7e..d10d5c6add359 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -2025,6 +2025,11 @@ u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) > > } > > EXPORT_SYMBOL_GPL(kvm_read_l1_tsc); > > > > +static u64 kvm_read_l2_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) > > This is definitely not L2 specific. I would vote to just omit the helper so > that we don't need to come up with a name that is correct across the board, > e.g. "raw" is also not quite correct. Yes, now I see this. > > An alternative would be to do: > > u64 tsc_offset = msr_info->host_initiated ? vcpu->arch.l1_tsc_offset : > vcpu->arch.tsc_offset; > > msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + tsc_offset; > > Which I kind of like because the behavioral difference is a bit more obvious. Yep did that. The onl minor downside is that I need a C scope in the switch block. I can add kvm_read_tsc but I think that this is not worth it. > > > +{ > > + return vcpu->arch.tsc_offset + kvm_scale_tsc(vcpu, host_tsc); > > +} > > + > > static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > > { > > vcpu->arch.l1_tsc_offset = offset; > > @@ -3220,7 +3225,19 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > msr_info->data = vcpu->arch.msr_ia32_power_ctl; > > break; > > case MSR_IA32_TSC: > > - msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + vcpu->arch.tsc_offset; > > + /* > > + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset > > + * even when not intercepted. AMD manual doesn't define this > > + * but appears to behave the same > > + * > > + * However when userspace wants to read this MSR, return its > > + * real L1 value so that its restore will be correct > > + * > > Extra line is unnecessary. This is a bit of my OCD :-) I don't mind to remove it. > > > + */ > > + if (msr_info->host_initiated) > > + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); > > + else > > + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); > > break; > > case MSR_MTRRcap: > > case 0x200 ... 0x2ff: > > -- > > 2.26.2 > > Thanks for the review, the V2 is on the way. Best regards, Maxim Levitsky
On Thu, 2020-09-17 at 09:14 -0700, Sean Christopherson wrote: > On Thu, Sep 17, 2020 at 02:07:23PM +0300, Maxim Levitsky wrote: > > + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset > > One more nit, "Intel SDM" would be preferred as that's most commonly used in > KVM changelogs, and there are multiple PRM acronyms in Intel's dictionary > these days. Fixed. Best regards, Maxim Levitsky > > > + * even when not intercepted. AMD manual doesn't define this > > + * but appears to behave the same > > + * > > + * However when userspace wants to read this MSR, return its > > + * real L1 value so that its restore will be correct > > + * > > + */ > > + if (msr_info->host_initiated) > > + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); > > + else > > + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); > > break; > > case MSR_MTRRcap: > > case 0x200 ... 0x2ff: > > -- > > 2.26.2 > >
On Mon, 2020-09-21 at 12:25 +0300, Maxim Levitsky wrote: > On Thu, 2020-09-17 at 09:11 -0700, Sean Christopherson wrote: > > On Thu, Sep 17, 2020 at 02:07:23PM +0300, Maxim Levitsky wrote: > > > MSR reads/writes should always access the L1 state, since the (nested) > > > hypervisor should intercept all the msrs it wants to adjust, and these > > > that it doesn't should be read by the guest as if the host had read it. > > > > > > However IA32_TSC is an exception.Even when not intercepted, guest still > > > > Missing a space after the period. > Fixed > > > reads the value + TSC offset. > > > The write however does not take any TSC offset in the account. > > > > s/in the/into > Fixed. > > > This is documented in Intel's PRM and seems also to happen on AMD as well. > > > > Ideally we'd get confirmation from AMD that this is the correct behavior. > It would be great. This isn't a blocker for this patch however since I didn't > change the current emulation behavier which already assumes this. > Also we don't really trap TSC reads, so this code isn't really executed. I did now find out an explict mention that AMD's TSC scaling affects the MSR reads, and while this doesn't expictily mention the offset, this does give more ground to the assumption that the offset is added as well. "Writing to the TSC Ratio MSR allows the hypervisor to control the guest's view of the Time Stamp Counter. The contents of TSC Ratio MSR sets the value of the TSCRatio. This constant scales the timestamp value returned when the TSC is read by a guest via the RDTSC or RDTSCP instructions or when the TSC, MPERF, or MPerfReadOnly MSRs are read via the RDMSR instruction by a guest running under virtualization." Best regards, Maxim Levitsky > > (I haven't checked what corner cases when we do this. It can happen in theory, > if MSR read is done from the emulator or something like that). > > > > This creates a problem when userspace wants to read the IA32_TSC value and then > > > write it. (e.g for migration) > > > > > > In this case it reads L2 value but write is interpreted as an L1 value. > > > > It _may_ read the L2 value, e.g. it's not going to read the L2 value if L1 > > is active. > > I didn't thought about this this way. I guess I always thought that L2 is, > L2 if L2 is running, otherwise L1, but now I understand what you mean, > and I agree. > > > > To fix this make the userspace initiated reads of IA32_TSC return L1 value > > > as well. > > > > > > Huge thanks to Dave Gilbert for helping me understand this very confusing > > > semantic of MSR writes. > > > > > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > > --- > > > arch/x86/kvm/x86.c | 19 ++++++++++++++++++- > > > 1 file changed, 18 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > index 17f4995e80a7e..d10d5c6add359 100644 > > > --- a/arch/x86/kvm/x86.c > > > +++ b/arch/x86/kvm/x86.c > > > @@ -2025,6 +2025,11 @@ u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) > > > } > > > EXPORT_SYMBOL_GPL(kvm_read_l1_tsc); > > > > > > +static u64 kvm_read_l2_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) > > > > This is definitely not L2 specific. I would vote to just omit the helper so > > that we don't need to come up with a name that is correct across the board, > > e.g. "raw" is also not quite correct. > Yes, now I see this. > > > An alternative would be to do: > > > > u64 tsc_offset = msr_info->host_initiated ? vcpu->arch.l1_tsc_offset : > > vcpu->arch.tsc_offset; > > > > msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + tsc_offset; > > > > Which I kind of like because the behavioral difference is a bit more obvious. > Yep did that. The onl minor downside is that I need a C scope in the switch block. > I can add kvm_read_tsc but I think that this is not worth it. > > > > +{ > > > + return vcpu->arch.tsc_offset + kvm_scale_tsc(vcpu, host_tsc); > > > +} > > > + > > > static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) > > > { > > > vcpu->arch.l1_tsc_offset = offset; > > > @@ -3220,7 +3225,19 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > > msr_info->data = vcpu->arch.msr_ia32_power_ctl; > > > break; > > > case MSR_IA32_TSC: > > > - msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + vcpu->arch.tsc_offset; > > > + /* > > > + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset > > > + * even when not intercepted. AMD manual doesn't define this > > > + * but appears to behave the same > > > + * > > > + * However when userspace wants to read this MSR, return its > > > + * real L1 value so that its restore will be correct > > > + * > > > > Extra line is unnecessary. > This is a bit of my OCD :-) I don't mind to remove it. > > > + */ > > > + if (msr_info->host_initiated) > > > + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); > > > + else > > > + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); > > > break; > > > case MSR_MTRRcap: > > > case 0x200 ... 0x2ff: > > > -- > > > 2.26.2 > > > > > Thanks for the review, the V2 is on the way. > Best regards, > Maxim Levitsky >
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 17f4995e80a7e..d10d5c6add359 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2025,6 +2025,11 @@ u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) } EXPORT_SYMBOL_GPL(kvm_read_l1_tsc); +static u64 kvm_read_l2_tsc(struct kvm_vcpu *vcpu, u64 host_tsc) +{ + return vcpu->arch.tsc_offset + kvm_scale_tsc(vcpu, host_tsc); +} + static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu *vcpu, u64 offset) { vcpu->arch.l1_tsc_offset = offset; @@ -3220,7 +3225,19 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) msr_info->data = vcpu->arch.msr_ia32_power_ctl; break; case MSR_IA32_TSC: - msr_info->data = kvm_scale_tsc(vcpu, rdtsc()) + vcpu->arch.tsc_offset; + /* + * Intel PRM states that MSR_IA32_TSC read adds the TSC offset + * even when not intercepted. AMD manual doesn't define this + * but appears to behave the same + * + * However when userspace wants to read this MSR, return its + * real L1 value so that its restore will be correct + * + */ + if (msr_info->host_initiated) + msr_info->data = kvm_read_l1_tsc(vcpu, rdtsc()); + else + msr_info->data = kvm_read_l2_tsc(vcpu, rdtsc()); break; case MSR_MTRRcap: case 0x200 ... 0x2ff:
MSR reads/writes should always access the L1 state, since the (nested) hypervisor should intercept all the msrs it wants to adjust, and these that it doesn't should be read by the guest as if the host had read it. However IA32_TSC is an exception.Even when not intercepted, guest still reads the value + TSC offset. The write however does not take any TSC offset in the account. This is documented in Intel's PRM and seems also to happen on AMD as well. This creates a problem when userspace wants to read the IA32_TSC value and then write it. (e.g for migration) In this case it reads L2 value but write is interpreted as an L1 value. To fix this make the userspace initiated reads of IA32_TSC return L1 value as well. Huge thanks to Dave Gilbert for helping me understand this very confusing semantic of MSR writes. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> --- arch/x86/kvm/x86.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)