On 2012-01-07 19:23, Liu, Jinsong wrote:
> Jan Kiszka wrote:
>> On 2012-01-05 18:07, Liu, Jinsong wrote:
>>>> Sorry, it remains bogus to expose the tsc deadline timer feature on
>>>> machines < pc-1.1. That's just like we introduced kvmclock only to
>>>> pc-0.14 onward. The reason is that guest OSes so far running on
>>>> qemu-1.0 or older without deadline timer support must not find that
>>>> feature when being migrated to a host with qemu-1.1 in pc-1.0 compat
>>>> mode. Yes, the user can explicitly disable it, but that is not the
>>>> idea of legacy machine models. They should provide the very same
>>>> environment that older qemu versions offered.
>>>>
>>>
>>> Not quite clear about this point.
>>> Per my understanding, if a kvm guest running on an older qemu
>>> without tsc deadline timer support,
>>> then after migrate, the guest would still cannot find tsc deadline
>>> feature, no matter older or newer host/qemu/pc-xx it migrate to.
>>
>> What should prevent this? The feature flags are not part of the
>> vmstate. They are part of the vm configuration which is not migrated
>> but defined by starting qemu on the target host.
>>
>
> Thanks! understand this point ("They are part of the vm configuration which is not migrated but defined by starting qemu on the target host").
>
> But kvmclock example still cannot satisfy the purpose "guest running on old qemu/pc-0.13 without kvmclock support must not find kvmclock feature when being migrated to a host with new qemu/pc-0.13 compat mode". After migration, guest can possibily find kvmclock feature CPUID.0x40000001.KVM_FEATURE_CLOCKSOURCE:
> pc_init1(..., kvmclock_enabled)
> {
> pc_cpus_init(cpu_model); // the point to decide and expose cpuid features to guest
>
> if (kvmclock_enabled) { // the difference point between pc-0.13 vs. pc-0.14, related nothing to cpuid features.
> kvmclock_create();
> }
> }
Right, not a perfect example: the cpuid feature is not influenced by
this mechanism, only the fact if a kvmclock device (for save/restore)
should be created. I guess we ignored this back then, only focusing on
the more obvious issue of the addition device.
>
> Seems currently there is no good way to satisfy "guest running on old qemu/pc-xx without feature A support must not find feature A when being migrated to a host with new qemu/pc-xx compat mode", i.e. considering
> * if running with '-cpu host' then migrate;
> * each time we add a new cpuid feature it need add one or more new machine model? is it necessary to bind pc-xx with cpuid feature?
> * logically cpuid features should better be controlled by cpu model, not by machine model.
The compatibility machines define the possible cpu models. If I select
pc-0.14, e.g. -cpu kvm64 should not give me features that 0.14 was not
exposing.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
