From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50892 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIhLj-0004oa-24 for qemu-devel@nongnu.org; Sun, 30 May 2010 08:10:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIhLh-00040g-M0 for qemu-devel@nongnu.org; Sun, 30 May 2010 08:10:38 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:63528) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIhLh-00040G-Dx for qemu-devel@nongnu.org; Sun, 30 May 2010 08:10:37 -0400 Received: by pwi7 with SMTP id 7so436027pwi.4 for ; Sun, 30 May 2010 05:10:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100530060255.GJ5474@redhat.com> References: <20100528073135.GC17805@redhat.com> <20100528204746.GC3604@redhat.com> <4C00C921.2060809@web.de> <20100529144641.GF3604@redhat.com> <20100529163709.GJ3604@redhat.com> <20100530060255.GJ5474@redhat.com> From: Blue Swirl Date: Sun, 30 May 2010 12:10:16 +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=000e0cd1a0feb583020487cea007 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 --000e0cd1a0feb583020487cea007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2010/5/30 Gleb Natapov : > On Sat, May 29, 2010 at 09:21:14PM +0000, Blue Swirl wrote: >> On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov wrote: >> > On Sat, May 29, 2010 at 04:13:22PM +0000, Blue Swirl wrote: >> >> On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov wrote= : >> >> > On Sat, May 29, 2010 at 09:35:30AM +0000, Blue Swirl wrote: >> >> >> > I still don't see how the alternative is supposed to simplify ou= r life >> >> >> > or improve the efficiency of the de-coalescing workaround. It's = rather >> >> >> > problematic like Gleb pointed out: The de-coalescing logic needs= to be >> >> >> > informed about periodicity changes that can only be delivered al= ong >> >> >> > IRQs. So what to do with the backlog when the timer is stopped? >> >> >> >> >> >> What happens with the current design? 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. >> >> >> >> >> > Hm, why it can't exist on real HW? Do simple exercise. Run WindowsX= P >> >> > inside QEMU, connect with gdb to QEMU process and check what freque= ncy >> >> > RTC configured with (hint: it will be 64Hz), now run video inside t= he >> >> > guest and check frequency again (hint: it will be 1Khz). >> >> >> >> 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 w= ant >> > 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: > =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 al= l, > =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. > 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. 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 >> >> 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. > >> >> >> But what if the guest changed the frequency very often, and between >> >> changes used zero value, like 64Hz -> 0Hz -> 128Hz -> 0Hz -> 64Hz? >> > Too bad, the world is not perfect. >> > >> > -- >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Gleb. >> > > > -- > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Gleb. > --000e0cd1a0feb583020487cea007 Content-Type: application/octet-stream; name="coalescing.S" Content-Disposition: attachment; filename="coalescing.S" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9ttq9do0 CiAgICAgICAgLnNlY3Rpb24gLnRleHQsICJheCIKICAgICAgICAuY29kZTE2Z2NjCgojZGVmaW5l IE8ocG9ydCwgdmFsKSAgICAgICAgICAgIFwKICAgICAgICBtb3ZiICAgICR2YWwsICVhbDsgICAg ICBcCiAgICAgICAgb3V0ICAgICAlYWwsICRwb3J0CiNkZWZpbmUgUlRDX08ocG9ydCwgdmFsKSAg ICAgICAgXAogICAgICAgIE8oMHg3MCwgcG9ydCk7ICAgICAgICAgIFwKICAgICAgICBPKDB4NzEs IHZhbCkKI2RlZmluZSBSVENfSShwb3J0KSAgICAgICAgICAgICBcCiAgICAgICAgTygweDcwLCBw b3J0KTsgICAgICAgICAgXAogICAgICAgIGluICAgICAgJDB4NzEsICVhbAoKICAgICAgICAub3Jn IDB4MTAwMDAKICAgICAgICAuZ2xvYmwgc3RhcnQKc3RhcnQ6CiAgICAgICAgLyogQTIwICovCiAg ICAgICAgTygweDkyLCAweDAxKQoKICAgICAgICAvKiBJRFQgKi8KICAgICAgICBsaWR0dyAgICVj czoweDIwMDAKCiAgICAgICAgLyogR0RUICovCiAgICAgICAgbGdkdHcgICAlY3M6MHgyMDEwCgog ICAgICAgIC8qIFN3aXRjaCB0byBwcm90ZWN0ZWQgbW9kZSAqLwogICAgICAgIG1vdmwgICAgJWNy MCwgJWVheAogICAgICAgIG9ybCAgICAgJDEsICVlYXgKICAgICAgICBtb3ZsICAgICVlYXgsICVj cjAKICAgICAgICBsam1wbCAgICQ4LCAkMHhmNDAwMAogICAgICAgIC5vcmcgMHgxMTAwMAoKICAg ICAgICAuY29kZTMyCgogICAgICAgIC8qIElOVCA3MCBoYW5kbGVyICovCiAgICAgICAgUlRDX0ko MHhjKQogICAgICAgIE8oMHhhMCwgMHgyMCkKICAgICAgICBPKDB4MjAsIDB4MjApCiAgICAgICAg aXJldAoKICAgICAgICAub3JnIDB4MTIwMDAKCiAgICAgICAgLyogSURURCAqLwogICAgICAgIC5z aG9ydCAweDA0MDAKICAgICAgICAubG9uZyAweDBmMzAwMAoKICAgICAgICAub3JnIDB4MTIwMTAK CiAgICAgICAgLyogR0RURCAqLwogICAgICAgIC5zaG9ydCAweDAwMjAKICAgICAgICAubG9uZyAw eGYzNDAwCgogICAgICAgIC5vcmcgMHgxMzM4MAoKICAgICAgICAvKiBJRFQgZW50cnkgZm9yIElO VCA3MCAqLwogICAgICAgIC5sb25nIDB4MDAwODEwMDAsIDB4MDAwZjhlMDAKCiAgICAgICAgLm9y ZyAweDEzNDA4CgogICAgICAgIC8qIEdEVCBlbnRyeSBmb3IgMXN0IGRlc2NyaXB0b3IsIENTICov CiAgICAgICAgLnNob3J0IDB4ZmZmZiwgMHgwMDAwLCAweDliMDAsIDB4MDBjZgogICAgICAgIC8q IEdEVCBlbnRyeSBmb3IgMm5kIGRlc2NyaXB0b3IsIERTIGV0Yy4gKi8KICAgICAgICAuc2hvcnQg MHhmZmZmLCAweDAwMDAsIDB4OTMwMCwgMHgwMGNmCgogICAgICAgIC5vcmcgMHgxNDAwMAogICAg ICAgIG1vdmwgICAgJDB4MTAsICVlYXgKICAgICAgICBtb3Z3ICAgICVheCwgJWRzCiAgICAgICAg bW92dyAgICAlYXgsICVzcwogICAgICAgIG1vdmwgICAgJDB4MTAwMCwgJWVzcAoKICAgICAgICAv KiBNYXN0ZXIgUElDICovCiAgICAgICAgLyogSUNXMSAqLwogICAgICAgIE8oMHgyMCwgMHgxMSkK ICAgICAgICAvKiBJQ1cyICovCiAgICAgICAgTygweDIxLCAweDA4KQogICAgICAgIC8qIElDVzMg Ki8KICAgICAgICBPKDB4MjEsIDB4MDQpCiAgICAgICAgLyogSUNXNCAqLwogICAgICAgIE8oMHgy MSwgMHgwMSkKICAgICAgICAvKiBPQ1cxOiBvbmx5IHNsYXZlIElSUXMgKi8KICAgICAgICBPKDB4 MjEsIDB4ZmIpCgogICAgICAgIC8qIFNsYXZlIFBJQyAqLwogICAgICAgIC8qIElDVzEgKi8KICAg ICAgICBPKDB4YTAsIDB4MTEpCiAgICAgICAgLyogSUNXMiAqLwogICAgICAgIE8oMHhhMSwgMHg3 MCkKICAgICAgICAvKiBJQ1czICovCiAgICAgICAgTygweGExLCAweDAyKQogICAgICAgIC8qIElD VzQgKi8KICAgICAgICBPKDB4YTEsIDB4MDEpCiAgICAgICAgLyogT0NXMTogb25seSBSVEMgSVJR ICovCiAgICAgICAgTygweGExLCAweGZlKQoKICAgICAgICAvKiBzZXQgdXAgQVBJQyBMVlQgKi8K ICAgICAgICB4b3IgICAgICVlYXgsICVlYXgKICAgICAgICBtb3YgICAgICVlYXgsIDB4ZmVlMDAz NTAKCiAgICAgICAgLyogUlRDOiBmcmVxdWVuY3kgMWtIeiAqLwogICAgICAgIFJUQ19PKDB4YSwg MHgyNikKICAgICAgICAvKiBFbmFibGUgSVJRICovCiAgICAgICAgUlRDX08oMHhiLCAweDQwKQoK ICAgICAgICBzdGkKMTogICAgICBqbXAgICAgIDFiCiAgICAgICAgaGx0CgogICAgICAgIC5zZWN0 aW9uIC5yZXNldCwgImF4IgogICAgICAgIC5nbG9ibCAgZW50cnkKICAgICAgICAuY29kZTE2Z2Nj CmVudHJ5OgogICAgICAgIGNsaQogICAgICAgIGxqbXAgICAgJDB4ZjAwMCwgJDB4MDAwMAogICAg ICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5vcAog ICAgICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5vcAogICAgICAgIG5v cAoK --000e0cd1a0feb583020487cea007 Content-Type: application/octet-stream; name="coalescing.ld" Content-Disposition: attachment; filename="coalescing.ld" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9ttr1lv1 T1VUUFVUX0ZPUk1BVChlbGYzMi1pMzg2KQpPVVRQVVRfQVJDSChpMzg2KQoKRU5UUlkoZW50cnkp CgpTRUNUSU9OUwp7CiAgICAuID0gMHhlMDAwMDsKCiAgICAudGV4dCA6IHsgKigudGV4dCkgfQoK ICAgIC4gPSAweGYwMDAwOwoKICAgIC50ZXh0IDogeyAqKC50ZXh0KSB9CgogICAgLiA9IDB4ZmZm ZjA7CgogICAgLnJlc2V0IDogeyAqKC5yZXNldCkgfQp9Cg== --000e0cd1a0feb583020487cea007--