From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ2Ix-0004UP-Qk for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:55:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ2Is-0000M5-Kn for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:55:51 -0500 Received: from smtp.codeaurora.org ([198.145.11.231]:58223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ2Is-0000Lw-F4 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:55:46 -0500 Message-ID: <54D240FD.6010105@codeaurora.org> Date: Wed, 04 Feb 2015 10:55:41 -0500 From: Christopher Covington MIME-Version: 1.0 References: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> In-Reply-To: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , qemu-devel@nongnu.org Cc: mdroth@linux.vnet.ibm.com 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