Jan Kiszka <jan.kis...@web.de> 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.
