If creating an SMP guest with unstable host TSC, issue a warning
Signed-off-by: Zachary Amsden <[email protected]>
---
arch/x86/kvm/x86.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3420f25..5e3b10e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5457,6 +5457,10 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
unsigned int id)
{
+ if (check_tsc_unstable() && atomic_read(&kvm->online_vcpus) != 0)
+ printk_once(KERN_WARNING
+ "kvm: SMP vm created on host with unstable TSC; "
+ "guest TSC will not be reliable\n");
return kvm_x86_ops->vcpu_create(kvm, id);
}
--
1.7.1
On Thu, Aug 19, 2010 at 10:07:22PM -1000, Zachary Amsden wrote:
> If creating an SMP guest with unstable host TSC, issue a warning
>
> Signed-off-by: Zachary Amsden <[email protected]>
Ok, I am not sure I agree 100 % this is needed.
I believe we should try to communicate this kind of thing to the guest,
not the host, and through cpuid.
Passing through tsc flags to the guest should maybe be enough?
On 08/20/2010 07:28 AM, Glauber Costa wrote:
> On Thu, Aug 19, 2010 at 10:07:22PM -1000, Zachary Amsden wrote:
>
>> If creating an SMP guest with unstable host TSC, issue a warning
>>
>> Signed-off-by: Zachary Amsden<[email protected]>
>>
> Ok, I am not sure I agree 100 % this is needed.
> I believe we should try to communicate this kind of thing to the guest,
> not the host, and through cpuid.
>
> Passing through tsc flags to the guest should maybe be enough?
>
I found a better way to deal with this later in the series... the theory
being if the full series doesn't get backported to supported releases,
at least we'll get a warning.