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.
>
>>
>> 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.
> 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.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
