** Description changed: [Impact] - * A bad named define made timerfd_create be in the code but not + * 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 + * two smaller fixes to be backported from upstream that change the define + names; This will enable the timerfd_create in qemu-user [Test Case] - * TODO @WES - + * Compile the attached source code using your host C compiler. + => https://launchpadlibrarian.net/401131808/timerfd_support_test.c + * Run the resulting binary. + > It should run for 3 seconds and print timer information. (sanity test) + * Compile the attached source code using a PowerPC cross compiler with + static linking enabled (to make the remaining steps simpler). + * 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. + * 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. + > 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. + * 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 + * 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-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1807743 Title: QEMU timerfd_create support on PowerPC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1807743/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
