>> 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.
>
> 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. With more and more cpuid features (N) controlled in this way, machine models would be 2^N.
Thanks,
Jinsong--
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
