From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRUwD-0004nC-7V for qemu-devel@nongnu.org; Tue, 31 May 2011 15:49:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRUwB-0007Zb-U3 for qemu-devel@nongnu.org; Tue, 31 May 2011 15:49:12 -0400 Message-ID: <4DE5462E.80908@codemonkey.ws> Date: Tue, 31 May 2011 14:49:02 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1306705831-59385-1-git-send-email-andreas.faerber@web.de> <4DE4F16D.6030009@codemonkey.ws> <4DE4F5E2.5020906@siemens.com> <4DE4FAA1.7080109@codemonkey.ws> <4DE5011C.80000@siemens.com> <98DD53CD-B6E2-4739-A952-0F21019485A4@suse.de> <4DE50DC5.2060806@codemonkey.ws> <35D43777-76C2-415D-83FF-143C4D2EF774@suse.de> In-Reply-To: <35D43777-76C2-415D-83FF-143C4D2EF774@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] Use SIGIO with caution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-trivial@nongnu.org" , Jan Kiszka , Marcelo Tosatti , "qemu-devel@nongnu.org" , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Avi Kivity On 05/31/2011 11:16 AM, Alexander Graf wrote: > > On 31.05.2011, at 17:48, Anthony Liguori wrote: > >> On 05/31/2011 10:44 AM, Alexander Graf wrote: >>> >>> On 31.05.2011, at 16:54, Jan Kiszka wrote: >>> >>>> On 2011-05-31 16:26, Anthony Liguori wrote: >>>>> On 05/31/2011 09:06 AM, Jan Kiszka wrote: >>>>>> On 2011-05-31 15:47, Anthony Liguori wrote: >>>>>>> On 05/29/2011 04:50 PM, Andreas Färber wrote: >>>>>>>> BeOS and Haiku don't define SIGIO. When undefined, it won't arrive >>>>>>>> and doesn't need to be blocked. >>>>>>>> >>>>>>>> Signed-off-by: Andreas Färber >>>>>>> >>>>>>> Anything to do with signal masks is never a trivial patch BTW... >>>>>>> >>>>>>> But I actually think explicit handling of SIGIO is unneeded. I think >>>>>>> this is a hold over from the pre-I/O thread days where we selectively >>>>>>> set SIGIO on certain file descriptors to make sure that when an IO fd >>>>>>> became readable, we received a signal to break out of the KVM emulation >>>>>>> loop. >>>>>>> >>>>>>> Can the folks on CC confirm/deny? >>>>>>> >>>>>>> I can't see any use of SIGIO in the current source tree. >>>>>> >>>>>> At least qemu-timer.c uses SIGIO in HPET mode. That only applies to >>>>>> Linux hosts, though. >>>>> >>>>> Is there any reason we still carry multiple timer implementations these >>>>> days? >>>>> >>>>> HPET shouldn't be any better than dynticks. >>>> >>>> On any recent kernel, for sure. BTW, the same applies to the RTC timer. >>> >>> So the obvious change would be to introduce CONFIG_HPET, ifdef the SIGIO handling on that and also ifdef the host hpet handling code on it? That way it's documented well and can preferably even be turned off with --disable-host-hpet during configure time, which we can then slowly turn to the default. >> >> Or just remove hpet and rtc. >> >> Does anyone really object to that? > > Do RHEL5 and SLES10 support dynticks? If yes, no objections. They're the oldest really supported distros we should possibly remotely even care about. Yes, they do. But it's not as accurate as RTC/HPET because there is no CONFIG_HRTIMERS. But the problem with RTC/HPET is that there is only one /dev/rtc and one /dev/hpet so only one guest can use it at any given time. It's really not a generally useful solution. At one point in time, it was the only way to get a high res clock. Now, it Just Works provided you don't have an ancient kernel. Regards, Anthony Liguori