[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Expose tsc deadline timer cpuid to guest

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] Expose tsc deadline timer cpuid to guest
Date: Wed, 28 Dec 2011 20:18:11 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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

> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]