On 2012-02-27 17:05, Liu, Jinsong wrote:
> Jan Kiszka wrote:
>> 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
>
> How does machine define possible cpu models?
> cpu model defined by qemu option '-cpu ...', while machine model defined by '-machine ...'
>
>> pc-0.14, e.g. -cpu kvm64 should not give me features that 0.14 was not
>> exposing.
>>
>
> in such case, it's '-cpu kvm64' who take effect to decide what cpuid features would exposed to guest, not '-machine pc-0.14'.
>
> IMO, what our patch need to do is to expose a cpuid feature to guest (CPUID.01H:ECX.TSC_Deadline[bit 24]), it decided by cpu model, not machine model:
> pc_init1(..., cpu_model, ...)
> {
> pc_cpus_init(cpu_model); // this is the whole logic exposing cpuid features to guest
> ...
> }
>
> Do I misunderstanding something?
My point is that
qemu-version-A [-cpu whatever]
should provide the same VM as
qemu-version-B -machine pc-A [-cpu whatever]
specifically if you leave out the cpu specification.
So the compat machine could establish a feature mask (e.g. append some
"-tsc_deadline" in this case). But, indeed, we need a new channel for this.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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
