From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQn1A-00055L-9J for qemu-devel@nongnu.org; Wed, 25 Feb 2015 20:13:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQn15-0002os-9n for qemu-devel@nongnu.org; Wed, 25 Feb 2015 20:13:32 -0500 Received: from mail-vc0-x235.google.com ([2607:f8b0:400c:c03::235]:32918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQn15-0002of-5V for qemu-devel@nongnu.org; Wed, 25 Feb 2015 20:13:27 -0500 Received: by mail-vc0-f181.google.com with SMTP id im6so2837397vcb.12 for ; Wed, 25 Feb 2015 17:13:26 -0800 (PST) Date: Wed, 25 Feb 2015 20:13:20 -0500 From: "Gabriel L. Somlo" Message-ID: <20150226011319.GA24405@foober.ini.cmu.edu> References: <1424806987-24790-1-git-send-email-somlo@cmu.edu> <54ED0439.1030904@redhat.com> <1424904034.21588.19.camel@mfleming-mobl1.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424904034.21588.19.camel@mfleming-mobl1.ger.corp.intel.com> Subject: Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matt Fleming Cc: mdroth@linux.vnet.ibm.com, Laszlo Ersek , rjones@redhat.com, qemu-devel@nongnu.org On Wed, Feb 25, 2015 at 10:40:34PM +0000, Matt Fleming wrote: > > Right, I was thinking about this in the context of configuring the BIOS > (OVMF in my case) with runtime tunable knobs instead of having to > recompile the BIOS image from scratch. > > I'll carve out some time to review your patches Gabriel. Thanks ! Although the more I think about it, the more I like the idea of simply adding a generic named blob to fw_cfg from the host side (rather than adding a dedicated "-guestenv 'foo=bar'" option. If I make sure the generic "-fwcfg name='blob-name',file=./blob_file" is processed *after* everything else is already inserted into fw_cfg, and that we throw an error if 'blob-name' collides with anything already added during qemu setup, there's no reason I can't pass a blob named 'etc/guest-info'. So I'll send out a v2 attempting to do that, which should take care of both of our needs on the host side. On the guest side, you should be taken care of -- read whatever you need to read from fw_cfg using the BIOS's existing mechanisms. For myself, I'm tempted to write a kernel driver to allow me to simply "cat /sys/firmware/fw_cfg/etc/guestinfo | grep '^key_name='" when I need to retrieve a guest environment variable. However, I'd first need to figure out how to do the equivalent thing on Windows, and whether the requirement to add a kernel module is worth it when my main purpose is making it easy to recycle VMWare VMs which use "vmware-tools --cmd info-get guestinfo.key_name" :) Maybe it's better to stick with accessing the fw_cfg io ports from guest-side userspace, so patch 2/2 should stand as is (modulo Daniel's suggestion to make it a separate binary from "qemu-ga", of course). Thanks, --Gabriel