Release of Solo5.0.7.2

[dinosaure]

v0.7.2 (2022-05-27)

• Suppress gcc array bounds warning in test_zeropage (@felixmoebius, dependency fixes #515)
• Xen: retrieve mem_size uniformly via XENMEM_memory_map hypercall.
  Previously, the memory map was extracted from the HVM start info (if
  available and booting directly via PVH), or multiboot info (if booting via
  multiboot). The fallback for direct PVH booting was the XENMEM_memory_map
  hypercall (which retrieves an E820 memory map). This lead to three distinct
  paths, with no fallback for the memory map not being present in the multiboot
  info. With QubesOS 4.1 (Xen 4.14), this didn't work anymore (it worked with
  QubesOS 4.0 (Xen 4.8)).
  Now, there is a single path of the code, which uses the hypercall. Since this
  is only executed once at startup, the overhead is negligible (@hannesm, consistently use %{make}% instead of "make" in opam invocations. #516,
  review and discussions with @marmarek @xaki23 @palainp)
• Xen: do not skip first token of command line when booted via multiboot.
  This code originated from the virtio binding, but when booting on xen via
  multiboot there is no additional token.
  (@hannesm, New ocp indent #517, review and testing with @palainp @xaki23)

[xaki23]

the links were probably meant to reference the following solo5-side PRs:

• Suppress gcc array bounds warning in test_zeropage Solo5/solo5#515
• Xen: retrieve mem_size via a hypercall and the E820 map Solo5/solo5#516
• xen: remove the "skip the first token in the cmdline" from multiboot code path Solo5/solo5#517

[mseri]

The failures

• linwrap.4.0.0 (failed: Unbound module Cpm)
• linwrap.5.0.0 (failed: Unbound module Cpm)
• ometrics.0.2.0 (failed: Failed to get sources of ometrics.0.2.0: Bad checksum)
  are unrelated, I will send a fix separately