From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55051 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHhKP-0005vz-01 for qemu-devel@nongnu.org; Thu, 27 May 2010 13:57:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHhKN-0001ro-LF for qemu-devel@nongnu.org; Thu, 27 May 2010 13:57:08 -0400 Received: from mail-pz0-f186.google.com ([209.85.222.186]:62854) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHhKN-0001rZ-E7 for qemu-devel@nongnu.org; Thu, 27 May 2010 13:57:07 -0400 Received: by pzk16 with SMTP id 16so197155pzk.22 for ; Thu, 27 May 2010 10:57:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201005270026.34119.paul@codesourcery.com> References: <4BFD8010.3010001@web.de> <201005270026.34119.paul@codesourcery.com> From: Blue Swirl Date: Thu, 27 May 2010 17:56:46 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela On Wed, May 26, 2010 at 11:26 PM, Paul Brook wrote: >> At the other extreme, would it be possible to make the educated guests >> aware of the virtualization also in clock aspect: virtio-clock? > > The guest doesn't even need to be aware of virtualization. It just needs = to be > able to accommodate the lack of guaranteed realtime behavior. > > The fundamental problem here is that some guest operating systems assume = that > the hardware provides certain realtime guarantees with respect to executi= on of > interrupt handlers. =C2=A0In particular they assume that the CPU will alw= ays be > able to complete execution of the timer IRQ handler before the periodic t= imer > triggers again. =C2=A0In most virtualized environments you have absolutel= y no > guarantee of realtime response. > > With Linux guests this was solved a long time ago by the introduction of > tickless kernels. =C2=A0These separate the timekeeping from wakeup events= , so it > doesn't matter if several wakeup triggers end up getting merged (either a= t 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 la= tency > to the timer event, ensuring that the guest "sees" them all. =C2=A0Unfort= unately > guests vary on when it is safe for them to see the next timer event, and > trying to observe this behavior involves potentially harmful heuristics a= nd > collusion between unrelated devices (e.g. interrupt controller and timer)= . > > In some cases we don't even do that, and just reschedule the event some > arbitrarily small amount of time later. This assumes the guest to do usef= ul > work in that time. In a single threaded environment this is probably true= - > qemu got enough CPU to inject the first interrupt, so will probably manag= e to > execute some guest code before the end of its timeslice. In an environmen= t > where interrupt processing/delivery and execution of the guest code happe= n in > different threads this becomes increasingly likely to fail. 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 solution, like slowing down the guest system to the point where we can guarantee the interrupt rate vs. CPU execution speed?