On Thursday, July 30, 2020 1:28:49 PM CEST Daniel P. Berrangé wrote: > On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote: > > Hi, all, > > > > I'd like to get some understanding on the current state of emulation > > of other architectures. > > > > In the current CI infra we have infinite(*) access to x86_64 compute > > resources, but we haven't yet got our hands on any non x86_64 > > hardware. > > > > As COPR has recently got support for s390 builds, the question is: if > > emulation is good enough for building packages, can we use it for > > testing? What are the limitations there? Is it worth it? > > I'm not familiar with what COPR is doing for s39x0 ? Is it using the > simple QEMU linux-user syscall emulation, or is it running a proper > QEMU s390x VM. > > I'm guessing probably the former. The linux-user syscall emulation is > truely amazing, but it is certainly not feature complete or fully > robust. Yes, it is just running `mock -r fedora-<version>-s390x` on x86_64 VM. That uses dnf's --forcearch feature (qemu-user-static emulation). Pavel > Applications that are multi-threaded are especially likely to expose > bugs and/or design limitations that are often hard to fix. If the > app uses common/simple syscalls it'll probably be OK in general; if it > uses more obscure stuff it'll come up against bugs / missing features. > It doesn't emulate ptrace, or robust futexes, and doesn't separate > rlimits for the emulation layer from the application lkayer. QEMU > isn't especially prompt about adding support for newly exposed kernel > syscalls. The quality can also vary depending on what target > architecture is involved. > > Overall it is pretty decent at being able to run common toolchains for > performing builds. Once you get into running a broader class of > applications, things can get more hairy. > > Basically if it works for an given app, that is great, but don't be > too surprised if apps experiance odd behaviour or hits bugs. > > I certainly won't expect to be able to blindly throw any Fedora package > at it and expect to run arbitrary integration tests with the same level > of quality you'd experiance with bare metal for that particular arch. > > The QEMU VM emulation will get a more reliable environment for integration > testing, since that's just emulating the CPU + hardware, with Linux still > providing the syscall ABI. The cost is that VM is higher overhead than > linux-user. > > As something that individual packagers can opt-in to QEMU linux-user > emulation might be viable. Packagers would just have to try it and see > if it works well enough for their particular package's testing use cases. > I'm not sure if that makes it compelling enough to invest time into > though from a Fedora infra POV. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
