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

[Juan Quintela]

Jan Kiszka <address@hidden> wrote:

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

Yeap, but then I end having lots of things patches in RHEL that are not
upstream, and each new version/rebase I have to redo all of them.

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

Sorry, no donut :-)

We try to help/fix everything that we can (we == Red Hat in this case),
but we are not going to ship will all drivers any time soon, so it needs
to be a way to disable them IMHO.  If we need to wait for _all_ devices
to be stable and bug free we could ship for next millenium (take or put
a couple century's).

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

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.

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

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.

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

At this very point in time:
- it is not stable
- lack irq-reinjection when missing ticks

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

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

Humm, we run normally without hpet enabled and all normal guests work.
And yes, I would also preffer it to work.

Later, Juan.