From: Anthony Liguori <anthony@codemonkey.ws>
To: Juan Quintela <quintela@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, Jan Kiszka <jan.kiszka@web.de>,
Paul Brook <paul@codesourcery.com>,
qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Date: Mon, 24 May 2010 13:03:35 -0500 [thread overview]
Message-ID: <4BFABF77.8050108@codemonkey.ws> (raw)
In-Reply-To: <m3ocg5uqvz.fsf@trasno.mitica>
On 05/24/2010 12:54 PM, Juan Quintela wrote:
> Paul Brook<paul@codesourcery.com> wrote:
>
>>> 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. Notice that in general, we (RHEL/KVM)
>>>>> are interested in a small subset of qemu devices.
>>>>>
>>>> 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.
>>>>
>>> I disagree. I think the device model should be cleaned up so that no
>>> 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 matter
>>> 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). 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.
>>
> 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
>
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.
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. 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. When the HPET isn't in use, the rtc would be created with an
isa allocated qemu_irq.
Regards,
Anthony Liguori
> how the other one is used on pc.c
>
> if (!no_hpet) {
> hpet_init(isa_irq);
> }
>
> I agree that I could probably came with some trick with qdev_create() to
> substitute the hpet_init() (my understanding is that jan already have it
> or something like that).
>
> But for the other call, what do you propose?
>
> My best try was to hide the availability of hpet inside hpet_emul.h
> with:
>
> #ifdef CONFIG_HPET
> uint32_t hpet_in_legacy_mode(void);
> else
> uint32_t hpet_in_legacy_mode(void) { return 0;}
> #endif
>
> I can't see any obvious way to change the hpet_in_legacy_mode() that is
> cleaner than this.
>
> Thanks, Juan.
>
>
>> Paul
>>
next prev parent reply other threads:[~2010-05-24 18:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 15:18 [Qemu-devel] [PATCH 0/6] Make hpet a compile time option Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 1/6] Create again config-device.h and config.devices.h Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 2/6] Move no_hpet declaration to hpet_emul.h Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 3/6] Move no_hpet test to inside hpet_init() Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 4/6] Make hpet_in_legacy_mode() return 0 for !TARGET_I386 Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 5/6] make hpet_in_legacy_mode() return a bool Juan Quintela
2010-05-24 15:18 ` [Qemu-devel] [PATCH 6/6] Create CONFIG_HPET Juan Quintela
2010-05-24 15:20 ` [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option Juan Quintela
2010-05-24 15:43 ` Jan Kiszka
2010-05-24 15:57 ` Juan Quintela
2010-05-24 16:20 ` Jan Kiszka
2010-05-24 18:08 ` Juan Quintela
2010-05-24 20:11 ` Jan Kiszka
2010-05-24 16:32 ` Paul Brook
2010-05-24 16:49 ` Anthony Liguori
2010-05-24 17:11 ` Paul Brook
2010-05-24 17:37 ` Anthony Liguori
2010-05-24 17:54 ` Juan Quintela
2010-05-24 18:03 ` Anthony Liguori [this message]
2010-05-24 18:15 ` Jan Kiszka
2010-05-24 20:16 ` Blue Swirl
2010-05-24 18:10 ` Jan Kiszka
2010-05-25 8:38 ` Paolo Bonzini
2010-05-25 9:05 ` Jan Kiszka
2010-05-25 9:56 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BFABF77.8050108@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=jan.kiszka@web.de \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).