Re: [Qemu-devel] hpet problems with unaccelerated qemu

[Jan Kiszka]

On 2012-04-10 16:06, Serge E. Hallyn wrote:
> Quoting Jan Kiszka (address@hidden):
>> On 2012-04-09 17:36, Serge E. Hallyn wrote:
>>> Hi,
>>>
>>> at https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240 there is
>>> reported a problem in 1.0.0 with running unaccelerated qemu with hpet.
>>> This is fixed upstream as of commit 
>>> ce967e2f33861b0e17753f97fa4527b5943c94b6.
>>> However, that one seems very depending on many of the preceding ~thousand
>>> commits.
>>>
>>> On irc mjt and iggy suggested that implicitly setting -no-hpet when tcg
>>> is chosen should be fine.  Right now that seems the best course, but
>>> does anyone know how one would cleanly cherrypick that commit into 1.0?
>>> Does anyone see a reason why -no-hpet with -no-kvm would cause anyone
>>> trouble?
>>
>> Have you already tried to backport the complete set or dependent
>> patches, ie. 5904ae4eba..ce967e2f33?
> 
> Yes, I did, starting with that range.  But I kept finding more patches that
> seemed to need to preceed it ( cf88a3bcc442d70e10d3969e1edfc8430d74172f,
> (40c9dcbfd026f0d0dd73dcf5a189ead7d1ba2d0f, 
> 48a18b3c698295e4d891f34e919615e84e20f027,
> ad6d45fa0837acf3e8cab323ee5b08e05a9410a5).  Perhaps the original set should
> have been easy to port to 1.0, and I just didn't know what I was doing,
> but there seemed to constantly be more previous changes needed.

Well, indeed, that's non-trivial and bears some risk of subtle
regressions. It should be easier for upstream, but you are trapped in
the remainders of the qemu-kvm fork. Will be gone in 1.1.

I have no definitive opinion on disabling hpet in TCG mode. Maybe there
are also use cases that weren't affected by the hand-over bug and would
suffer from the unavailability of the hpet (as there is no "-hpet").
But, otherwise, this looks like the most pragmatic approach.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux