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? > > Right. Thanks Avi, for your detailed explanation, fix a long misunderstanding I had for live migration. Best Regards, Jinsong > >> 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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
