[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]

Juan Quintela wrote:
> Jan Kiszka <jan.kiszka@web.de> wrote:
>> Juan Quintela wrote:
> 
>> Unless this is deadly urgent, please hold it back until we sorted out
>> some more fundamental issues with the HPET, specifically ported it to qdev.
> 
> This series are independent of the qdev change (it almost don't change
> hpet code at all).  It is basically independent of almost everything else.

It causes mechanical breakage to the qdev change (and the one I'm
hacking on ATM).

> 
>> But I'm also not convinced about the general approach. Except for RHEL
>> packagers, no one seems to gain any benefit from having CONFIG_HPET.
> 
> This happens to us all the time for lots of devices.  And the big
> problem is that there is no sane way to disable them :(
> 
> If we can agree in a mechanism to disable them (like this one) or
> something similar, we could remove it.
> 
> Our biggest problem with shipping a device is that we are going to
> support it for 7 years, you can guess why we want to be conservative.

In this particular case, it is a one line patch: "no_hpet = 1;", hardwired.

> 
>>  The
>> HPET model is still incomplete in has some remaining quicks (hold on for
>> improvements), but that doesn't qualify it for !CONFIG_HPET,
>> specifically as it is deeply hooked into every modern PC. If I was
>> asked, I guess I would nack this switch.
> 
> Then, what should we do?

Help fixing it (e.g. testers will soon be welcome).

> We already have to disable hpet for 5.4 (1 year ago).  It was done with
> a local hack because it was supposed that for next big release it would
> have been fixed.

But this remains a RHEL issue. Redhat decided to compile out features
that are unsupported, others seem to handle this differently.

> 
> Here we are, and device is still not fixed, what to do?  Another local
> patch?  Just get upstream to integrate a sane way to disable it and let
> in enable by default?

Let's start with listing your requirements to no longer disable HPET.
That would already help us to asses how long !CONFIG_HPET would actually
be of any use at all. I'm yet optimistic that we can resolve most if not
all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13
material anyway.

> 
> 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.

At least HPET is IMHO a bad example as it is, just like e.g. the IOAPIC,
an essential part of today's x86 systems.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]