Bug 1066145 - Using <timer name=hpet present=no> causes arm + ppc64 to break, "Option no-hpet not supported for this target"
Summary: Using <timer name=hpet present=no> causes arm + ppc64 to break, "Option no-hp...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ján Tomko
QA Contact:
URL:
Whiteboard:
: 1066524 (view as bug list)
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2014-02-17 20:17 UTC by Richard W.M. Jones
Modified: 2014-04-18 13:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1066524 (view as bug list)
Environment:
Last Closed: 2014-04-18 13:16:44 UTC
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2014-02-17 20:17:03 UTC
Description of problem:

qemu-system-arm has an annoying bug since forever where the -help
output mentioned -no-hpet, but if you actually use this flag, qemu
helpfully prints:

  Option no-hpet not supported for this target

If you use the libvirt XML on an ARM guest:

  <timer name=hpet present=no>

meaning "don't include an HPET device", then libvirt adds -no-hpet
to the command line, and qemu-system-arm won't start up.  Of course
ARM has never had a High Precision Timer, and in any case we're
asking not to include one.

I have worked around this in libguestfs by not including this
XML fragment on ARM, but this still looks like it is a bug in
libvirt (and qemu of course).

Version-Release number of selected component (if applicable):

libvirt from git today

How reproducible:

100%

Steps to Reproduce:
1. Compile libvirt from git on ARM.
2. Run: ~/d/libvirt/run libguestfs-test-tool

Actual results:

Original error from libvirt: internal error: process exited while connecting to monitor: Option no-hpet not supported for this target
 [code=1 domain=10]
libguestfs-test-tool: failed to launch appliance

Expected results:

Should probably ignore this.

Additional info:

Comment 1 Daniel Berrangé 2014-02-18 15:07:46 UTC
*** Bug 1066524 has been marked as a duplicate of this bug. ***

Comment 2 Daniel Berrangé 2014-02-18 15:08:49 UTC
Affects multiple architectures, both arm and ppc, probably all non-x86 archs in fact.

Comment 3 Daniel Lipsitt 2014-02-26 00:55:45 UTC
(In reply to Richard W.M. Jones from comment #0)

> I have worked around this in libguestfs by not including this
> XML fragment on ARM, but this still looks like it is a bug in
> libvirt (and qemu of course).

I still see this problem after compiling from libguestfs-1.25.37.tar.gz on Ubuntu Trusty. Should the workaround be present in that release?

Comment 4 Richard W.M. Jones 2014-03-26 14:34:45 UTC
(In reply to Daniel Lipsitt from comment #3)
> (In reply to Richard W.M. Jones from comment #0)
> 
> > I have worked around this in libguestfs by not including this
> > XML fragment on ARM, but this still looks like it is a bug in
> > libvirt (and qemu of course).
> 
> I still see this problem after compiling from libguestfs-1.25.37.tar.gz on
> Ubuntu Trusty. Should the workaround be present in that release?

The workaround is present in current libguestfs, so a newer version
should be OK.

Comment 5 Ján Tomko 2014-04-17 14:57:47 UTC
Upstream patch posted:
https://www.redhat.com/archives/libvir-list/2014-April/msg00730.html

Comment 6 Ján Tomko 2014-04-18 13:16:44 UTC
Fixed upstream:
commit c3725db8d0c1035dc550959c93f8b9aeb78ec1bf
Author:     Ján Tomko <jtomko>
CommitDate: 2014-04-18 15:01:27 +0200

    Only set QEMU_CAPS_NO_HPET on x86
    
    QEMU only supports it on x86, but we've been assuming it for
    all QEMUs when doing QMP capability detection.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1066145

git describe: v1.2.3-138-gc3725db
Backported to v1.1.3-maint: v1.1.3.4-19-ga91c1f1


Note You need to log in before you can comment on or make changes to this bug.