Set VM memory in runtime rather than hypervisor.args

[jodh-intel]

hypervisor.args currently hard-codes the amount of memory given to the VM using these options:

-m
2G,slots=2,maxmem=3G

We need to move this logic into the runtime to address 2 issues:

• The ability to potentially dynamically choose both the base and max memory assigned to the VM.
• The ability to support DPDK, which needs to know the amount of memory assigned to the VM.

The plan is to modify hypervisor.args.in so that rather than the lines above, the qemu -m option is specified like this instead:

-m
@VM_MEM@,slots=2,maxmem=@VM_MEM_MAX@

These new variables will be expanded by the runtime to their current values. We also need to add new global CLI options --vm-mem-size= and --vm-mem-size-max= to allow these default values to be modified (the user can set them by specifying their runtime using the helper script cc-oci-runtime.sh rather than cc-oci-runtime - see https://github.com/01org/cc-oci-runtime/wiki/Debugging).

• This new behaviour should be documented in the top-level README.rst.
• The niggle here is validating the arguments to --vm-mem-size= and --vm-mem-size-max=: we either have to add code that checks for the fairly flexible specifications that qemu permits (1024, 5M, 2G, etc), or defer to qemu when the hypervisor is launched. Maybe a half-way house approach would be to check that the argument is purely numeric with the exception of the last byte which can be alphabetic before handing it over to the hypervisor.
• We should add a g_debug() call to log if the user has specified --vm-mem-size= or --vm-max-mem-size= (along with the specified values).

---

For discussion on this topic, see:

• https://github.com/01org/cc-oci-runtime/pull/787#discussion_r109857946

[grahamwhaley]

A note: currently the difference between the mem (2G) and maxmem (3G) is used for the nvdimm mapping space for the DAX mapped OS image. We may need to add some extra sanity check/debug information in case the user sets the mem/maxmem which make this mapping fail. My guess is currently it would be an obscure failure in QEMU, and hence hard to figure out what has been 'broken'. We should check what the failure case 'looks like', and if necessary improve the QEMU error reporting or add a pre-QEMU sanity check to the runtime (possibly that could dynamically check the size of the .img file is <= the size of the mem/maxmem difference).