From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34366 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIi4O-0001FG-S3 for qemu-devel@nongnu.org; Sun, 30 May 2010 08:56:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIi4N-0003mx-Jd for qemu-devel@nongnu.org; Sun, 30 May 2010 08:56:48 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:34727) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIi4N-0003mq-77 for qemu-devel@nongnu.org; Sun, 30 May 2010 08:56:47 -0400 Received: by pwi7 with SMTP id 7so444373pwi.4 for ; Sun, 30 May 2010 05:56:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100530123316.GB24302@redhat.com> References: <20100528204746.GC3604@redhat.com> <4C00C921.2060809@web.de> <20100529144641.GF3604@redhat.com> <20100529163709.GJ3604@redhat.com> <20100530060255.GJ5474@redhat.com> <20100530123316.GB24302@redhat.com> From: Blue Swirl Date: Sun, 30 May 2010 12:56:26 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Content-Type: multipart/mixed; boundary=000e0cd1a83acfceae0487cf45a3 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela --000e0cd1a83acfceae0487cf45a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2010/5/30 Gleb Natapov : > 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 th= e >> >> >> emulation, this means loss of ticks which should have been deliver= ed >> >> >> before the change. >> >> >> >> >> > I haven't missed it. I describe to you reality of the situation. Yo= u want >> >> > to change reality to be more close to what you want it to be by add= ing >> >> > 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: >> > =C2=A0Gleb only mentioned the frequency change, I thought that was not= so big >> > =C2=A0problem. But I don't think this case should be allowed happen at= all, >> > =C2=A0it 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 =3D 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. Strange. Here's a working binary. > >> >> >> >> By default the APIC's delivery method for IRQs is ExtInt and >> >> coalescing counting happens only with Fixed. This means that the gues= t >> >> 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-ha= ck >> > 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 p= ut >> > 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? No, at least OpenBSD 4.4 doesn't seem to use RTC. --000e0cd1a83acfceae0487cf45a3 Content-Type: application/x-bzip2; name="coalescing.bin.bz2" Content-Disposition: attachment; filename="coalescing.bin.bz2" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9tvfhgv0 QlpoOTFBWSZTWVkuXGAAAHn///3c4QFxAWQAQABACAEAYAoIAVgIaABAREBAwEBFGEQZsADZaDSK P1Iek9QAA002kBkD1NNpqMImjSNRiNNAYjJiZAyD0maICKUmmk8gCMmTBMJk0xDI0xMq9SIRT6hS iFpQCidKJABWnCrMFnsSc4VVWWLsNEM0KAAUfd61LPCzwIABD8uj2BIaZki/aAjmZKwZdLVdpIQY iXBVjRAEAJSrwbRAlntBRiFgkFg3jtNilACBld0OAd78vi0lhWgdCnMMraHVW3yhq6Tn892UfaXT neVtcs62RYEC49IIiIiLlH/TW8HXYLuSKcKEgsly4wA= --000e0cd1a83acfceae0487cf45a3--