From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58961 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIbby-0000AT-PI for qemu-devel@nongnu.org; Sun, 30 May 2010 02:03:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIbbv-0007lJ-Ql for qemu-devel@nongnu.org; Sun, 30 May 2010 02:03:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41727) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIbbv-0007l7-KU for qemu-devel@nongnu.org; Sun, 30 May 2010 02:02:59 -0400 Date: Sun, 30 May 2010 09:02:55 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela 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 our= life > >> >> > or improve the efficiency of the de-coalescing workaround. It's r= ather > >> >> > problematic like Gleb pointed out: The de-coalescing logic needs = to be > >> >> > informed about periodicity changes that can only be delivered alo= ng > >> >> > 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 WindowsXP > >> > inside QEMU, connect with gdb to QEMU process and check what frequen= cy > >> > RTC configured with (hint: it will be 64Hz), now run video inside the > >> > 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 wa= nt > > to change reality to be more close to what you want it to be by adding > > words to my description. >=20 > 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. No 'stopped' was under discussion nowhere. FWIW 'stopped' is just a case of frequency change. >=20 > XP frequency change isn't the same case as timer being stopped. >=20 And what is the big difference exactly? > > Please just go write code, experiment, debug > > and _then_ come here with design. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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. >=20 > >> 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. > > > > -- > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AGleb. > > -- Gleb.