[Qemu-devel] [Bug 599958] [NEW] Timedrift problems with Win7 + qemu-kvm

[Qemu-devel] [Bug 599958] [NEW] Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

Public bug reported:

We've been finding timedrift issues witth Win7 under qemu-kvm on our
daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

** Attachment added: "timedrift with load log"
   http://launchpadlibrarian.net/51133239/kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load.DEBUG

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

** Attachment added: "timedrift with migration log"
   http://launchpadlibrarian.net/51133264/kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration.DEBUG

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

** Attachment added: "timedrift with reboot log"
   http://launchpadlibrarian.net/51133275/kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot.DEBUG

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Anthony Liguori]

Does adding -no-hpet make a difference?  I assume that Win7 is using
hpet by default and we currently don't do any time drift mitigation with
hpet.

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

I will try that on a separate test job and will let you know about the
results.

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7 + qemu-kvm

[Lucas Meneghel Rodrigues]

Indeed -no-hpet made the tests pass. It's still uncertain to me whether
this flag is supported across several branches of qemu-kvm, if it's
supported in all branches I'm going to update the upstream kvm autotest
config file.

-- 
Timedrift problems with Win7 + qemu-kvm
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Anthony Liguori]

-no-hpet works in every version of qemu/qemu-kvm that has included HPET
support.  RHEL disables HPET support by default unlike qemu and qemu-
kvm.

I've updated the bug priority and title to reflect what the issue is.

We only support edge triggered interrupts with HPET which seems to be
what most OSes use anyway.  We could potentially use the
reset_irq_delivered/get_irq_delivered APIC functions to implement
interrupt catch-up but I think it would be better to try to merge Jan's
generic IRQ delivered API first.

** Summary changed:

- Timedrift problems with Win7 + qemu-kvm
+ Timedrift problems with Win7: hpet missing time drift fixups

** Changed in: qemu
   Importance: Undecided => Wishlist

** Changed in: qemu
       Status: New => Confirmed

-- 
Timedrift problems with Win7: hpet missing time drift fixups
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Lucas Meneghel Rodrigues]

Sent patch http://patchwork.test.kernel.org/patch/2384/ to autotest and
will update the autotest server to reflect that option.

-- 
Timedrift problems with Win7: hpet missing time drift fixups
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed

Bug description:
We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing

kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

Steps to reproduce:

timedrift.with_load

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Run load on the guest and host.
4) Take a second time reading.
5) Stop the load and rest for a while.
6) Take a third time reading.
7) If the drift immediately after load is higher than a user-
    specified value (in %), fail.
    If the drift after the rest period is higher than a user-specified value,
    fail.

timedrift.with_migration

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Migrate the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

timedrift.with_reboot

1) Log into a guest.
2) Take a time reading from the guest and host.
3) Reboot the guest.
4) Take a second time reading.
5) If the drift (in seconds) is higher than a user specified value, fail.

This bug is to register those issues and keep an eye on them.

Attached, some logs from the autotest tests executed on the guest

[Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

Anthony Liguori wrote:
> -no-hpet works in every version of qemu/qemu-kvm that has included HPET
> support.  RHEL disables HPET support by default unlike qemu and qemu-
> kvm.
> 
> I've updated the bug priority and title to reflect what the issue is.
> 
> We only support edge triggered interrupts with HPET which seems to be
> what most OSes use anyway.

qemu.git now also supports level triggering.

>  We could potentially use the
> reset_irq_delivered/get_irq_delivered APIC functions to implement
> interrupt catch-up but I think it would be better to try to merge Jan's
> generic IRQ delivered API first.

Which one? I'm a bit tired of rebasing versions that will only be
rejected again. :)

> 
> ** Summary changed:
> 
> - Timedrift problems with Win7 + qemu-kvm
> + Timedrift problems with Win7: hpet missing time drift fixups
> 
> ** Changed in: qemu
>    Importance: Undecided => Wishlist
> 
> ** Changed in: qemu
>        Status: New => Confirmed
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Thu, Jul 01, 2010 at 09:13:48AM +0200, Jan Kiszka wrote:
> >  We could potentially use the
> > reset_irq_delivered/get_irq_delivered APIC functions to implement
> > interrupt catch-up but I think it would be better to try to merge Jan's
> > generic IRQ delivered API first.
> 
> Which one? I'm a bit tired of rebasing versions that will only be
> rejected again. :)
> 
Since it solves existing problem and is rejected without any rational
explanation and without proposing alternative solution (in form of code)
it should be committed.

--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Paul Brook]

> Since it solves existing problem and is rejected without any rational
> explanation and without proposing alternative solution (in form of code)
> it should be committed.

No. This is not sufficient justification for applying a patch. We should not 
be accepting patches just because they exist.

If a feature[1] is important enough that we need to implement it, then it 
should also warrant getting a good solution. Otherwise we're going to end up 
in exactly the same situation next time someone starts using a nwew 
timesource.

Paul

[1] Time-drift hacks are a new *feature*, not a bugfix. At best they're hiding 
more fundamental flaws, e.g. kvm being incapable of emulating realtime 
behavior.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Anthony Liguori]

On 07/01/2010 02:13 AM, Jan Kiszka wrote:
> Anthony Liguori wrote:
>    
>> -no-hpet works in every version of qemu/qemu-kvm that has included HPET
>> support.  RHEL disables HPET support by default unlike qemu and qemu-
>> kvm.
>>
>> I've updated the bug priority and title to reflect what the issue is.
>>
>> We only support edge triggered interrupts with HPET which seems to be
>> what most OSes use anyway.
>>      
> qemu.git now also supports level triggering.
>    

Indeed it does :-)

>    
>>   We could potentially use the
>> reset_irq_delivered/get_irq_delivered APIC functions to implement
>> interrupt catch-up but I think it would be better to try to merge Jan's
>> generic IRQ delivered API first.
>>      
> Which one? I'm a bit tired of rebasing versions that will only be
> rejected again. :)
>    

Yeah, I appreciate your frustration here.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Anthony Liguori]

On 07/01/2010 10:45 AM, Paul Brook wrote:
>> Since it solves existing problem and is rejected without any rational
>> explanation and without proposing alternative solution (in form of code)
>> it should be committed.
>>      
> No. This is not sufficient justification for applying a patch. We should not
> be accepting patches just because they exist.
>
> If a feature[1] is important enough that we need to implement it, then it
> should also warrant getting a good solution.

I think it's important to try to be constructive.  It's easy to say that 
something is bad but it's far more productive to take the time to offer 
a better alternative.

>   Otherwise we're going to end up
> in exactly the same situation next time someone starts using a nwew
> timesource.
>
> Paul
>
> [1] Time-drift hacks are a new *feature*, not a bugfix. At best they're hiding
> more fundamental flaws, e.g. kvm being incapable of emulating realtime
> behavior.
>    

I think a fundamental problem in this discussion is that you're 
asserting that the true problem is "broken guests".  I contend that 
there is no such thing as broken guests.  Guests behave the way they do 
and to the extent that most hardware accommodates that behavior, our 
goal in QEMU should be to also accommodate that behavior.

Sometimes that means breaking nice abstractions but that's the cost of 
functionality.

I really see no tangible objection to Jan's patches.  They don't impact 
any other code.  They don't inhibit flexibility in the infrastructure.  
You might consider it to be a "hack" but so what.  QEMU is filled with 
hacks.  It would be useless without them because there would be very 
little code.

Taking these patches really does no harm.  I really think you ought to 
reconsider your position.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Paul Brook]

> I really see no tangible objection to Jan's patches.  They don't impact
> any other code.  They don't inhibit flexibility in the infrastructure.
> You might consider it to be a "hack" but so what.  QEMU is filled with
> hacks.  It would be useless without them because there would be very
> little code.

I object strongly to anything that makes qemu_irq a message passing API.
if you want message passing then you should not be using qemu_irq.

Paul

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Paul Brook wrote:
>> I really see no tangible objection to Jan's patches.  They don't impact
>> any other code.  They don't inhibit flexibility in the infrastructure.
>> You might consider it to be a "hack" but so what.  QEMU is filled with
>> hacks.  It would be useless without them because there would be very
>> little code.
> 
> I object strongly to anything that makes qemu_irq a message passing API.
> if you want message passing then you should not be using qemu_irq.

Blueswirl objected to the straightforward return-value approach I first
posted. You seems to be more open towards this, right? Still looks like
I cannot make you both happy at the same time. So what to do?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Blue Swirl]

On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Paul Brook wrote:
>>> I really see no tangible objection to Jan's patches.  They don't impact
>>> any other code.  They don't inhibit flexibility in the infrastructure.
>>> You might consider it to be a "hack" but so what.  QEMU is filled with
>>> hacks.  It would be useless without them because there would be very
>>> little code.
>>
>> I object strongly to anything that makes qemu_irq a message passing API.
>> if you want message passing then you should not be using qemu_irq.
>
> Blueswirl objected to the straightforward return-value approach I first
> posted. You seems to be more open towards this, right? Still looks like
> I cannot make you both happy at the same time. So what to do?

I have withdrawn my objection. We can do message passing with some
different API later, for simple coalescing needs the return value
approach is enough.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Blue Swirl wrote:
> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Paul Brook wrote:
>>>> I really see no tangible objection to Jan's patches.  They don't impact
>>>> any other code.  They don't inhibit flexibility in the infrastructure.
>>>> You might consider it to be a "hack" but so what.  QEMU is filled with
>>>> hacks.  It would be useless without them because there would be very
>>>> little code.
>>> I object strongly to anything that makes qemu_irq a message passing API.
>>> if you want message passing then you should not be using qemu_irq.
>> Blueswirl objected to the straightforward return-value approach I first
>> posted. You seems to be more open towards this, right? Still looks like
>> I cannot make you both happy at the same time. So what to do?
> 
> I have withdrawn my objection. We can do message passing with some
> different API later, for simple coalescing needs the return value
> approach is enough.

Great! I'll respin my patches ASAP.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Paul Brook]

> Blue Swirl wrote:
> > On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >> Paul Brook wrote:
> >>>> I really see no tangible objection to Jan's patches.  They don't
> >>>> impact any other code.  They don't inhibit flexibility in the
> >>>> infrastructure. You might consider it to be a "hack" but so what. 
> >>>> QEMU is filled with hacks.  It would be useless without them because
> >>>> there would be very little code.
> >>> 
> >>> I object strongly to anything that makes qemu_irq a message passing
> >>> API. if you want message passing then you should not be using
> >>> qemu_irq.
> >> 
> >> Blueswirl objected to the straightforward return-value approach I first
> >> posted. You seems to be more open towards this, right? Still looks like
> >> I cannot make you both happy at the same time. So what to do?
> > 
> > I have withdrawn my objection. We can do message passing with some
> > different API later, for simple coalescing needs the return value
> > approach is enough.
> 
> Great! I'll respin my patches ASAP.

Note that I still have some concerns over the semantics of that API.
I believe this should be fundamentally state based, not event based.

In practice returning a value from qemu_set_irq may be a reasonable way of 
communicating this state.  However this should be done is such a a way that 
redundant calls to qemu_set_irq return the same value.

See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01592.html

Paul

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Paul Brook wrote:
>> Blue Swirl wrote:
>>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> Paul Brook wrote:
>>>>>> I really see no tangible objection to Jan's patches.  They don't
>>>>>> impact any other code.  They don't inhibit flexibility in the
>>>>>> infrastructure. You might consider it to be a "hack" but so what. 
>>>>>> QEMU is filled with hacks.  It would be useless without them because
>>>>>> there would be very little code.
>>>>> I object strongly to anything that makes qemu_irq a message passing
>>>>> API. if you want message passing then you should not be using
>>>>> qemu_irq.
>>>> Blueswirl objected to the straightforward return-value approach I first
>>>> posted. You seems to be more open towards this, right? Still looks like
>>>> I cannot make you both happy at the same time. So what to do?
>>> I have withdrawn my objection. We can do message passing with some
>>> different API later, for simple coalescing needs the return value
>>> approach is enough.
>> Great! I'll respin my patches ASAP.
> 
> Note that I still have some concerns over the semantics of that API.
> I believe this should be fundamentally state based, not event based.

For the caller of qemu_set_irq, it will be like that.

> 
> In practice returning a value from qemu_set_irq may be a reasonable way of 
> communicating this state.  However this should be done is such a a way that 
> redundant calls to qemu_set_irq return the same value.

I played with ignoring redundant invocations of qemu_set_irq early to
strengthen the state based concept. Unfortunately, the result was a
non-booting x86 system as at least the PIT is not properly deasserting
its IRQ line in periodic mode. Everything is fixable, I'm just reluctant
to overload the planned series with such a measure. I would prefer doing
this in a second step after checking for more such regressions.

> 
> See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01592.html

Will adopt the naming scheme.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Mon, Jul 05, 2010 at 08:39:38AM +0200, Jan Kiszka wrote:
> Paul Brook wrote:
> >> Blue Swirl wrote:
> >>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>> Paul Brook wrote:
> >>>>>> I really see no tangible objection to Jan's patches.  They don't
> >>>>>> impact any other code.  They don't inhibit flexibility in the
> >>>>>> infrastructure. You might consider it to be a "hack" but so what. 
> >>>>>> QEMU is filled with hacks.  It would be useless without them because
> >>>>>> there would be very little code.
> >>>>> I object strongly to anything that makes qemu_irq a message passing
> >>>>> API. if you want message passing then you should not be using
> >>>>> qemu_irq.
> >>>> Blueswirl objected to the straightforward return-value approach I first
> >>>> posted. You seems to be more open towards this, right? Still looks like
> >>>> I cannot make you both happy at the same time. So what to do?
> >>> I have withdrawn my objection. We can do message passing with some
> >>> different API later, for simple coalescing needs the return value
> >>> approach is enough.
> >> Great! I'll respin my patches ASAP.
> > 
> > Note that I still have some concerns over the semantics of that API.
> > I believe this should be fundamentally state based, not event based.
> 
> For the caller of qemu_set_irq, it will be like that.
> 
Unfortunately just having qemu_set_irq() return value is not enough to
fix timedrift problem for all Windows. For some of them you need to know
_which_ CPU accepted IRQ.

--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

Gleb Natapov wrote:
> On Mon, Jul 05, 2010 at 08:39:38AM +0200, Jan Kiszka wrote:
>> Paul Brook wrote:
>>>> Blue Swirl wrote:
>>>>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>>> Paul Brook wrote:
>>>>>>>> I really see no tangible objection to Jan's patches.  They don't
>>>>>>>> impact any other code.  They don't inhibit flexibility in the
>>>>>>>> infrastructure. You might consider it to be a "hack" but so what. 
>>>>>>>> QEMU is filled with hacks.  It would be useless without them because
>>>>>>>> there would be very little code.
>>>>>>> I object strongly to anything that makes qemu_irq a message passing
>>>>>>> API. if you want message passing then you should not be using
>>>>>>> qemu_irq.
>>>>>> Blueswirl objected to the straightforward return-value approach I first
>>>>>> posted. You seems to be more open towards this, right? Still looks like
>>>>>> I cannot make you both happy at the same time. So what to do?
>>>>> I have withdrawn my objection. We can do message passing with some
>>>>> different API later, for simple coalescing needs the return value
>>>>> approach is enough.
>>>> Great! I'll respin my patches ASAP.
>>> Note that I still have some concerns over the semantics of that API.
>>> I believe this should be fundamentally state based, not event based.
>> For the caller of qemu_set_irq, it will be like that.
>>
> Unfortunately just having qemu_set_irq() return value is not enough to
> fix timedrift problem for all Windows. For some of them you need to know
> _which_ CPU accepted IRQ.

Return values:
 < 0	- no state change, specifically due to masking or latching
 >= 0	- first CPU (lowest index) on which a state change was achieved

Sufficient?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Mon, Jul 05, 2010 at 08:49:31AM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Mon, Jul 05, 2010 at 08:39:38AM +0200, Jan Kiszka wrote:
> >> Paul Brook wrote:
> >>>> Blue Swirl wrote:
> >>>>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>>> Paul Brook wrote:
> >>>>>>>> I really see no tangible objection to Jan's patches.  They don't
> >>>>>>>> impact any other code.  They don't inhibit flexibility in the
> >>>>>>>> infrastructure. You might consider it to be a "hack" but so what. 
> >>>>>>>> QEMU is filled with hacks.  It would be useless without them because
> >>>>>>>> there would be very little code.
> >>>>>>> I object strongly to anything that makes qemu_irq a message passing
> >>>>>>> API. if you want message passing then you should not be using
> >>>>>>> qemu_irq.
> >>>>>> Blueswirl objected to the straightforward return-value approach I first
> >>>>>> posted. You seems to be more open towards this, right? Still looks like
> >>>>>> I cannot make you both happy at the same time. So what to do?
> >>>>> I have withdrawn my objection. We can do message passing with some
> >>>>> different API later, for simple coalescing needs the return value
> >>>>> approach is enough.
> >>>> Great! I'll respin my patches ASAP.
> >>> Note that I still have some concerns over the semantics of that API.
> >>> I believe this should be fundamentally state based, not event based.
> >> For the caller of qemu_set_irq, it will be like that.
> >>
> > Unfortunately just having qemu_set_irq() return value is not enough to
> > fix timedrift problem for all Windows. For some of them you need to know
> > _which_ CPU accepted IRQ.
> 
> Return values:
>  < 0	- no state change, specifically due to masking or latching
>  >= 0	- first CPU (lowest index) on which a state change was achieved
> 
> Sufficient?
> 
To problem specific for such generic interface. Doesn't allow to
distinguish between masking and coalescing. Assumes that CPU with
lowest index is BSP (that one we can actually guaranty if we want
to). And what about PIC mode where interrupt receiver is not CPU?

--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

Gleb Natapov wrote:
> On Mon, Jul 05, 2010 at 08:49:31AM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Mon, Jul 05, 2010 at 08:39:38AM +0200, Jan Kiszka wrote:
>>>> Paul Brook wrote:
>>>>>> Blue Swirl wrote:
>>>>>>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>>>>> Paul Brook wrote:
>>>>>>>>>> I really see no tangible objection to Jan's patches.  They don't
>>>>>>>>>> impact any other code.  They don't inhibit flexibility in the
>>>>>>>>>> infrastructure. You might consider it to be a "hack" but so what. 
>>>>>>>>>> QEMU is filled with hacks.  It would be useless without them because
>>>>>>>>>> there would be very little code.
>>>>>>>>> I object strongly to anything that makes qemu_irq a message passing
>>>>>>>>> API. if you want message passing then you should not be using
>>>>>>>>> qemu_irq.
>>>>>>>> Blueswirl objected to the straightforward return-value approach I first
>>>>>>>> posted. You seems to be more open towards this, right? Still looks like
>>>>>>>> I cannot make you both happy at the same time. So what to do?
>>>>>>> I have withdrawn my objection. We can do message passing with some
>>>>>>> different API later, for simple coalescing needs the return value
>>>>>>> approach is enough.
>>>>>> Great! I'll respin my patches ASAP.
>>>>> Note that I still have some concerns over the semantics of that API.
>>>>> I believe this should be fundamentally state based, not event based.
>>>> For the caller of qemu_set_irq, it will be like that.
>>>>
>>> Unfortunately just having qemu_set_irq() return value is not enough to
>>> fix timedrift problem for all Windows. For some of them you need to know
>>> _which_ CPU accepted IRQ.
>> Return values:
>>  < 0	- no state change, specifically due to masking or latching
>>  >= 0	- first CPU (lowest index) on which a state change was achieved
>>
>> Sufficient?
>>
> To problem specific for such generic interface. Doesn't allow to
> distinguish between masking and coalescing.

It does (return values < 0 are specified to differentiate between them
and more).

> Assumes that CPU with
> lowest index is BSP (that one we can actually guaranty if we want
> to).

Well, the generic solution would be returning a bitmap of the CPUs that
were affected, but this is impractical. However, at least x86 should be
fine with the information "state change also on BSP", e.g. like this:
 0 - state change on one or more CPUs, none of them is the BSP
 1 - state change on BSP (and possible more CPUs)

> And what about PIC mode where interrupt receiver is not CPU?

In the end, there's always a CPU (or several of them).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 10:36 AM, Jan Kiszka wrote:
>
>> Assumes that CPU with
>> lowest index is BSP (that one we can actually guaranty if we want
>> to).
>>      
> Well, the generic solution would be returning a bitmap of the CPUs that
> were affected, but this is impractical. However, at least x86 should be
> fine with the information "state change also on BSP", e.g. like this:
>   0 - state change on one or more CPUs, none of them is the BSP
>   1 - state change on BSP (and possible more CPUs)
>    

What about ack notifiers?  Ask the APIC to notify you when an interrupt 
is acked.  That allows you to track the BSP, all cpus, or some subset.  
Masking can be seen at the irq controller level.

It's more involved, but provides more information.



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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Avi Kivity wrote:
> On 07/05/2010 10:36 AM, Jan Kiszka wrote:
>>
>>> Assumes that CPU with
>>> lowest index is BSP (that one we can actually guaranty if we want
>>> to).
>>>      
>> Well, the generic solution would be returning a bitmap of the CPUs that
>> were affected, but this is impractical. However, at least x86 should be
>> fine with the information "state change also on BSP", e.g. like this:
>>   0 - state change on one or more CPUs, none of them is the BSP
>>   1 - state change on BSP (and possible more CPUs)
>>    
> 
> What about ack notifiers?  Ask the APIC to notify you when an interrupt
> is acked.  That allows you to track the BSP, all cpus, or some subset. 
> Masking can be seen at the irq controller level.

So, if I understand you correctly, an IRQ state change that is ignored
due to masking would invoke the ack notifier chain as well?

> 
> It's more involved, but provides more information.

Well, it requires to establish ack notifier chains in parallel to the
existing IRQ delivery routes. Definitely more invasive.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Mon, Jul 05, 2010 at 11:07:56AM +0200, Jan Kiszka wrote:
> Avi Kivity wrote:
> > On 07/05/2010 10:36 AM, Jan Kiszka wrote:
> >>
> >>> Assumes that CPU with
> >>> lowest index is BSP (that one we can actually guaranty if we want
> >>> to).
> >>>      
> >> Well, the generic solution would be returning a bitmap of the CPUs that
> >> were affected, but this is impractical. However, at least x86 should be
> >> fine with the information "state change also on BSP", e.g. like this:
> >>   0 - state change on one or more CPUs, none of them is the BSP
> >>   1 - state change on BSP (and possible more CPUs)
> >>    
> > 
> > What about ack notifiers?  Ask the APIC to notify you when an interrupt
> > is acked.  That allows you to track the BSP, all cpus, or some subset. 
> > Masking can be seen at the irq controller level.
> 
> So, if I understand you correctly, an IRQ state change that is ignored
> due to masking would invoke the ack notifier chain as well?
> 
Ack notifiers go with mask notifiers.

> > 
> > It's more involved, but provides more information.
> 
> Well, it requires to establish ack notifier chains in parallel to the
> existing IRQ delivery routes. Definitely more invasive.
> 
> Jan
> 



--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 12:07 PM, Jan Kiszka wrote:
>
>> What about ack notifiers?  Ask the APIC to notify you when an interrupt
>> is acked.  That allows you to track the BSP, all cpus, or some subset.
>> Masking can be seen at the irq controller level.
>>      
> So, if I understand you correctly, an IRQ state change that is ignored
> due to masking would invoke the ack notifier chain as well?
>    

No - the cpu doesn't ack, no ack notifier.

We might need a separate mask notifier.  Just add pomodoro sauce.

>> It's more involved, but provides more information.
>>      
> Well, it requires to establish ack notifier chains in parallel to the
> existing IRQ delivery routes. Definitely more invasive.
>    

Right, and need to plumb it twice, once for qemu and once for kvm.

But my feeling is you get a lot more information out of it.

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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

Avi Kivity wrote:
> On 07/05/2010 12:07 PM, Jan Kiszka wrote:
>>
>>> What about ack notifiers?  Ask the APIC to notify you when an interrupt
>>> is acked.  That allows you to track the BSP, all cpus, or some subset.
>>> Masking can be seen at the irq controller level.
>>>      
>> So, if I understand you correctly, an IRQ state change that is ignored
>> due to masking would invoke the ack notifier chain as well?
>>    
> 
> No - the cpu doesn't ack, no ack notifier.
> 
> We might need a separate mask notifier.  Just add pomodoro sauce.

Mask notifiers would be a must, otherwise you cannot tell apart if an
IRQ was not yet ack'ed or is actually masked. On the other hand... see
below.

> 
>>> It's more involved, but provides more information.
>>>      
>> Well, it requires to establish ack notifier chains in parallel to the
>> existing IRQ delivery routes. Definitely more invasive.
>>    
> 
> Right, and need to plumb it twice, once for qemu and once for kvm.
> 
> But my feeling is you get a lot more information out of it.

That decoupling between state change and acknowledgment worries me.
Dispatching a source to multiple sinks or sharing a sink between
multiple source is no longer cleanly manageable this way. Just look at
the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
and a 'masked' from the ISA side (or vice versa). And the 'masked' will
arrive earlier. Not really straightforward to handle, is it?

Moreover, it requires a concrete algorithm that takes advantage from the
'ack' information bit (that should be the only additional information
you gain) to justify the additional effort. A "might have some
advantages" is not enough IMO. Do we have such an algorithm already?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 02:13 PM, Jan Kiszka wrote:
>
> That decoupling between state change and acknowledgment worries me.
> Dispatching a source to multiple sinks or sharing a sink between
> multiple source is no longer cleanly manageable this way. Just look at
> the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
> and a 'masked' from the ISA side (or vice versa). And the 'masked' will
> arrive earlier.

I think it is sufficient to only note masks and take action on acks.

> Not really straightforward to handle, is it?
>    

No question.

> Moreover, it requires a concrete algorithm that takes advantage from the
> 'ack' information bit (that should be the only additional information
> you gain) to justify the additional effort. A "might have some
> advantages" is not enough IMO. Do we have such an algorithm already?
>    

No.

The additional information is that you know which cpu(s) processed the 
interrupt, and when exactly.  I don't know how to translate it to a 
functional advantage, I just have a feeling that it is possible.

It's also architecturally cleaner.  Masks and acks are architectural 
events.  Injections are not - there's the edge on the LINT0 or INTI2 
pins, generation of an APIC message, receipt of the APIC message, and 
assertion of the APIC-to-core interrupt interface.  I'm not sure how the 
proposed interface maps to that.

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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

Avi Kivity wrote:
> On 07/05/2010 02:13 PM, Jan Kiszka wrote:
>> That decoupling between state change and acknowledgment worries me.
>> Dispatching a source to multiple sinks or sharing a sink between
>> multiple source is no longer cleanly manageable this way. Just look at
>> the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
>> and a 'masked' from the ISA side (or vice versa). And the 'masked' will
>> arrive earlier.
> 
> I think it is sufficient to only note masks and take action on acks.

We would increment our backlog on injection, decrement it on mask
notification - and decrement it again on ack.

> 
>> Not really straightforward to handle, is it?
>>    
> 
> No question.
> 
>> Moreover, it requires a concrete algorithm that takes advantage from the
>> 'ack' information bit (that should be the only additional information
>> you gain) to justify the additional effort. A "might have some
>> advantages" is not enough IMO. Do we have such an algorithm already?
>>    
> 
> No.
> 
> The additional information is that you know which cpu(s) processed the 
> interrupt, and when exactly.  I don't know how to translate it to a 
> functional advantage, I just have a feeling that it is possible.
> 
> It's also architecturally cleaner.  Masks and acks are architectural 
> events.  Injections are not - there's the edge on the LINT0 or INTI2 
> pins, generation of an APIC message, receipt of the APIC message, and 
> assertion of the APIC-to-core interrupt interface.  I'm not sure how the 
> proposed interface maps to that.

Our emulation does not reflect every architectural detail of the
delivery path anyway. The abstraction is always an IRQ line which can be
high or low (sometimes it is only high, but this is a bug).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Mon, Jul 05, 2010 at 02:16:56PM +0200, Jan Kiszka wrote:
> Avi Kivity wrote:
> > On 07/05/2010 02:13 PM, Jan Kiszka wrote:
> >> That decoupling between state change and acknowledgment worries me.
> >> Dispatching a source to multiple sinks or sharing a sink between
> >> multiple source is no longer cleanly manageable this way. Just look at
> >> the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
> >> and a 'masked' from the ISA side (or vice versa). And the 'masked' will
> >> arrive earlier.
> > 
> > I think it is sufficient to only note masks and take action on acks.
> 
> We would increment our backlog on injection, decrement it on mask
> notification - and decrement it again on ack.
> 
On mask notification backlog is zeroed and not incremented until unmask
notification.

--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 03:16 PM, Jan Kiszka wrote:
>
>> It's also architecturally cleaner.  Masks and acks are architectural
>> events.  Injections are not - there's the edge on the LINT0 or INTI2
>> pins, generation of an APIC message, receipt of the APIC message, and
>> assertion of the APIC-to-core interrupt interface.  I'm not sure how the
>> proposed interface maps to that.
>>      
> Our emulation does not reflect every architectural detail of the
> delivery path anyway.

Usually, when that happens, we get an obscure bug.

So if we add a facility, especially across the user/kernel boundary, 
it's better to have it conform to the architecture.  That reduces the 
chance it has a serious hidden bug.

> The abstraction is always an IRQ line which can be
> high or low (sometimes it is only high, but this is a bug).
>    

That's a bug in the use of qemu_irq, not qemu_irq itself.

But qemu_irq needs to remember its state, otherwise when an irq 
controller unmasks a level-triggered line, it won't see the interrupt.

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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

Gleb Natapov wrote:
> On Mon, Jul 05, 2010 at 02:16:56PM +0200, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>> On 07/05/2010 02:13 PM, Jan Kiszka wrote:
>>>> That decoupling between state change and acknowledgment worries me.
>>>> Dispatching a source to multiple sinks or sharing a sink between
>>>> multiple source is no longer cleanly manageable this way. Just look at
>>>> the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
>>>> and a 'masked' from the ISA side (or vice versa). And the 'masked' will
>>>> arrive earlier.
>>> I think it is sufficient to only note masks and take action on acks.
>> We would increment our backlog on injection, decrement it on mask
>> notification - and decrement it again on ack.
>>
> On mask notification backlog is zeroed and not incremented until unmask
> notification.

OK, so your idea is that mask/unmask notifiers report masking state
changes. I somehow had a different model in mind. Mmm, may work if we
put additional logic into those IRQ routers that have more than one
output per input. Only if all possible outputs are masked, this event
would be propagated up.

But how to deal with multiple acks per input due to multiple open
outputs (not just to different CPUs)? We either need to enable the
router to filter redundant information or support the injection source
with processing all acks properly.

And is there some scenario where the time-keeping device is sharing its
IRQ line with some other device? De-coalescing workarounds would not
work then if they were notifier based.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

Avi Kivity wrote:
> On 07/05/2010 03:16 PM, Jan Kiszka wrote:
>>> It's also architecturally cleaner.  Masks and acks are architectural
>>> events.  Injections are not - there's the edge on the LINT0 or INTI2
>>> pins, generation of an APIC message, receipt of the APIC message, and
>>> assertion of the APIC-to-core interrupt interface.  I'm not sure how the
>>> proposed interface maps to that.
>>>      
>> Our emulation does not reflect every architectural detail of the
>> delivery path anyway.
> 
> Usually, when that happens, we get an obscure bug.
> 
> So if we add a facility, especially across the user/kernel boundary, 
> it's better to have it conform to the architecture.  That reduces the 
> chance it has a serious hidden bug.

Neither ack/mask notifiers (past the IRQ controller) nor injection
return values are part of any architecture we emulate. What is driving
us are the requirements of the de-coalescing workarounds we want to
build on top and the impact on existing design.

> 
>> The abstraction is always an IRQ line which can be
>> high or low (sometimes it is only high, but this is a bug).
>>    
> 
> That's a bug in the use of qemu_irq, not qemu_irq itself.
> 
> But qemu_irq needs to remember its state, otherwise when an irq 
> controller unmasks a level-triggered line, it won't see the interrupt.

I think it's currently the IRQ controller's job to keep track of the
line state during masked periods. Moving this to qemu_irq is definitely
better but requires some care (e.g. when vmstates are involved).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 04:24 PM, Jan Kiszka wrote:
>
> But how to deal with multiple acks per input due to multiple open
> outputs (not just to different CPUs)?

That will be very rare (i.e. guest bug).

> We either need to enable the
> router to filter redundant information or support the injection source
> with processing all acks properly.
>
> And is there some scenario where the time-keeping device is sharing its
> IRQ line with some other device? De-coalescing workarounds would not
> work then if they were notifier based.
>    

In that case the timekeeping device needs to expose some kind of 
register the guest reads, to distinguish among the various sources.  If 
that's the case, then the qemu timekeeping code can look at accesses to 
this register instead of acks/deliveries.

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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Mon, Jul 05, 2010 at 04:42:06PM +0300, Avi Kivity wrote:
> On 07/05/2010 04:24 PM, Jan Kiszka wrote:
> >
> >But how to deal with multiple acks per input due to multiple open
> >outputs (not just to different CPUs)?
> 
> That will be very rare (i.e. guest bug).
> 
> >We either need to enable the
> >router to filter redundant information or support the injection source
> >with processing all acks properly.
> >
> >And is there some scenario where the time-keeping device is sharing its
> >IRQ line with some other device? De-coalescing workarounds would not
> >work then if they were notifier based.
> 
> In that case the timekeeping device needs to expose some kind of
> register the guest reads, to distinguish among the various sources.
> If that's the case, then the qemu timekeeping code can look at
> accesses to this register instead of acks/deliveries.
> 
RTC has such register, but Windows access it more the once on each
interrupt and that makes counting on this access unreliable for interrupt
decoalescing.

--
			Gleb.

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 04:28 PM, Jan Kiszka wrote:
> Avi Kivity wrote:
>    
>> On 07/05/2010 03:16 PM, Jan Kiszka wrote:
>>      
>>>> It's also architecturally cleaner.  Masks and acks are architectural
>>>> events.  Injections are not - there's the edge on the LINT0 or INTI2
>>>> pins, generation of an APIC message, receipt of the APIC message, and
>>>> assertion of the APIC-to-core interrupt interface.  I'm not sure how the
>>>> proposed interface maps to that.
>>>>
>>>>          
>>> Our emulation does not reflect every architectural detail of the
>>> delivery path anyway.
>>>        
>> Usually, when that happens, we get an obscure bug.
>>
>> So if we add a facility, especially across the user/kernel boundary,
>> it's better to have it conform to the architecture.  That reduces the
>> chance it has a serious hidden bug.
>>      
> Neither ack/mask notifiers (past the IRQ controller) nor injection
> return values are part of any architecture we emulate.

Right.  But placing a tap on something that exists architectually means 
it's likely to survive implementation changes.

>   What is driving
> us are the requirements of the de-coalescing workarounds we want to
> build on top and the impact on existing design.
>    

In the case of qemu<->kvm interfaces, also the longevity of these 
interfaces.

Note I'm not advocating a mask/ack solution.  It's pretty complicated 
and I'm not sure the benefits outweigh the complexity.  But I want us to 
examine all options, especially as I don't like delivery checks very much.

>>> The abstraction is always an IRQ line which can be
>>> high or low (sometimes it is only high, but this is a bug).
>>>
>>>        
>> That's a bug in the use of qemu_irq, not qemu_irq itself.
>>
>> But qemu_irq needs to remember its state, otherwise when an irq
>> controller unmasks a level-triggered line, it won't see the interrupt.
>>      
> I think it's currently the IRQ controller's job to keep track of the
> line state during masked periods. Moving this to qemu_irq is definitely
> better but requires some care (e.g. when vmstates are involved).
>    

If everything is done correctly no new vmstates are needed.  The irq 
producer, when its state is reloaded, will output exactly the same value 
as when the state was saved.

The irq line qemu_irq models doesn't have a flip-flop, so it doesn't 
have state.  Similarly, the irq inputs on the irq controllers don't have 
flip flops attached (some do), so ioapic->irr for example shouldn't be 
state.

(some care is needed on load to avoid spurious edges)

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

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Blue Swirl]

On Mon, Jul 5, 2010 at 1:47 PM, Avi Kivity <avi@redhat.com> wrote:
> On 07/05/2010 04:28 PM, Jan Kiszka wrote:
>>
>> Avi Kivity wrote:
>>
>>>
>>> On 07/05/2010 03:16 PM, Jan Kiszka wrote:
>>>
>>>>>
>>>>> It's also architecturally cleaner.  Masks and acks are architectural
>>>>> events.  Injections are not - there's the edge on the LINT0 or INTI2
>>>>> pins, generation of an APIC message, receipt of the APIC message, and
>>>>> assertion of the APIC-to-core interrupt interface.  I'm not sure how
>>>>> the
>>>>> proposed interface maps to that.
>>>>>
>>>>>
>>>>
>>>> Our emulation does not reflect every architectural detail of the
>>>> delivery path anyway.
>>>>
>>>
>>> Usually, when that happens, we get an obscure bug.
>>>
>>> So if we add a facility, especially across the user/kernel boundary,
>>> it's better to have it conform to the architecture.  That reduces the
>>> chance it has a serious hidden bug.
>>>
>>
>> Neither ack/mask notifiers (past the IRQ controller) nor injection
>> return values are part of any architecture we emulate.
>
> Right.  But placing a tap on something that exists architectually means it's
> likely to survive implementation changes.
>
>>  What is driving
>> us are the requirements of the de-coalescing workarounds we want to
>> build on top and the impact on existing design.
>>
>
> In the case of qemu<->kvm interfaces, also the longevity of these
> interfaces.
>
> Note I'm not advocating a mask/ack solution.  It's pretty complicated and
> I'm not sure the benefits outweigh the complexity.  But I want us to examine
> all options, especially as I don't like delivery checks very much.

Since you seem to have gone back to drawing board, how about the
following design:

Explicit qemu_irqs and muxes for the backwards channel

Each participating device has a set of GPIOs (implemented with
qemu_irq) for any backwards signals: delivered, coalesced, EOI'd,
masked (short D/C/E/M). For each incoming IRQ line, there would be
four backwards GPIOs (D/C/E/M).

When a forward IRQ signal is propagated, any intermediate devices turn
the internal 'mux' dial to point to the originating device GPIO.

When a backwards signal (one of D/C/E/M) must be delivered, the mux
forwards the D/C/E/M signal in question towards the last IRQ
originator as indicated by the dial.

I think this design would cover the coalescing needs, it would not
change qemu_irq design and it should be expandable. Drawbacks would be
that a lot of signals would be needed and all these signal's routes
should be set up by the board level.

>
>>>> The abstraction is always an IRQ line which can be
>>>> high or low (sometimes it is only high, but this is a bug).
>>>>
>>>>
>>>
>>> That's a bug in the use of qemu_irq, not qemu_irq itself.
>>>
>>> But qemu_irq needs to remember its state, otherwise when an irq
>>> controller unmasks a level-triggered line, it won't see the interrupt.
>>>
>>
>> I think it's currently the IRQ controller's job to keep track of the
>> line state during masked periods. Moving this to qemu_irq is definitely
>> better but requires some care (e.g. when vmstates are involved).
>>
>
> If everything is done correctly no new vmstates are needed.  The irq
> producer, when its state is reloaded, will output exactly the same value as
> when the state was saved.
>
> The irq line qemu_irq models doesn't have a flip-flop, so it doesn't have
> state.  Similarly, the irq inputs on the irq controllers don't have flip
> flops attached (some do), so ioapic->irr for example shouldn't be state.
>
> (some care is needed on load to avoid spurious edges)
>
> --
> error compiling committee.c: too many arguments to function
>
>

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Jan Kiszka]

Blue Swirl wrote:
> On Mon, Jul 5, 2010 at 1:47 PM, Avi Kivity <avi@redhat.com> wrote:
>> On 07/05/2010 04:28 PM, Jan Kiszka wrote:
>>> Avi Kivity wrote:
>>>
>>>> On 07/05/2010 03:16 PM, Jan Kiszka wrote:
>>>>
>>>>>> It's also architecturally cleaner.  Masks and acks are architectural
>>>>>> events.  Injections are not - there's the edge on the LINT0 or INTI2
>>>>>> pins, generation of an APIC message, receipt of the APIC message, and
>>>>>> assertion of the APIC-to-core interrupt interface.  I'm not sure how
>>>>>> the
>>>>>> proposed interface maps to that.
>>>>>>
>>>>>>
>>>>> Our emulation does not reflect every architectural detail of the
>>>>> delivery path anyway.
>>>>>
>>>> Usually, when that happens, we get an obscure bug.
>>>>
>>>> So if we add a facility, especially across the user/kernel boundary,
>>>> it's better to have it conform to the architecture.  That reduces the
>>>> chance it has a serious hidden bug.
>>>>
>>> Neither ack/mask notifiers (past the IRQ controller) nor injection
>>> return values are part of any architecture we emulate.
>> Right.  But placing a tap on something that exists architectually means it's
>> likely to survive implementation changes.
>>
>>>  What is driving
>>> us are the requirements of the de-coalescing workarounds we want to
>>> build on top and the impact on existing design.
>>>
>> In the case of qemu<->kvm interfaces, also the longevity of these
>> interfaces.
>>
>> Note I'm not advocating a mask/ack solution.  It's pretty complicated and
>> I'm not sure the benefits outweigh the complexity.  But I want us to examine
>> all options, especially as I don't like delivery checks very much.
> 
> Since you seem to have gone back to drawing board, how about the
> following design:
> 
> Explicit qemu_irqs and muxes for the backwards channel
> 
> Each participating device has a set of GPIOs (implemented with
> qemu_irq) for any backwards signals: delivered, coalesced, EOI'd,
> masked (short D/C/E/M). For each incoming IRQ line, there would be
> four backwards GPIOs (D/C/E/M).
> 
> When a forward IRQ signal is propagated, any intermediate devices turn
> the internal 'mux' dial to point to the originating device GPIO.
> 
> When a backwards signal (one of D/C/E/M) must be delivered, the mux
> forwards the D/C/E/M signal in question towards the last IRQ
> originator as indicated by the dial.

E & M can arrive in arbitrary order, so this does not yet improve the
dispatching issue we discussed during the day. D & C work just like
return values as they will be reported instantly.

> 
> I think this design would cover the coalescing needs, it would not
> change qemu_irq design and it should be expandable. Drawbacks would be
> that a lot of signals would be needed and all these signal's routes
> should be set up by the board level.

The drawback of this approach compared to all others is that no
information about the accepting CPUs is reported back. That's obviously
required for some Windows SMP guests. At the bare minimum, you would
need another line that tells BSP delivery apart from delivery to other CPUs.

However, I do not see the benefits of this approach over specialized
ack/mask callbacks.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 08:12 PM, Blue Swirl wrote:
>
> Since you seem to have gone back to drawing board, how about the
> following design:
>
> Explicit qemu_irqs and muxes for the backwards channel
>
>    
[...]

The question of how to design the thing is secondary to me, at present.  
IMO the first question we have to answer is whether we track interrupts 
by delivery (queued into the core/apic, coalesced by core/apic, or 
masked at the irq controller) or mask/ack (masked before the core, or 
acknowledged by guest software; coalescing can be derived from nr_irq > 
nr_acks).  The two approaches provide different information, I don't 
currently have a feel for which is better.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Ben A]

Apparently this bug's still alive and kicking.

There's an obvious clock skew problem on Windows 7; in the Date & Time
dialog, the clock jumps through seconds visibly too fast.

I also found a case where HPET bugs are causing a real problem: Terraria
(dedicated server) seems to be relying on (something that relies on)
HPET, and QEMU doesn't get it right. The result is a goofy and
aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
makes killing anything tougher than a normal zombie basically
impossible.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Confirmed

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Ben A]

Forgot to add: Reproduced the above behavior in both 1.5.1 and 1.6.0.
Adding -no-hpet to commandline removed both problems (full disclosure:
this fix wasn't tested in 1.5.1 but I have no reason to believe behavior
would be different.)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Confirmed

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote:
> Apparently this bug's still alive and kicking.
> 
And no plans to fix it. Do not use hpet with windows guests this buys
you nothing.

> There's an obvious clock skew problem on Windows 7; in the Date & Time
> dialog, the clock jumps through seconds visibly too fast.
> 
> I also found a case where HPET bugs are causing a real problem: Terraria
> (dedicated server) seems to be relying on (something that relies on)
> HPET, and QEMU doesn't get it right. The result is a goofy and
> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
> makes killing anything tougher than a normal zombie basically
> impossible.
> 
> -- 
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/599958
> 
> Title:
>   Timedrift problems with Win7: hpet missing time drift fixups
> 
> Status in QEMU:
>   Confirmed
> 
> Bug description:
>   We've been finding timedrift issues witth Win7 under qemu-kvm on our
>   daily testing
> 
>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds
> 
>   Steps to reproduce:
> 
>   timedrift.with_load
> 
>   1) Log into a guest.
>   2) Take a time reading from the guest and host.
>   3) Run load on the guest and host.
>   4) Take a second time reading.
>   5) Stop the load and rest for a while.
>   6) Take a third time reading.
>   7) If the drift immediately after load is higher than a user-
>       specified value (in %), fail.
>       If the drift after the rest period is higher than a user-specified value,
>       fail.
> 
>   timedrift.with_migration
> 
>   1) Log into a guest.
>   2) Take a time reading from the guest and host.
>   3) Migrate the guest.
>   4) Take a second time reading.
>   5) If the drift (in seconds) is higher than a user specified value, fail.
> 
>   timedrift.with_reboot
> 
>   1) Log into a guest.
>   2) Take a time reading from the guest and host.
>   3) Reboot the guest.
>   4) Take a second time reading.
>   5) If the drift (in seconds) is higher than a user specified value, fail.
> 
>   This bug is to register those issues and keep an eye on them.
> 
>   Attached, some logs from the autotest tests executed on the guest
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

--
			Gleb.

Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Ben "Root" Anderson]

Fair enough in itself, but if HPET is known to have problems with
arguably the most popular OS family to use as a guest, why is it
enabled by default?

On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote:
>> Apparently this bug's still alive and kicking.
>>
> And no plans to fix it. Do not use hpet with windows guests this buys
> you nothing.
>
>> There's an obvious clock skew problem on Windows 7; in the Date & Time
>> dialog, the clock jumps through seconds visibly too fast.
>>
>> I also found a case where HPET bugs are causing a real problem: Terraria
>> (dedicated server) seems to be relying on (something that relies on)
>> HPET, and QEMU doesn't get it right. The result is a goofy and
>> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
>> makes killing anything tougher than a normal zombie basically
>> impossible.
>>
>> --
>> You received this bug notification because you are a member of qemu-
>> devel-ml, which is subscribed to QEMU.
>> https://bugs.launchpad.net/bugs/599958
>>
>> Title:
>>   Timedrift problems with Win7: hpet missing time drift fixups
>>
>> Status in QEMU:
>>   Confirmed
>>
>> Bug description:
>>   We've been finding timedrift issues witth Win7 under qemu-kvm on our
>>   daily testing
>>
>>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load   FAIL    1       Time drift too large after rest period: 38.63%
>>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL    1       Time drift too large at iteration 1: 17.77 seconds
>>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration      FAIL    1       Time drift too large at iteration 2: 3.08 seconds
>>
>>   Steps to reproduce:
>>
>>   timedrift.with_load
>>
>>   1) Log into a guest.
>>   2) Take a time reading from the guest and host.
>>   3) Run load on the guest and host.
>>   4) Take a second time reading.
>>   5) Stop the load and rest for a while.
>>   6) Take a third time reading.
>>   7) If the drift immediately after load is higher than a user-
>>       specified value (in %), fail.
>>       If the drift after the rest period is higher than a user-specified value,
>>       fail.
>>
>>   timedrift.with_migration
>>
>>   1) Log into a guest.
>>   2) Take a time reading from the guest and host.
>>   3) Migrate the guest.
>>   4) Take a second time reading.
>>   5) If the drift (in seconds) is higher than a user specified value, fail.
>>
>>   timedrift.with_reboot
>>
>>   1) Log into a guest.
>>   2) Take a time reading from the guest and host.
>>   3) Reboot the guest.
>>   4) Take a second time reading.
>>   5) If the drift (in seconds) is higher than a user specified value, fail.
>>
>>   This bug is to register those issues and keep an eye on them.
>>
>>   Attached, some logs from the autotest tests executed on the guest
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions
>
> --
>                         Gleb.

Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote:
> Fair enough in itself, but if HPET is known to have problems with
> arguably the most popular OS family to use as a guest, why is it
> enabled by default?
> 
Arguably :) But QEMU defaults are arguably far from been optimal for any
guest.

> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote:
> >> Apparently this bug's still alive and kicking.
> >>
> > And no plans to fix it. Do not use hpet with windows guests this buys
> > you nothing.
> >
> >> There's an obvious clock skew problem on Windows 7; in the Date & Time
> >> dialog, the clock jumps through seconds visibly too fast.
> >>
> >> I also found a case where HPET bugs are causing a real problem: Terraria
> >> (dedicated server) seems to be relying on (something that relies on)
> >> HPET, and QEMU doesn't get it right. The result is a goofy and
> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
> >> makes killing anything tougher than a normal zombie basically
> >> impossible.
> >>
> >> --
> >> You received this bug notification because you are a member of qemu-
> >> devel-ml, which is subscribed to QEMU.
> >> https://bugs.launchpad.net/bugs/599958
> >>
> >> Title:
> >>   Timedrift problems with Win7: hpet missing time drift fixups
> >>
> >> Status in QEMU:
> >>   Confirmed
> >>
> >> Bug description:
> >>   We've been finding timedrift issues witth Win7 under qemu-kvm on our
> >>   daily testing
> >>
> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load   FAIL    1       Time drift too large after rest period: 38.63%
> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL    1       Time drift too large at iteration 1: 17.77 seconds
> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration      FAIL    1       Time drift too large at iteration 2: 3.08 seconds
> >>
> >>   Steps to reproduce:
> >>
> >>   timedrift.with_load
> >>
> >>   1) Log into a guest.
> >>   2) Take a time reading from the guest and host.
> >>   3) Run load on the guest and host.
> >>   4) Take a second time reading.
> >>   5) Stop the load and rest for a while.
> >>   6) Take a third time reading.
> >>   7) If the drift immediately after load is higher than a user-
> >>       specified value (in %), fail.
> >>       If the drift after the rest period is higher than a user-specified value,
> >>       fail.
> >>
> >>   timedrift.with_migration
> >>
> >>   1) Log into a guest.
> >>   2) Take a time reading from the guest and host.
> >>   3) Migrate the guest.
> >>   4) Take a second time reading.
> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
> >>
> >>   timedrift.with_reboot
> >>
> >>   1) Log into a guest.
> >>   2) Take a time reading from the guest and host.
> >>   3) Reboot the guest.
> >>   4) Take a second time reading.
> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
> >>
> >>   This bug is to register those issues and keep an eye on them.
> >>
> >>   Attached, some logs from the autotest tests executed on the guest
> >>
> >> To manage notifications about this bug go to:
> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions
> >
> > --
> >                         Gleb.

--
			Gleb.

Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Ben "Root" Anderson]

Agh, I forgot reply all.

Seems like something that should be changed, no? It would've saved me
a lot of headache if there was a switch e.g.
-optimize-for=[linux,winxp,
win7,etc] that changed the defaults to be
most accomodating to the specified OS as a guest.

On Tue, Oct 1, 2013 at 11:33 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote:
>> Fair enough in itself, but if HPET is known to have problems with
>> arguably the most popular OS family to use as a guest, why is it
>> enabled by default?
>>
> Arguably :) But QEMU defaults are arguably far from been optimal for any
> guest.
>
>> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <gleb@redhat.com> wrote:
>> > On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote:
>> >> Apparently this bug's still alive and kicking.
>> >>
>> > And no plans to fix it. Do not use hpet with windows guests this buys
>> > you nothing.
>> >
>> >> There's an obvious clock skew problem on Windows 7; in the Date & Time
>> >> dialog, the clock jumps through seconds visibly too fast.
>> >>
>> >> I also found a case where HPET bugs are causing a real problem: Terraria
>> >> (dedicated server) seems to be relying on (something that relies on)
>> >> HPET, and QEMU doesn't get it right. The result is a goofy and
>> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
>> >> makes killing anything tougher than a normal zombie basically
>> >> impossible.
>> >>
>> >> --
>> >> You received this bug notification because you are a member of qemu-
>> >> devel-ml, which is subscribed to QEMU.
>> >> https://bugs.launchpad.net/bugs/599958
>> >>
>> >> Title:
>> >>   Timedrift problems with Win7: hpet missing time drift fixups
>> >>
>> >> Status in QEMU:
>> >>   Confirmed
>> >>
>> >> Bug description:
>> >>   We've been finding timedrift issues witth Win7 under qemu-kvm on our
>> >>   daily testing
>> >>
>> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load   FAIL    1       Time drift too large after rest period: 38.63%
>> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL    1       Time drift too large at iteration 1: 17.77 seconds
>> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration      FAIL    1       Time drift too large at iteration 2: 3.08 seconds
>> >>
>> >>   Steps to reproduce:
>> >>
>> >>   timedrift.with_load
>> >>
>> >>   1) Log into a guest.
>> >>   2) Take a time reading from the guest and host.
>> >>   3) Run load on the guest and host.
>> >>   4) Take a second time reading.
>> >>   5) Stop the load and rest for a while.
>> >>   6) Take a third time reading.
>> >>   7) If the drift immediately after load is higher than a user-
>> >>       specified value (in %), fail.
>> >>       If the drift after the rest period is higher than a user-specified value,
>> >>       fail.
>> >>
>> >>   timedrift.with_migration
>> >>
>> >>   1) Log into a guest.
>> >>   2) Take a time reading from the guest and host.
>> >>   3) Migrate the guest.
>> >>   4) Take a second time reading.
>> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
>> >>
>> >>   timedrift.with_reboot
>> >>
>> >>   1) Log into a guest.
>> >>   2) Take a time reading from the guest and host.
>> >>   3) Reboot the guest.
>> >>   4) Take a second time reading.
>> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
>> >>
>> >>   This bug is to register those issues and keep an eye on them.
>> >>
>> >>   Attached, some logs from the autotest tests executed on the guest
>> >>
>> >> To manage notifications about this bug go to:
>> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions
>> >
>> > --
>> >                         Gleb.
>
> --
>                         Gleb.

Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Gleb Natapov]

On Tue, Oct 01, 2013 at 11:36:39AM -0500, Ben "Root" Anderson wrote:
> Agh, I forgot reply all.
> 
I have to re reply now :)

> Seems like something that should be changed, no? It would've saved me
> a lot of headache if there was a switch e.g.
> -optimize-for=[linux,winxp,
> win7,etc] that changed the defaults to be
> most accomodating to the specified OS as a guest.
> 
QEMU developers see it to be a management job. Management
(libvirt/virt-manager) knows what guest is and what optimal config is. I
am not sure they use -no-hpet for windows currently if they do not it
should be changed there.

> On Tue, Oct 1, 2013 at 11:33 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote:
> >> Fair enough in itself, but if HPET is known to have problems with
> >> arguably the most popular OS family to use as a guest, why is it
> >> enabled by default?
> >>
> > Arguably :) But QEMU defaults are arguably far from been optimal for any
> > guest.
> >
> >> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote:
> >> >> Apparently this bug's still alive and kicking.
> >> >>
> >> > And no plans to fix it. Do not use hpet with windows guests this buys
> >> > you nothing.
> >> >
> >> >> There's an obvious clock skew problem on Windows 7; in the Date & Time
> >> >> dialog, the clock jumps through seconds visibly too fast.
> >> >>
> >> >> I also found a case where HPET bugs are causing a real problem: Terraria
> >> >> (dedicated server) seems to be relying on (something that relies on)
> >> >> HPET, and QEMU doesn't get it right. The result is a goofy and
> >> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it
> >> >> makes killing anything tougher than a normal zombie basically
> >> >> impossible.
> >> >>
> >> >> --
> >> >> You received this bug notification because you are a member of qemu-
> >> >> devel-ml, which is subscribed to QEMU.
> >> >> https://bugs.launchpad.net/bugs/599958
> >> >>
> >> >> Title:
> >> >>   Timedrift problems with Win7: hpet missing time drift fixups
> >> >>
> >> >> Status in QEMU:
> >> >>   Confirmed
> >> >>
> >> >> Bug description:
> >> >>   We've been finding timedrift issues witth Win7 under qemu-kvm on our
> >> >>   daily testing
> >> >>
> >> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load   FAIL    1       Time drift too large after rest period: 38.63%
> >> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL    1       Time drift too large at iteration 1: 17.77 seconds
> >> >>   kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration      FAIL    1       Time drift too large at iteration 2: 3.08 seconds
> >> >>
> >> >>   Steps to reproduce:
> >> >>
> >> >>   timedrift.with_load
> >> >>
> >> >>   1) Log into a guest.
> >> >>   2) Take a time reading from the guest and host.
> >> >>   3) Run load on the guest and host.
> >> >>   4) Take a second time reading.
> >> >>   5) Stop the load and rest for a while.
> >> >>   6) Take a third time reading.
> >> >>   7) If the drift immediately after load is higher than a user-
> >> >>       specified value (in %), fail.
> >> >>       If the drift after the rest period is higher than a user-specified value,
> >> >>       fail.
> >> >>
> >> >>   timedrift.with_migration
> >> >>
> >> >>   1) Log into a guest.
> >> >>   2) Take a time reading from the guest and host.
> >> >>   3) Migrate the guest.
> >> >>   4) Take a second time reading.
> >> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
> >> >>
> >> >>   timedrift.with_reboot
> >> >>
> >> >>   1) Log into a guest.
> >> >>   2) Take a time reading from the guest and host.
> >> >>   3) Reboot the guest.
> >> >>   4) Take a second time reading.
> >> >>   5) If the drift (in seconds) is higher than a user specified value, fail.
> >> >>
> >> >>   This bug is to register those issues and keep an eye on them.
> >> >>
> >> >>   Attached, some logs from the autotest tests executed on the guest
> >> >>
> >> >> To manage notifications about this bug go to:
> >> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions
> >> >
> >> > --
> >> >                         Gleb.
> >
> > --
> >                         Gleb.

--
			Gleb.

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[AndCycle]

I google about an old link talk about this issue can be fixed by not
using virtio

http://forum.proxmox.com/archive/index.php/t-5783.html

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Confirmed

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Thomas Huth]

Looking through old bug tickets... can this issue still be reproduced
with the latest version of QEMU? Or could we close this ticket nowadays?


** Changed in: qemu
       Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Incomplete

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Lucas Meneghel Rodrigues]

Absolutely, please close it.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Incomplete

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions

[Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958

Title:
  Timedrift problems with Win7: hpet missing time drift fixups

Status in QEMU:
  Expired

Bug description:
  We've been finding timedrift issues witth Win7 under qemu-kvm on our
  daily testing

  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load	FAIL	1	Time drift too large after rest period: 38.63%
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot	FAIL	1	Time drift too large at iteration 1: 17.77 seconds
  kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration	FAIL	1	Time drift too large at iteration 2: 3.08 seconds

  Steps to reproduce:

  timedrift.with_load

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Run load on the guest and host.
  4) Take a second time reading.
  5) Stop the load and rest for a while.
  6) Take a third time reading.
  7) If the drift immediately after load is higher than a user-
      specified value (in %), fail.
      If the drift after the rest period is higher than a user-specified value,
      fail.

  timedrift.with_migration

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Migrate the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  timedrift.with_reboot

  1) Log into a guest.
  2) Take a time reading from the guest and host.
  3) Reboot the guest.
  4) Take a second time reading.
  5) If the drift (in seconds) is higher than a user specified value, fail.

  This bug is to register those issues and keep an eye on them.

  Attached, some logs from the autotest tests executed on the guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions