QEMU timerfd_create support on PowerPC
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Invalid
|
Undecided
|
Unassigned | ||
Trusty |
Invalid
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Christian Ehrhardt | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* Compile the attached source code using your host C compiler.
=> https:/
$ apt install build-essential
$ gcc -Wall timertest.c -o timertest
* Run the resulting binary.
It should run for 3 seconds and print timer information. (sanity
test)
$ ./timertest
* Compile the attached source code using a PowerPC cross compiler with
static linking enabled (to make the remaining steps simpler).
$ apt install gcc-powerpc64-
$ powerpc64-
* Run the resulting binary using the unpatched qemu-user or qemu-user-
static executable for your selected PowerPC architecture. It should
exit immediately complaining about an unsupported syscall.
$ apt install qemu-user
$ qemu-ppc64 ./timertest
qemu: Unsupported syscall: 306
* Run the same binary using the patched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
It should behave as the host version did.
Note: If you chose a big-endian PowerPC architecture, the "timer expirations" output may be "72057594037927936" instead of "1" because the bytes read were in host byte order instead of target byte order.
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 139 lines (+117/-0)3 files modifieddebian/changelog (+7/-0)
debian/patches/series (+1/-0)
debian/patches/ubuntu/lp1807743-linux-user-timerfd.patch (+109/-0)
description: | updated |
description: | updated |
Changed in qemu (Ubuntu Xenial): | |
status: | Confirmed → In Progress |
assignee: | nobody → Christian Ehrhardt (paelzer) |
The attachment "Add an extra define to enable timerfd_create support." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]