From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41507 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGe52-00030s-0Z for qemu-devel@nongnu.org; Mon, 24 May 2010 16:17:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGe4s-0000b1-DI for qemu-devel@nongnu.org; Mon, 24 May 2010 16:16:55 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:55664) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGe4r-0000ah-KQ for qemu-devel@nongnu.org; Mon, 24 May 2010 16:16:46 -0400 Received: by pvg16 with SMTP id 16so145247pvg.4 for ; Mon, 24 May 2010 13:16:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BFABF77.8050108@codemonkey.ws> References: <201005241732.46988.paul@codesourcery.com> <4BFAAE22.5040900@codemonkey.ws> <201005241811.10219.paul@codesourcery.com> <4BFABF77.8050108@codemonkey.ws> From: Blue Swirl Date: Mon, 24 May 2010 20:16:24 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: qemu-devel@nongnu.org, Jan Kiszka , Paul Brook , Juan Quintela On Mon, May 24, 2010 at 6:03 PM, Anthony Liguori wr= ote: > On 05/24/2010 12:54 PM, Juan Quintela wrote: >> >> Paul Brook =C2=A0wrote: >> >>>> >>>> On 05/24/2010 11:32 AM, Paul Brook wrote: >>>> >>>>>> >>>>>> 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. =C2=A0Notice that in general, we (RHE= L/KVM) >>>>>> are interested in a small subset of qemu devices. >>>>>> >>>>> >>>>> IMO this patch is a backwards step. =C2=A0The device models should be >>>>> cleaned >>>>> up so that you don't need to make a compile time decision. >>>>> >>>> >>>> I disagree. =C2=A0I think the device model should be cleaned up so tha= t no >>>> CONFIG_HPET is required in code but I think it's still useful to be ab= le >>>> to exclude device models from the build. =C2=A0That should just be a m= atter >>>> of not building the object though (that's the point of device_init()). >>>> >>> >>> 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). =C2=A0However a necessa= ry >>> prerequisite is that you fix the device model and machine initialisatio= n >>> so >>> that it's possible to omit hpet.o without rebuilding anything else. >>> >> >> 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 >> =C2=A0 =C2=A0 if (!hpet_in_legacy_mode()) >> #endif >> > > In real hardware, and HPET would normally emulate an RTC. =C2=A0The inter= action > problem here is that we aren't modelling that correctly in qemu as we're > treating the rtc as a separate device. > > 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. =C2=A0= When 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. =C2= =A0When > the HPET isn't in use, the rtc would be created with an isa allocated > qemu_irq. Fully agree, HPET logic should be moved into HPET. I think my yesterday's patches only went half way.