1. 07 Dec, 2021 2 commits
  2. 03 Dec, 2021 3 commits
    • Antonio Terceiro's avatar
      Merge branch 'docker-cgroupsv2' into 'master' · fc689663
      Antonio Terceiro authored
      lava_dispatcher_host: add support for docker device sharing under cgroups v2
      Closes #467
      See merge request lava/lava!1614
    • Antonio Terceiro's avatar
      lava-dispatcher-host: move device sharing to a daemon · c3cbe547
      Antonio Terceiro authored
      Attaching BPF programs doesn't really work from within an udev-triggered
      processes. I checked that they are executed with uid 0, gid 0, and do
      have CAP_SYS_ADMIN, but I couldn't figure out exactly why.
      Thus, the device sharing is now done by a separate daemon, and the
      process executed by udev simply pokes that daemon to do its job. The
      daemon can use systemd socket activation, so it can be autostarted when
      needed (i.e. if any client connects to the socket). For development,
      just running the daemon directly will also work.
    • Antonio Terceiro's avatar
      lava_dispatcher_host: add support for docker device sharing under cgroups v2 · 180cb3c1
      Antonio Terceiro authored
      Under cgroups v2, device access control is done with BPF programs only.
      When docker creates a container, it already attaches a BPF program to
      that container cgroup. lava-dispather-host replaces that BPF program
      with one of its own, that allows the regular list of devices containers
      can usually access (/dev/null, /dev/zero etc), plus all the devices
      shared with the container. Subsequent device sharing with the same
      container overrides that BPF program with a new one.
      cgroups v2 is the default on Debian 11 (bullseye), so in there we need
      python3-bpfcc >= 0.21. In Debian 10 (buster, base-files << 1), we don't
      need python3-bpfcc, bpftool and the kernel headers, since the
      corresponding code path will not be used anyway.
      Fixes: lava/lava#467
  3. 02 Dec, 2021 3 commits
  4. 01 Dec, 2021 5 commits
  5. 30 Nov, 2021 6 commits
  6. 29 Nov, 2021 1 commit
    • Paul Sokolovsky's avatar
      boot/fvp: Consume all feedback from an FVP binary · d359a639
      Paul Sokolovsky authored
      The issue is similar to one previously fixed for the "read-feedback"
      action: only a single "short" read was performed. This in particular
      led to loss of code coverage reports printed out by the FVP binary
      (if requested with command-line options).
      Instead, read all data while it comes (i.e. until EOF or timeout is
      hit). Unlike previous fix for the "read-feedback" action, there's
      no detailed timeout handling: a hardcoded while of 5s is used as
      before, and for the case that and FVP binary will produce too much
      output (not an expected situation), we rely on general job timeout
      to stop it.
      Signed-off-by: default avatarPaul Sokolovsky <paul.sokolovsky@linaro.org>
  7. 26 Nov, 2021 12 commits
  8. 25 Nov, 2021 5 commits
    • Rémi Duraffort's avatar
      Merge branch 'revert-2733638c' into 'master' · 8be4180a
      Rémi Duraffort authored
      Revert "Merge branch 'flasher-docker' into 'master'"
      See merge request lava/lava!1634
    • stevanradakovic's avatar
      Revert "Merge branch 'flasher-docker' into 'master'" · 6f14eb77
      stevanradakovic authored
      This reverts merge request !1340
    • Rémi Duraffort's avatar
      Merge branch 'read-feedback-long-reads' into 'master' · 26584b2a
      Rémi Duraffort authored
      ReadFeedback: For finalize, perform long reads, make duration configurable
      See merge request lava/lava!1633
    • Rémi Duraffort's avatar
      Merge branch 'add_volteer_support' into 'master' · a3b233b0
      Rémi Duraffort authored
      device-types: add asus-cx9400-volteer
      See merge request lava/lava!1620
    • Paul Sokolovsky's avatar
      ReadFeedback: For finalize, perform long reads, make duration configurable · d17d667f
      Paul Sokolovsky authored
      Original read-feedback action implementation performed only 1 call to
      the underlying pexpect connection (via listen_feedback() method). So,
      if pexpect buffered a lot of output, only some initial small chunk of
      it (~2K) was returned. And if, say, timeout (duration) for read-feedback
      was 20s, and some data was read before that, only that data was returned,
      and read-feedback didn't try to wait for the remaining duration (in other
      words, the only case when it waited 20s was only when there was no data
      in buffer or form input, in other cases it waited less).
      This behavior (which we can call "sort reads") is a good match when
      reading feedback connections concurrently with the main connection
      processing (indeed, we just want to poll feedbacks to *try* to keep
      up with the output there, but don't delay main processing too much).
      But for read-feedback action, it leads to the fact that a lot of
      feedback output will never be processed at all. So, we actually
      need to perform "long" reads there, to spool all output which may
      be buffered and/or wait for the full duration specified.
      Additional complication is however that read-feedback action may be
      called not just at the end of job processing, but also at other times.
      E.g. the "fvp" boot action calls it after opening feedback connections,
      apparently, to bootstrap and synchronize their outputs. The difference
      between final vs other read-feedback calls is in "finalize" parameter.
      That's exactly what we modify - when read-feedback is executed with
      finalize=True parameter, it performs multiple pexpect reads for the
      duration specified (unless EOF is seen before that). The behavior
      of finalize=False case stays the same, to avoid unexpected change of
      behavior in parent actions which use it.
      Finally, the question of read-feedback duration. Previously, it was
      hardcoded as 1 second. Testing showed that even with the above changes,
      not enough feedback output may be captured. That's easy to explain -
      as during the main connection processing, we perform only short reads
      of feedbacks, of feedback connections produce a lot of info, it
      accumulates in buffers, and then the only chance to read it is at the
      end of processing (read-feedbacks(finalize=True)), and that may take
      its time too (including more than 1s).
      This duration also depends on particular test payload, and not on the
      device, in other words, this duration must be specified on the level
      of job, not on the level of device dictionary. It's however complication
      by the fact that read-feedback action isn't specified in jobs explicitly,
      but rather added in sub-pipelines to higher-level actions. Thus, parameters
      (like duration) can't be specified explicitly. With some stretch,
      read-feedback duration can be called read-feedback timeout. And that's
      exactly where this patch adds, it can be specified in job's top-level
      "timeouts" section:
          read-feedback: 20
      Signed-off-by: default avatarPaul Sokolovsky <paul.sokolovsky@linaro.org>
  9. 23 Nov, 2021 3 commits