Jan Kiszka wrote:
> On 2011-12-28 18:35, Liu, Jinsong wrote:
>>>> diff --git a/qemu-kvm.h b/qemu-kvm.h
>>>> index 2bd5602..8c6c2ea 100644
>>>> --- a/qemu-kvm.h
>>>> +++ b/qemu-kvm.h
>>>> @@ -260,6 +260,7 @@ extern int kvm_irqchip;
>>>> extern int kvm_pit;
>>>> extern int kvm_pit_reinject;
>>>> extern unsigned int kvm_shadow_memory;
>>>> +extern int tsc_deadline_timer;
>>>>
>>>> int kvm_handle_tpr_access(CPUState *env);
>>>> void kvm_tpr_enable_vapic(CPUState *env);
>>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>>> index f6df6b9..eff6644 100644
>>>> --- a/qemu-options.hx
>>>> +++ b/qemu-options.hx
>>>> @@ -2619,6 +2619,9 @@ DEF("no-kvm-pit-reinjection", 0,
>>>> QEMU_OPTION_no_kvm_pit_reinjection,
>>>> "-no-kvm-pit-reinjection\n" " disable KVM
>>>> kernel mode PIT interrupt reinjection\n", QEMU_ARCH_I386)
>>>> +DEF("no-tsc-deadline-timer", 0,
>>>> QEMU_OPTION_no_tsc_deadline_timer, + "-no-tsc-deadline-timer
>>>> disable tsc deadline timer\n", + QEMU_ARCH_I386)
>>>
>>> Hmm, I would really prefer to stop adding switches like this. They
>>> won't make it upstream anyway.
>>
>> OK, I will try to write a patch w/ better user control cpuid method,
>> i.e. by plus_features and minus_features.
>
> Yep, that would be better.
Thanks, patch updated according to above idea, and sent out.
>
>>
>>>
>>> Can't this control be attached to legacy qemu machine models, ie.
>>> here anything <= pc-1.0? See how we handle kvmclock.
>>>
>>
>> You mean, by adding input para like pc_init1(..., kvmclock_enabled,
>> tscdeadline_enabled)?
>> I think that's not a good way.
>
> I think it is mandatory as older qemu versions won't expose
> tscdeadline to the guest, thus newer versions must not do this when
> emulating older machines.
Hmm, if an old qemu machine runs at a new host platform (say, -cpu host), it
would expose many *new* cpuid features to guest.
IMO, qemu machine is a *virt* platform for guest,
tsc deadline timer is a cpuid features, not much necessary to be bound to some
qemu machine version.
whether tsc deadline timer cpuid expose to guest can only decided by:
1. user authorize enable (default yes)
2. kvm_irqchip_in_kernel
3. KVM_CAP_TSC_DEADLINE_TIMER
If yes, it can be exposed to guest, and would not break anything no matter what
qemu machine version is.
Thanks,
Jinsong
>
>> With more and more cpuid features (N) controlled in this way,
>> machine models would be 2^N.
>
> We likely need a better way to express this via code, I agree. Likely
> something declarative as for compat_props.
>
