From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58593 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHi4B-00062g-Bi for qemu-devel@nongnu.org; Thu, 27 May 2010 14:44:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHhrJ-0000EP-6d for qemu-devel@nongnu.org; Thu, 27 May 2010 14:31:10 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:37247) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHhrI-0000EE-Rc for qemu-devel@nongnu.org; Thu, 27 May 2010 14:31:09 -0400 Message-ID: <4BFEBA66.6030804@web.de> Date: Thu, 27 May 2010 20:31:02 +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: <4BFD8010.3010001@web.de> <201005270026.34119.paul@codesourcery.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5A67C8B129583C5432DCD5C" 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: Juan Quintela , Paul Brook , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5A67C8B129583C5432DCD5C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: > On Wed, May 26, 2010 at 11:26 PM, Paul Brook wr= ote: >>> At the other extreme, would it be possible to make the educated guest= s >>> aware of the virtualization also in clock aspect: virtio-clock? >> The guest doesn't even need to be aware of virtualization. It just nee= ds to be >> able to accommodate the lack of guaranteed realtime behavior. >> >> The fundamental problem here is that some guest operating systems assu= me that >> the hardware provides certain realtime guarantees with respect to exec= ution of >> interrupt handlers. In particular they assume that the CPU will alway= s be >> able to complete execution of the timer IRQ handler before the periodi= c timer >> triggers again. In most virtualized environments you have absolutely = no >> guarantee of realtime response. >> >> With Linux guests this was solved a long time ago by the introduction = of >> tickless kernels. These separate the timekeeping from wakeup events, = so it >> doesn't matter if several wakeup triggers end up getting merged (eithe= r at the >> hardware level or via top/bottom half guest IRQ handlers). >> >> >> It's worth mentioning that this problem also occurs on real hardware, >> typically due to lame hardware/drivers which end up masking interrupts= or >> otherwise stall the CPU for for long periods of time. >> >> >> The PIT hack attempts to workaround broken guests by adding artificial= latency >> to the timer event, ensuring that the guest "sees" them all. Unfortun= ately >> guests vary on when it is safe for them to see the next timer event, a= nd >> trying to observe this behavior involves potentially harmful heuristic= s and >> collusion between unrelated devices (e.g. interrupt controller and tim= er). >> >> In some cases we don't even do that, and just reschedule the event som= e >> arbitrarily small amount of time later. This assumes the guest to do u= seful >> work in that time. In a single threaded environment this is probably t= rue - >> qemu got enough CPU to inject the first interrupt, so will probably ma= nage to >> execute some guest code before the end of its timeslice. In an environ= ment >> where interrupt processing/delivery and execution of the guest code ha= ppen in >> different threads this becomes increasingly likely to fail. >=20 > So any voodoo around timer events is doomed to fail in some cases. > What's the amount of hacks what we want then? Is there any generic The aim of this patch is to reduce the amount of existing and upcoming hacks. It may still require some refinements, but I think we haven't found any smarter approach yet that fits existing use cases. > solution, like slowing down the guest system to the point where we can > guarantee the interrupt rate vs. CPU execution speed? That's generally a non-option in virtualized production environments. Specifically if the guest system lost interrupts due to host overcommitment, you do not want it slow down even further. Jan --------------enigE5A67C8B129583C5432DCD5C 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 iEYEARECAAYFAkv+umoACgkQitSsb3rl5xSKhACgqji9ZbfQOa4GLjV9OzuybN8o dBEAoIqt/6TkigmU87cBR7lVXI/7oBTK =MGuf -----END PGP SIGNATURE----- --------------enigE5A67C8B129583C5432DCD5C--