[PATCH 1/2] Fix bad merge

[PATCH 1/2] Fix bad merge

[Anthony Liguori]

This option no longer exists.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/qemu/vl.c b/qemu/vl.c
index d9b7db2..82c9831 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8090,7 +8090,6 @@ enum {
     QEMU_OPTION_startdate,
     QEMU_OPTION_tb_size,
     QEMU_OPTION_icount,
-    QEMU_OPTION_translation,
     QEMU_OPTION_incoming,
     QEMU_OPTION_tdf,
     QEMU_OPTION_kvm_shadow_memory,

[PATCH 2/2] Remove -tdf

[Anthony Liguori]

The last time I posted the KVM patch series to qemu-devel, the -tdf patch met with
some opposition.  Since today we implement timer catch-up in the in-kernel PIT and
the in-kernel PIT is used by default, it doesn't seem all that valuable to have
timer catch-up in userspace too.

Removing it will reduce our divergence from QEMU.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

diff --git a/qemu/hw/i8254.c b/qemu/hw/i8254.c
index 69eb889..d0394c0 100644
--- a/qemu/hw/i8254.c
+++ b/qemu/hw/i8254.c
@@ -332,11 +332,6 @@ static uint32_t pit_ioport_read(void *opaque, uint32_t addr)
     return ret;
 }
 
-/* global counters for time-drift fix */
-int64_t timer_acks=0, timer_interrupts=0, timer_ints_to_push=0;
-
-extern int time_drift_fix;
-
 static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
 {
     int64_t expire_time;
@@ -347,24 +342,6 @@ static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
     expire_time = pit_get_next_transition_time(s, current_time);
     irq_level = pit_get_out1(s, current_time);
     qemu_set_irq(s->irq, irq_level);
-    if (time_drift_fix && irq_level==1) {
-        /* FIXME: fine tune timer_max_fix (max fix per tick). 
-         *        Should it be 1 (double time), 2 , 4, 10 ? 
-         *        Currently setting it to 5% of PIT-ticks-per-second (per PIT-tick)
-         */
-        const long pit_ticks_per_sec = (s->count>0) ? (PIT_FREQ/s->count) : 0;
-        const long timer_max_fix = pit_ticks_per_sec/20;
-        const long delta = timer_interrupts - timer_acks;
-        const long max_delta = pit_ticks_per_sec * 60; /* one minute */
-        if ((delta >  max_delta) && (pit_ticks_per_sec > 0)) {
-            printf("time drift is too long, %ld seconds were lost\n", delta/pit_ticks_per_sec);
-            timer_acks = timer_interrupts;
-            timer_ints_to_push = 0;
-        } else if (delta > 0) {
-            timer_ints_to_push = MIN(delta, timer_max_fix);
-        }
-        timer_interrupts++;
-    }
 #ifdef DEBUG_PIT
     printf("irq_level=%d next_delay=%f\n",
            irq_level,
diff --git a/qemu/hw/i8259.c b/qemu/hw/i8259.c
index b266119..1707434 100644
--- a/qemu/hw/i8259.c
+++ b/qemu/hw/i8259.c
@@ -221,35 +221,18 @@ static inline void pic_intack(PicState *s, int irq)
     } else {
         s->isr |= (1 << irq);
     }
-
     /* We don't clear a level sensitive interrupt here */
     if (!(s->elcr & (1 << irq)))
         s->irr &= ~(1 << irq);
-
 }
 
-extern int time_drift_fix;
-
 int pic_read_irq(PicState2 *s)
 {
     int irq, irq2, intno;
 
     irq = pic_get_irq(&s->pics[0]);
     if (irq >= 0) {
-
         pic_intack(&s->pics[0], irq);
-#ifndef TARGET_IA64
-	if (time_drift_fix && irq == 0) {
-	    extern int64_t timer_acks, timer_ints_to_push;
-	    timer_acks++;
-	    if (timer_ints_to_push > 0) {
-		timer_ints_to_push--;
-                /* simulate an edge irq0, like the one generated by i8254 */
-                pic_set_irq1(&s->pics[0], 0, 0);
-                pic_set_irq1(&s->pics[0], 0, 1);
-	    }
-	}
-#endif
         if (irq == 2) {
             irq2 = pic_get_irq(&s->pics[1]);
             if (irq2 >= 0) {
diff --git a/qemu/vl.c b/qemu/vl.c
index 19c8bbf..d6877cd 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -229,7 +229,6 @@ const char *option_rom[MAX_OPTION_ROMS];
 int nb_option_roms;
 int semihosting_enabled = 0;
 int autostart = 1;
-int time_drift_fix = 0;
 unsigned int kvm_shadow_memory = 0;
 const char *mem_path = NULL;
 int hpagesize = 0;
@@ -7968,7 +7967,6 @@ static void help(int exitcode)
 #ifndef _WIN32
 	   "-daemonize      daemonize QEMU after initializing\n"
 #endif
-           "-tdf            inject timer interrupts that got lost\n"
            "-kvm-shadow-memory megs set the amount of shadow pages to be allocated\n"
            "-mem-path       set the path to hugetlbfs/tmpfs mounted directory, also enables allocation of guest memory with huge pages\n"
 	   "-option-rom rom load a file, rom, into the option ROM space\n"
@@ -8089,7 +8087,6 @@ enum {
     QEMU_OPTION_tb_size,
     QEMU_OPTION_icount,
     QEMU_OPTION_incoming,
-    QEMU_OPTION_tdf,
     QEMU_OPTION_kvm_shadow_memory,
     QEMU_OPTION_mempath,
 };
@@ -8202,7 +8199,6 @@ const QEMUOption qemu_options[] = {
 #if defined(TARGET_ARM) || defined(TARGET_M68K)
     { "semihosting", 0, QEMU_OPTION_semihosting },
 #endif
-    { "tdf", 0, QEMU_OPTION_tdf }, /* enable time drift fix */
     { "kvm-shadow-memory", HAS_ARG, QEMU_OPTION_kvm_shadow_memory },
     { "name", HAS_ARG, QEMU_OPTION_name },
 #if defined(TARGET_SPARC)
@@ -9092,9 +9088,6 @@ int main(int argc, char **argv)
             case QEMU_OPTION_semihosting:
                 semihosting_enabled = 1;
                 break;
-            case QEMU_OPTION_tdf:
-                time_drift_fix = 1;
-		break;
             case QEMU_OPTION_kvm_shadow_memory:
                 kvm_shadow_memory = (int64_t)atoi(optarg) * 1024 * 1024 / 4096;
                 break;

Re: [PATCH 2/2] Remove -tdf

[Dor Laor]

Anthony Liguori wrote:
> The last time I posted the KVM patch series to qemu-devel, the -tdf patch met with
> some opposition.  Since today we implement timer catch-up in the in-kernel PIT and
> the in-kernel PIT is used by default, it doesn't seem all that valuable to have
> timer catch-up in userspace too.
>
> Removing it will reduce our divergence from QEMU.
>
>   
IMHO the in kernel PIT should go away, there is no reason to keep it 
except that userspace PIT drifts.
Currently both in-kernel PIT and even the in kernel irqchips are not 
100% bullet proof.
Of course this code is a hack, Gleb Natapov has send better fix for 
PIT/RTC to qemu list.
Can you look into them:
http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html

Thanks, Dor
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> diff --git a/qemu/hw/i8254.c b/qemu/hw/i8254.c
> index 69eb889..d0394c0 100644
> --- a/qemu/hw/i8254.c
> +++ b/qemu/hw/i8254.c
> @@ -332,11 +332,6 @@ static uint32_t pit_ioport_read(void *opaque, uint32_t addr)
>      return ret;
>  }
>  
> -/* global counters for time-drift fix */
> -int64_t timer_acks=0, timer_interrupts=0, timer_ints_to_push=0;
> -
> -extern int time_drift_fix;
> -
>  static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
>  {
>      int64_t expire_time;
> @@ -347,24 +342,6 @@ static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
>      expire_time = pit_get_next_transition_time(s, current_time);
>      irq_level = pit_get_out1(s, current_time);
>      qemu_set_irq(s->irq, irq_level);
> -    if (time_drift_fix && irq_level==1) {
> -        /* FIXME: fine tune timer_max_fix (max fix per tick). 
> -         *        Should it be 1 (double time), 2 , 4, 10 ? 
> -         *        Currently setting it to 5% of PIT-ticks-per-second (per PIT-tick)
> -         */
> -        const long pit_ticks_per_sec = (s->count>0) ? (PIT_FREQ/s->count) : 0;
> -        const long timer_max_fix = pit_ticks_per_sec/20;
> -        const long delta = timer_interrupts - timer_acks;
> -        const long max_delta = pit_ticks_per_sec * 60; /* one minute */
> -        if ((delta >  max_delta) && (pit_ticks_per_sec > 0)) {
> -            printf("time drift is too long, %ld seconds were lost\n", delta/pit_ticks_per_sec);
> -            timer_acks = timer_interrupts;
> -            timer_ints_to_push = 0;
> -        } else if (delta > 0) {
> -            timer_ints_to_push = MIN(delta, timer_max_fix);
> -        }
> -        timer_interrupts++;
> -    }
>  #ifdef DEBUG_PIT
>      printf("irq_level=%d next_delay=%f\n",
>             irq_level,
> diff --git a/qemu/hw/i8259.c b/qemu/hw/i8259.c
> index b266119..1707434 100644
> --- a/qemu/hw/i8259.c
> +++ b/qemu/hw/i8259.c
> @@ -221,35 +221,18 @@ static inline void pic_intack(PicState *s, int irq)
>      } else {
>          s->isr |= (1 << irq);
>      }
> -
>      /* We don't clear a level sensitive interrupt here */
>      if (!(s->elcr & (1 << irq)))
>          s->irr &= ~(1 << irq);
> -
>  }
>  
> -extern int time_drift_fix;
> -
>  int pic_read_irq(PicState2 *s)
>  {
>      int irq, irq2, intno;
>  
>      irq = pic_get_irq(&s->pics[0]);
>      if (irq >= 0) {
> -
>          pic_intack(&s->pics[0], irq);
> -#ifndef TARGET_IA64
> -	if (time_drift_fix && irq == 0) {
> -	    extern int64_t timer_acks, timer_ints_to_push;
> -	    timer_acks++;
> -	    if (timer_ints_to_push > 0) {
> -		timer_ints_to_push--;
> -                /* simulate an edge irq0, like the one generated by i8254 */
> -                pic_set_irq1(&s->pics[0], 0, 0);
> -                pic_set_irq1(&s->pics[0], 0, 1);
> -	    }
> -	}
> -#endif
>          if (irq == 2) {
>              irq2 = pic_get_irq(&s->pics[1]);
>              if (irq2 >= 0) {
> diff --git a/qemu/vl.c b/qemu/vl.c
> index 19c8bbf..d6877cd 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -229,7 +229,6 @@ const char *option_rom[MAX_OPTION_ROMS];
>  int nb_option_roms;
>  int semihosting_enabled = 0;
>  int autostart = 1;
> -int time_drift_fix = 0;
>  unsigned int kvm_shadow_memory = 0;
>  const char *mem_path = NULL;
>  int hpagesize = 0;
> @@ -7968,7 +7967,6 @@ static void help(int exitcode)
>  #ifndef _WIN32
>  	   "-daemonize      daemonize QEMU after initializing\n"
>  #endif
> -           "-tdf            inject timer interrupts that got lost\n"
>             "-kvm-shadow-memory megs set the amount of shadow pages to be allocated\n"
>             "-mem-path       set the path to hugetlbfs/tmpfs mounted directory, also enables allocation of guest memory with huge pages\n"
>  	   "-option-rom rom load a file, rom, into the option ROM space\n"
> @@ -8089,7 +8087,6 @@ enum {
>      QEMU_OPTION_tb_size,
>      QEMU_OPTION_icount,
>      QEMU_OPTION_incoming,
> -    QEMU_OPTION_tdf,
>      QEMU_OPTION_kvm_shadow_memory,
>      QEMU_OPTION_mempath,
>  };
> @@ -8202,7 +8199,6 @@ const QEMUOption qemu_options[] = {
>  #if defined(TARGET_ARM) || defined(TARGET_M68K)
>      { "semihosting", 0, QEMU_OPTION_semihosting },
>  #endif
> -    { "tdf", 0, QEMU_OPTION_tdf }, /* enable time drift fix */
>      { "kvm-shadow-memory", HAS_ARG, QEMU_OPTION_kvm_shadow_memory },
>      { "name", HAS_ARG, QEMU_OPTION_name },
>  #if defined(TARGET_SPARC)
> @@ -9092,9 +9088,6 @@ int main(int argc, char **argv)
>              case QEMU_OPTION_semihosting:
>                  semihosting_enabled = 1;
>                  break;
> -            case QEMU_OPTION_tdf:
> -                time_drift_fix = 1;
> -		break;
>              case QEMU_OPTION_kvm_shadow_memory:
>                  kvm_shadow_memory = (int64_t)atoi(optarg) * 1024 * 1024 / 4096;
>                  break;
>   

Re: [PATCH 2/2] Remove -tdf

[Anthony Liguori]

Dor Laor wrote:
> Anthony Liguori wrote:
>> The last time I posted the KVM patch series to qemu-devel, the -tdf 
>> patch met with
>> some opposition.  Since today we implement timer catch-up in the 
>> in-kernel PIT and
>> the in-kernel PIT is used by default, it doesn't seem all that 
>> valuable to have
>> timer catch-up in userspace too.
>>
>> Removing it will reduce our divergence from QEMU.
>>
>>   
> IMHO the in kernel PIT should go away, there is no reason to keep it 
> except that userspace PIT drifts.

I agree fully :-)  But there's certainly no reason to keep -tdf and the 
in-kernel PIT.  Since we're using the in-kernel PIT right now, I'd like 
to get rid of -tdf.

> Currently both in-kernel PIT and even the in kernel irqchips are not 
> 100% bullet proof.
> Of course this code is a hack, Gleb Natapov has send better fix for 
> PIT/RTC to qemu list.
> Can you look into them:
> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html

Paul Brook's initial feedback is still valid.  It causes quite a lot of 
churn and may not jive well with a virtual time base.  An advantage to 
the current -tdf patch is that it's more contained.  I don't think 
either approach is going to get past Paul in it's current form.

I'd still like to see some harder evidence of the benefits of tdf.  For 
a specific guest, with a specific configuration, how much better is the 
drift with this series.  The answer shouldn't be "movie's play better" :-)

Also, it's important that this is reproducible in upstream QEMU and not 
just in KVM.  If we can make a compelling case for the importance of 
this, we can possibly work out a compromise.

Regards,

Anthony Liguori

Re: [PATCH 2/2] Remove -tdf

[David S. Ahern]

Anthony Liguori wrote:
> Dor Laor wrote:
>> Anthony Liguori wrote:
>>> The last time I posted the KVM patch series to qemu-devel, the -tdf
>>> patch met with
>>> some opposition.  Since today we implement timer catch-up in the
>>> in-kernel PIT and
>>> the in-kernel PIT is used by default, it doesn't seem all that
>>> valuable to have
>>> timer catch-up in userspace too.
>>>
>>> Removing it will reduce our divergence from QEMU.
>>>
>>>   
>> IMHO the in kernel PIT should go away, there is no reason to keep it
>> except that userspace PIT drifts.
> 
> I agree fully :-)  But there's certainly no reason to keep -tdf and the
> in-kernel PIT.  Since we're using the in-kernel PIT right now, I'd like
> to get rid of -tdf.
> 
>> Currently both in-kernel PIT and even the in kernel irqchips are not
>> 100% bullet proof.
>> Of course this code is a hack, Gleb Natapov has send better fix for
>> PIT/RTC to qemu list.
>> Can you look into them:
>> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html
> 
> Paul Brook's initial feedback is still valid.  It causes quite a lot of
> churn and may not jive well with a virtual time base.  An advantage to
> the current -tdf patch is that it's more contained.  I don't think
> either approach is going to get past Paul in it's current form.
> 
> I'd still like to see some harder evidence of the benefits of tdf.  For
> a specific guest, with a specific configuration, how much better is the
> drift with this series.  The answer shouldn't be "movie's play better" :-)
>

I for one see better timekeeping with RHEL3 guests -- especially when
they get busy (e.g., kscand doing its thing). You see the "time drift"
message every time it kicks in (the message does need to be
throttled/not displayed by the way; it can overwhelm a stderr capture as
the guest runs for months).

> Also, it's important that this is reproducible in upstream QEMU and not
> just in KVM.  If we can make a compelling case for the importance of
> this, we can possibly work out a compromise.

I don't have an opinion on this particular implementation, only that
something is needed to keep the guest from losing time. Right now with
the kernel-pit my RHEL guests are always *ahead* of the host; with the
qemu pit the guest is behind the host (which makes more sense if ticks
are lost). Either way I'd like for the guest to not drift "noticeably"
and when it does that ntpd is adequate to keep it in sync (I've noticed
oddities with it too).

david


> 
> Regards,
> 
> Anthony Liguori
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 2/2] Remove -tdf

[Gleb Natapov]

On Tue, Jul 22, 2008 at 08:20:41PM -0500, Anthony Liguori wrote:
>> Currently both in-kernel PIT and even the in kernel irqchips are not  
>> 100% bullet proof.
>> Of course this code is a hack, Gleb Natapov has send better fix for  
>> PIT/RTC to qemu list.
>> Can you look into them:
>> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html
>
> Paul Brook's initial feedback is still valid.  It causes quite a lot of  
> churn and may not jive well with a virtual time base.  An advantage to  
> the current -tdf patch is that it's more contained.  I don't think  
> either approach is going to get past Paul in it's current form.
Yes, my patch causes a lot of churn because it changes widely used API.
But the time drift fix itself is contained to PIT/RTC code only. The
last patch series I've sent disables time drift fix if virtual time base
is enabled as Paul requested. There was no further feedback from him.
As Jan Kiszka wrote in one of his mails may be Paul's virtual time base
can be adopted to work with KVM too. BTW how virtual time base handles
SMP guest?

> Also, it's important that this is reproducible in upstream QEMU and not  
> just in KVM.  If we can make a compelling case for the importance of  
> this, we can possibly work out a compromise.
>
I developed and tested my patch with upstream QEMU.

--
			Gleb.

Re: [PATCH 2/2] Remove -tdf

[Anthony Liguori]

Gleb Natapov wrote:
> On Tue, Jul 22, 2008 at 08:20:41PM -0500, Anthony Liguori wrote:
>   
>>> Currently both in-kernel PIT and even the in kernel irqchips are not  
>>> 100% bullet proof.
>>> Of course this code is a hack, Gleb Natapov has send better fix for  
>>> PIT/RTC to qemu list.
>>> Can you look into them:
>>> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html
>>>       
>> Paul Brook's initial feedback is still valid.  It causes quite a lot of  
>> churn and may not jive well with a virtual time base.  An advantage to  
>> the current -tdf patch is that it's more contained.  I don't think  
>> either approach is going to get past Paul in it's current form.
>>     
> Yes, my patch causes a lot of churn because it changes widely used API.
>   

Indeed.

> But the time drift fix itself is contained to PIT/RTC code only. The
> last patch series I've sent disables time drift fix if virtual time base
> is enabled as Paul requested. There was no further feedback from him.
>   

I think there's a healthy amount of scepticism  about whether tdf really 
is worth it.  This is why I suggested that we need to better quantify 
exactly how much this patch set helps things.  For instance, a time 
drift test for kvm-autotest would be perfect.

tdf is ugly and deviates from how hardware works.  A compelling case is 
needed to justify it.

> As Jan Kiszka wrote in one of his mails may be Paul's virtual time base
> can be adopted to work with KVM too. BTW how virtual time base handles
> SMP guest?
>   

I really don't know.  I haven't looked to deeply at the virtual time 
base.  Keep in mind though, that QEMU SMP is not true SMP.  All VCPUs 
run in lock-step.

Regards,

Anthony Liguori

>> Also, it's important that this is reproducible in upstream QEMU and not  
>> just in KVM.  If we can make a compelling case for the importance of  
>> this, we can possibly work out a compromise.
>>
>>     
> I developed and tested my patch with upstream QEMU.
>
> --
> 			Gleb.
>   

Re: [PATCH 2/2] Remove -tdf

[Dor Laor]

Anthony Liguori wrote:
> Gleb Natapov wrote:
>> On Tue, Jul 22, 2008 at 08:20:41PM -0500, Anthony Liguori wrote:
>>  
>>>> Currently both in-kernel PIT and even the in kernel irqchips are 
>>>> not  100% bullet proof.
>>>> Of course this code is a hack, Gleb Natapov has send better fix 
>>>> for  PIT/RTC to qemu list.
>>>> Can you look into them:
>>>> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html
>>>>       
>>> Paul Brook's initial feedback is still valid.  It causes quite a lot 
>>> of  churn and may not jive well with a virtual time base.  An 
>>> advantage to  the current -tdf patch is that it's more contained.  I 
>>> don't think  either approach is going to get past Paul in it's 
>>> current form.
>>>     
>> Yes, my patch causes a lot of churn because it changes widely used API.
>>   
>
> Indeed.
>
>> But the time drift fix itself is contained to PIT/RTC code only. The
>> last patch series I've sent disables time drift fix if virtual time base
>> is enabled as Paul requested. There was no further feedback from him.
>>   
>
> I think there's a healthy amount of scepticism  about whether tdf 
> really is worth it.  This is why I suggested that we need to better 
> quantify exactly how much this patch set helps things.  For instance, 
> a time drift test for kvm-autotest would be perfect.
>
> tdf is ugly and deviates from how hardware works.  A compelling case 
> is needed to justify it.
>
We'll add time drift tests to autotest the minute it starts to run 
enough interesting tests/loads.
In our private test platform we use a simple scenario to test it:
1. Use windows guest and play a movie (changes rtc on acpi win/pit on 
-no-acpi win freq to 1000hz).
2. Pin the guest to a physical cpu + load the same cpu.
3. Measure a minute in real life vs in the guest.

Actually the movie seems to be more smooth without time drift fix. When 
fixing irqs some times the player needs to cope with too rapid changes. 
Anyway the main focus is time accuracy and not smoother movies.

In-kernel pit does relatively good job for Windows guests, the problem 
its not yet 100% stable and also we can do it in userspace and the rtc 
needs a solution too.
>> As Jan Kiszka wrote in one of his mails may be Paul's virtual time base
>> can be adopted to work with KVM too. BTW how virtual time base handles
>> SMP guest?
>>   
>
> I really don't know.  I haven't looked to deeply at the virtual time 
> base.  Keep in mind though, that QEMU SMP is not true SMP.  All VCPUs 
> run in lock-step.
>
> Regards,
>
> Anthony Liguori
>
>>> Also, it's important that this is reproducible in upstream QEMU and 
>>> not  just in KVM.  If we can make a compelling case for the 
>>> importance of  this, we can possibly work out a compromise.
>>>
>>>     
>> I developed and tested my patch with upstream QEMU.
>>
>> -- 
>>             Gleb.
>>   
>

Re: [PATCH 1/2] Fix bad merge

[Avi Kivity]

Anthony Liguori wrote:
> This option no longer exists.
>   


Applied, thanks.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 2/2] Remove -tdf

[Avi Kivity]

Anthony Liguori wrote:
> The last time I posted the KVM patch series to qemu-devel, the -tdf patch met with
> some opposition.  Since today we implement timer catch-up in the in-kernel PIT and
> the in-kernel PIT is used by default, it doesn't seem all that valuable to have
> timer catch-up in userspace too.
>
> Removing it will reduce our divergence from QEMU.
>
>   

I'd rather see the feature added to qemu (in the form of Gleb's irq 
notifications) rather than removed.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 2/2] Remove -tdf

[Avi Kivity]

Anthony Liguori wrote:
>
> I think there's a healthy amount of scepticism  about whether tdf 
> really is worth it.  This is why I suggested that we need to better 
> quantify exactly how much this patch set helps things.  For instance, 
> a time drift test for kvm-autotest would be perfect.
>
> tdf is ugly and deviates from how hardware works.  A compelling case 
> is needed to justify it.
>

On real hardware, the processor won't go away randomly for lengthy 
periods.  Since software assumes this, we must either provide a 
correction or live with guest time not corresponding to real time.

-- 
error compiling committee.c: too many arguments to function