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

[Serge E. Hallyn]

Quoting Jan Kiszka (address@hidden):
> 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.

Yay :)

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

Thanks, Jan.  I'll do the workaround for now (it's passing all my tests...)
and, if need be, consider a single big 'git diff v1.0..ce967e2f33'.

-serge