On Sun, May 30, 2010 at 12:10:16PM +0000, Blue Swirl wrote: > >> >> You missed the key word 'stopped'. If the timer is really stopped, no > >> >> IRQs should ever come out afterwards, just like on real HW. For the > >> >> emulation, this means loss of ticks which should have been delivered > >> >> before the change. > >> >> > >> > I haven't missed it. I describe to you reality of the situation. You want > >> > to change reality to be more close to what you want it to be by adding > >> > words to my description. > >> > >> Quoting Jan: 'So what to do with the backlog when the timer is > >> stopped?' I didn't add any words to your description, please be more > >> careful with your attributions. Why do you think I want to change the > >> reality? > > Please refer to my words when you answer to my quote. You quoted my > > answer to you statement: > > Gleb only mentioned the frequency change, I thought that was not so big > > problem. But I don't think this case should be allowed happen at all, > > it can't exist on real HW. > > With 'this case' I was referring to 'case with timer stopped', not > 'case which Gleb mentioned'. > > > No 'stopped' was under discussion nowhere. > > It's clearly written there in the sentence Jan wrote. > Jan, not me, but lets leave this topic alone since you agree that stopped is just a case of frequency change anyway.
> > FWIW 'stopped' is just a case > > of frequency change. > > True. > > > > >> > >> XP frequency change isn't the same case as timer being stopped. > >> > > And what is the big difference exactly? > > Because after the timer is stopped, its extremely unrealistic to send > any IRQs. Whereas if the frequency is changed to some other nonzero > value, we can cheat and inject some more queued IRQs. > Correct, when gets disables clock source (by reset or any other means) coalesced backlog should be forgotten. > Anyway, if this case is not interesting because it doesn't happen in > real life emulation scenarios, we can forget it no matter how buggy > the current QEMU implementation is. > > >> > Please just go write code, experiment, debug > >> > and _then_ come here with design. > >> > >> I added some debugging to RTC, PIC and APIC. I also built a small > >> guest in x86 assembly to test the coalescing. However, in the tests > >> with this guest and others I noticed that the coalescing only happens > >> in some obscure conditions. > > So try with real guest and with real load. > > Well, I'd like to get the test program also trigger it. Now I'm getting: > apic: write: 00000350 = 00000000 > apic: apic_reset_irq_delivered: old coalescing 0 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 1 > apic: apic_get_irq_delivered: returning coalescing 1 > apic: apic_reset_irq_delivered: old coalescing 1 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 0 > apic: apic_get_irq_delivered: returning coalescing 0 > apic: apic_reset_irq_delivered: old coalescing 0 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 0 > > It looks like some other IRQs cause the coalescing, because also > looking at RTC code, it seems it's not possible for RTC to raise the > IRQ (except update IRQ, alarm etc.) without calling > apic_reset_irq_delivered(). > > I've attached my test program. Compile: > gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T > coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin > > Run: > qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack > The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0x00000000fffffff0 to 0x00000000000f003e and back. > >> > >> By default the APIC's delivery method for IRQs is ExtInt and > >> coalescing counting happens only with Fixed. This means that the guest > >> needs to reprogram APIC. It also looks like RTC interrupts need to be > >> triggered. But I didn't see both of these to happen simultaneously in > >> my tests with Linux and Windows guests. Of course, -rtc-td-hack flag > >> must be used and I also disabled HPET to be sure that RTC would be > >> used. > >> > >> With DEBUG_COALESCING enabled, I just get increasing numbers for > >> apic_irq_delivered: > >> apic: apic_set_irq: coalescing 67123 > >> apic: apic_set_irq: coalescing 67124 > >> apic: apic_set_irq: coalescing 67125 > > So have you actually used -rtc-td-hack option? I compiled head of > > qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack > > and I get: > > apic: apic_reset_irq_delivered: old coalescing 3 > > apic: apic_set_irq: coalescing 1 > > apic: apic_get_irq_delivered: returning coalescing 1 > > apic: apic_set_irq: coalescing 2 > > apic: apic_set_irq: coalescing 3 > > apic: apic_set_irq: coalescing 4 > > apic: apic_set_irq: coalescing 5 > > apic: apic_set_irq: coalescing 6 > > apic: apic_reset_irq_delivered: old coalescing 6 > > apic: apic_set_irq: coalescing 1 > > apic: apic_get_irq_delivered: returning coalescing 1 > > > >> > >> If the hack were active, the numbers would be close to zero (or at > >> least some point) because apic_reset_irq_delivered would be called, > >> but this does not happen. Could you specify a clear test case with > >> which the coalescing action could be tested? Linux or BSD based, > >> please. > > Linux don't use RTC as time source and I don't know about BSD, so no > > Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put > > heavy load on the host. You can run video inside the gust to trigger > > coalescing more easily. > > I don't have Windows XP, sorry. > Will be hard to debug Windows time drift without Windows ;) Do you know what time source BSD uses? -- Gleb.