For a few months now QEMU has had options to enable compiler-based
control-flow integrity if built with clang.

While this feature has a low maintenance, It's probably still better to
add tests to the CI environment to check that an update doesn't break it.

The patchset allow gitlab testing of:
* --enable-cfi: forward-edge cfi (function pointers)
* --enable-safe-stack: backward-edge cfi (return pointers)
As an added benefit, this also inherently tests LTO. 

The first patch allows a custom selection for linker parallelism.
Currently, make parallelism at build time is based on the number
of cpus available.
This doesn't work well with LTO at linking, because the linker has to
load in memory all the intermediate object files for optimization.
If the gitlab runner happens to run two linking processes at the same
time, the job will fail with an out-of-memory error,
The patch leverages the ability to maintain high parallelism at
compile time, but limit the number of linkers executed in parallel.

The second patch introduces the ci/cd jobs in the gitlab pipeline.
My original intention was to create a single chain of
build -> check -> acceptance, with all the targets compiled by default.
Unfortunately, the resulting artifact is too big and won't be uploaded.
So I split the test in two chains, that should cover all non-deprecated
targets as of today.
Build jobs are on the longer side (about 2h and 20m), but I thought it
would be better to just have 6 large jobs than tens of smaller ones.
For build, we have to select --enable-slirp=git, because CFI needs a
statically linked version of slirp, with CFI information. More info on
this can be found in a comment in .gitlab-ci.yml.

Test runs of the full pipeline are here (cfi-ci-v2 branch):
https://gitlab.com/dbuono/qemu/-/pipelines/261311362

v2:
- More details in the code about the issue of using system-wide slirp
- Use meson to only limit linker parallelism instead of forcing no
  parallelism on the whole compilation process.

Daniele Buono (2):
  gitlab-ci.yml: Allow custom # of parallel linkers
  gitlab-ci.yml: Add jobs to test CFI flags

 .gitlab-ci.yml | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)

-- 
2.30.0

On Fri, Feb 26, 2021 at 10:21:06AM -0500, Daniele Buono wrote:
> Build jobs are on the longer side (about 2h and 20m), but I thought it
> would be better to just have 6 large jobs than tens of smaller ones.

IMHO that is a not viable.

Our longest job today is approx 60 minutes, and that is already
painfully long when developers are repeatedly testing their
patch series to find and fix bugs before posting them for review.
I can perhaps get through 5-6 test cycles in a day. If we have a
2 hour 20 min job, then I'll get 2-3 test cycles a day.

I don't want to see any new jobs added which increase the longest
job execution time. We want to reduce our max job time if anything.


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 :|

Hi Daniel,

On 3/1/2021 5:06 AM, Daniel P. Berrangé wrote:
> On Fri, Feb 26, 2021 at 10:21:06AM -0500, Daniele Buono wrote:
>> Build jobs are on the longer side (about 2h and 20m), but I thought it
>> would be better to just have 6 large jobs than tens of smaller ones.
> 
> IMHO that is a not viable.
> 
> Our longest job today is approx 60 minutes, and that is already
> painfully long when developers are repeatedly testing their
> patch series to find and fix bugs before posting them for review.
> I can perhaps get through 5-6 test cycles in a day. If we have a
> 2 hour 20 min job, then I'll get 2-3 test cycles a day.
> 
> I don't want to see any new jobs added which increase the longest
> job execution time. We want to reduce our max job time if anything.
> 
> 

I totally understand the argument.

We could build two targets per job. That would create build jobs that
take 40 to 60-ish minutes. If that's the case, however, I would not
recommend testing all the possible targets but limit them to what
is considered a set of most common targets. I have an example of the
resulting pipeline here:

https://gitlab.com/dbuono/qemu/-/pipelines/258983262

I selected intel, power, arm and s390 as "common" targets. Would
something like this be a viable alternative? Perhaps after
due thinking of what targets should be tested?

> Regards,
> Daniel
>