From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36185 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGcBs-0000BV-Jr for qemu-devel@nongnu.org; Mon, 24 May 2010 14:15:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGcBj-0007Pe-Mq for qemu-devel@nongnu.org; Mon, 24 May 2010 14:15:52 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:38009) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGcBi-0007PK-PQ for qemu-devel@nongnu.org; Mon, 24 May 2010 14:15:43 -0400 Message-ID: <4BFAC24C.6040708@web.de> Date: Mon, 24 May 2010 20:15:40 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <201005241732.46988.paul@codesourcery.com> <4BFAAE22.5040900@codemonkey.ws> <201005241811.10219.paul@codesourcery.com> <4BFABF77.8050108@codemonkey.ws> In-Reply-To: <4BFABF77.8050108@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5346FB78F45E503D6E07282" 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: Anthony Liguori Cc: Blue Swirl , qemu-devel@nongnu.org, Paul Brook , Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5346FB78F45E503D6E07282 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > On 05/24/2010 12:54 PM, Juan Quintela wrote: >> Paul Brook wrote: >> =20 >>>> On 05/24/2010 11:32 AM, Paul Brook wrote: >>>> =20 >>>>>> Notice that this patch was sent against hpet as one example, if we= >>>>>> agree >>>>>> that this "way" of disabling devices is ok, we could disable more >>>>>> devices/have more flexibility. Notice that in general, we (RHEL/K= VM) >>>>>> are interested in a small subset of qemu devices. >>>>>> =20 >>>>> IMO this patch is a backwards step. The device models should be >>>>> cleaned >>>>> up so that you don't need to make a compile time decision. >>>>> =20 >>>> I disagree. I think the device model should be cleaned up so that n= o >>>> CONFIG_HPET is required in code but I think it's still useful to be >>>> able >>>> to exclude device models from the build. That should just be a matt= er >>>> of not building the object though (that's the point of device_init()= ). >>>> =20 >>> I think we're saying the same thing. >>> >>> We already have a mechanism for avoiding things at build time - >>> specifically >>> config-devices.mak. We don't have a nice UI for it, but it's there. >>> At worst your distro specific patch is a 1-line change to default- >>> configs/i386-softmmu.mak. >>> >>> I have no objection to moving hpet.c into Makefile.objs, conditional = on >>> CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary >>> prerequisite is that you fix the device model and machine >>> initialisation so >>> that it's possible to omit hpet.o without rebuilding anything else. >>> =20 >> We have two exported functions: >> >> void hpet_init(qemu_irq *irq); >> uint32_t hpet_in_legacy_mode(void); >> >> This is how one is used in mc14818rtc: >> >> #if defined TARGET_I386 >> if (!hpet_in_legacy_mode()) >> #endif >> =20 >=20 > In real hardware, and HPET would normally emulate an RTC. The > interaction problem here is that we aren't modelling that correctly in > qemu as we're treating the rtc as a separate device. Not exactly: The HPET can only take over the periodic timer service of the RTC. But the RTC can still deliver that one as well as all its other IRQs via the SCI (part of ACPI). We don't implement the latter yet, thoug= h. >=20 > What could probably work at a hand wave level, is to make the rtc init > function take a qemu_irq instead of directly grabbing the isa irq. Whe= n > an HPET is in use, the rtc no longer is directly initiated but instead > is indirectly initiated by the HPET passing a special qemu_irq to the > device that masks the actual interrupt line when legacy mode isn't > enabled. When the HPET isn't in use, the rtc would be created with an > isa allocated qemu_irq. I'm on this. But, as already indicated, the current "beautifulness" of the RTC IRQ coalescing workaround kept me more busy than I expected. Jan --------------enigF5346FB78F45E503D6E07282 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 iEYEARECAAYFAkv6wkwACgkQitSsb3rl5xSLOQCg3LLpk2ADKvlUuttHKowM6620 CZAAoNLTURha8FQYYxdGMVaeJvCZudpo =xEF+ -----END PGP SIGNATURE----- --------------enigF5346FB78F45E503D6E07282--