Re: Can we use emulation of other architectures to run integration tests?
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org