Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"

[Christopher Covington]

Hi Gabriel,

Summary up top, why I like the approach below.

On 02/03/2015 02:09 PM, Gabriel L. Somlo wrote:
> Hi,

> For this functionality to really resemble the way environment variables
> are used, environment information should be provided as part of the QEMU
> command line, without the requirement to make a separate/subsequent
> connection to the guest agent. For example:
> 
>     qemu-system-x86_64 -guest-env="VAR1=value1;VAR2=value 2" -hda image.qcow2

qemu-system-x86_64 -append "myvars=VAR1=value1;VAR2=value2" -hda image.qcow2

> Once the guest is started, it should be possible to query the guest
> environment with something like:
> 
>     $ qemu-guest-env get VAR1
>     value1
> 
>     $ qemu-guest-env get VAR2
>     value 2

eval `sed -nr 's/myvars=(.*)/\1/' /proc/cmdline`
echo $VAR1
echo $VAR2

I have two use cases that I've enabled or would like to enable across a
variety of platforms and architectures:

A) Script workload(s) that should run from a regular "cold" boot.
B) On slow systems, script the workload(s) that should be run immediately
following a checkpoint restore ("warm" boot).

Originally I was using the ARM Angel semihosting command line for both A and
B. But that required a JTAG debugger be attached to hardware devices, so I
switched to appending foo=bar strings to /proc/cmdline, which has the
additional benefit of being portable across architectures. Does QEMU's -append
flag for setting and something like `sed -nr 's/myopts=(.*)/\1/'
/proc/cmdline` for getting work for your use case?

I've wondered about something portable across architectures like QMP or
VirtIO-something for the B use case, but that hasn't really progressed beyond
thought experiment.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project