Bug 1066145

Summary: Using <timer name=hpet present=no> causes arm + ppc64 to break, "Option no-hpet not supported for this target"
Product: [Community] Virtualization Tools Reporter: Richard W.M. Jones <rjones>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, berrange, danlipsitt, jtomko
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1066524 (view as bug list) Environment:
Last Closed: 2014-04-18 13:16:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 910269    

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