From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40390 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGe0m-0007yF-Gf for qemu-devel@nongnu.org; Mon, 24 May 2010 16:12:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGe0b-0008PA-KN for qemu-devel@nongnu.org; Mon, 24 May 2010 16:12:32 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:44950) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGe0Z-0008Of-Ff for qemu-devel@nongnu.org; Mon, 24 May 2010 16:12:21 -0400 Message-ID: <4BFADD5F.7010900@web.de> Date: Mon, 24 May 2010 22:11:11 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BFA9E8C.2070602@web.de> <4BFAA73F.9020101@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10F2BA82749DDFAA51255F6A" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Blue Swirl , qemu-devel@nongnu.org, Paul Brook This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10F2BA82749DDFAA51255F6A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Juan Quintela wrote: >>> We already have to disable hpet for 5.4 (1 year ago). It was done wi= th >>> a local hack because it was supposed that for next big release it wou= ld >>> have been fixed. >> But this remains a RHEL issue. Redhat decided to compile out features >> that are unsupported, others seem to handle this differently. >=20 > And then, everybody has a different hack to disable the features that > they don't need. Instead of doing a local hack, we do a patch that > allows anyone to disable HPET if it sees fit. So far I only know of precisely one user that wants to disable x86 platform devices at build-time. >=20 >>> Here we are, and device is still not fixed, what to do? Another loca= l >>> patch? Just get upstream to integrate a sane way to disable it and l= et >>> in enable by default? >> Let's start with listing your requirements to no longer disable HPET. >=20 > It is not stable at this point in time :-( Running with --no-hpet is > better than without it in all our testing. If we have to ask/modify > everything to use --no-hpet, we can also compile-out it. >=20 >> That would already help us to asses how long !CONFIG_HPET would actual= ly >> be of any use at all. I'm yet optimistic that we can resolve most if n= ot >> all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.1= 3 >> material anyway. >=20 > At this very point in time: > - it is not stable Well, that is helpful. > - lack irq-reinjection when missing ticks That is more helpful. I just reworked the RTC regarding this, I guess it will be straightforward to address it in the HPET too. >=20 > (I was not the one debugging/testing this so I don't have more details,= > but can ask for them). So, it is not stable enough yet. HPET is a fairly small device, a few hundred lines of code, only a few ugly platform dependencies, but that's it already. I bet it could have been fixed by now if someone just started by the time the tests reported "it is not stable enough". Jan --------------enig10F2BA82749DDFAA51255F6A 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 iEYEARECAAYFAkv63W0ACgkQitSsb3rl5xRzpwCg5UJRZt2boBrmkVur0ajD73yQ oAMAnRb8ROu4BuBGLTI3IksJ18gvla89 =RlUv -----END PGP SIGNATURE----- --------------enig10F2BA82749DDFAA51255F6A--