2010/5/30 Gleb Natapov <g...@redhat.com>: > 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?
Seems to be PIT. OpenBSD: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/isa/clock.c?rev=1.42 FreeBSD: http://fxr.watson.org/fxr/source/x86/isa/clock.c?im=bigexcerpts Didn't find NetBSD clock.
