RE: [PATCH v2] KVM: x86: Prevent exposing TSC deadline timerfeature in the absence of in-kernel APIC
From: Liu, Jinsong
Date: Mon Dec 26 2011 - 09:23:55 EST
Avi Kivity wrote:
> On 12/26/2011 10:11 AM, Liu, Jinsong wrote:
>>> It breaks live migration: if you start a guest on a TSC-deadline
>>> capable host kernel, and migrate it to a TSC-deadline incapable host
>>> kernel, you end up with a broken guest.
>>> More broadly, kvm never exposes features transparently to the guest,
>>> it always passes them to userspace first, so userspace controls the
>>> ABI exposed to the guest. This prevents the following scenario:
>> Do you mean, by the method qemu control cpuid exposing, it can avoid
>> live migration broken issue by
>> 1. user probe the lowest ability host of whole pool where vm may
>> live migrate;
>> 2. only if the lowest ablility host support the feature can user
>> enable the feature when boot a vm;
>> 3. if the lowest ability host didn't support the feature (say tsc
>> deadline timer as example), user disable the feature when boot a vm;
>> In this way, live migration wouldn't be broken. Right?
Thanks Avi, for your detailed explanation, fix a long misunderstanding I had for live migration.
>> or, do you mean qemu-kvm solve live migration broken issue by some
>> other method?
> The method you outlined, or any other method, such as partitioning the
> cluster according to hardware capabilities.
>>> - a guest is started on some hardware, which doesn't support some
>>> cpuid feature (say AVX for example)
>>> - the guest or one of its applications are broken wrt AVX, but
>>> because the feature is not exposed, it works correctly
>>> - the host hardware is upgraded to one which supports AVX
>>> - the guest is now broken
>> You mean, live migrate from 'old' (which doesn't support the
>> feature) platform to 'new' platform would broken?
> Live migration, or even just a guest restart on updated hardware.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/