From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34866 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHPC7-0002e4-CW for qemu-devel@nongnu.org; Wed, 26 May 2010 18:35:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHPC6-0000Sk-8q for qemu-devel@nongnu.org; Wed, 26 May 2010 18:35:23 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:54337) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHPC5-0000SZ-Ui for qemu-devel@nongnu.org; Wed, 26 May 2010 18:35:22 -0400 Message-ID: <4BFDA222.6050507@web.de> Date: Thu, 27 May 2010 00:35:14 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback References: <4BFC3028.6030303@codemonkey.ws> <4BFC44D2.2090608@web.de> <4BFD8010.3010001@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE8FEF57591D387FF4A5A419" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org, Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCE8FEF57591D387FF4A5A419 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: >>>>>> I think the real solution to coalescing is put the logic inside on= e >>>>>> device, in this case APIC because it has the information about irq= >>>>>> delivery. APIC could monitor incoming RTC irqs for frequency >>>>>> information and whether they get delivered or not. If not, an inte= rnal >>>>>> timer is installed which injects the lost irqs. >>>> That won't fly as the IRQs will already arrive at the APIC with a >>>> sufficiently high jitter. At the bare minimum, you need to tell the >>>> interrupt controller about the fact that a particular IRQ should be >>>> delivered at a specific regular rate. For this, you also need a gene= ric >>>> interface - nothing really "won". >>> OK, let's simplify: just reinject at next possible chance. No need to= >>> monitor or tell anything. >> There are guests that won't like this (I know of one in-house, but >> others may even have more examples), specifically if you end up firing= >> multiple IRQs in a row due to a longer backlog. For that reason, the R= TC >> spreads the reinjection according to the current rate. >=20 > Then reinject with a constant delay, or next CPU exit. Such buggy > guests could also be assisted with special handling (like win2k > install hack), for example guest instructions could be counted > (approximately, for example using TB size or TSC) and only inject > after at least N instructions have passed. Let's assume that would be an alternative... >=20 >> And even if the rate did not matter, the APIC woult still have to now >> about the fact that an IRQ is really periodic and does not only appear= >> as such for a certain interval. This really does not sound like >> simplifying things or even make them cleaner. >=20 > It would, the voodoo would be contained only in APIC, RTC would be > just like any other device. =2E..we would still need that communication channel from the RTC to the APIC to tell the latter about entering/leaving periodic IRQ generation. And as we don't want the RTC requiring any clue about who's finally delivering the IRQ, we still need some generic interface. This cannot be contained in the APIC - even leaving the PIC as another IRQ delivery service aside for now, and maybe other virtualized architectures. > With the bidirectional irqs, this voodoo > would probably eventually spread to many other devices. Yes, the HPET was reported to need this feature as well. > The logical > conclusion of that would be a system where all devices would be > careful not to disturb the guest at wrong moment because that would > trigger a bug. >=20 > At the other extreme, would it be possible to make the educated guests > aware of the virtualization also in clock aspect: virtio-clock? Paravirtual clocks are around since ages (e.g. kvm-clock), just unfortunately not long enough to find them supported by legacy guests. Jan --------------enigCE8FEF57591D387FF4A5A419 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkv9oiYACgkQitSsb3rl5xRtLACgnUJEXAv5rlgQJCjbDHvH8htg TZEAoILmb6MmI84dMRN4Toc9E7LqNg/A =ilAh -----END PGP SIGNATURE----- --------------enigCE8FEF57591D387FF4A5A419--