From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQv0X-0004Ke-CX for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:45:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQv0T-0004IK-OX for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:45:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQv0T-0004Hr-HF for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:45:21 -0500 Message-ID: <54EEEB26.9060102@redhat.com> Date: Thu, 26 Feb 2015 10:45:10 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1424806987-24790-1-git-send-email-somlo@cmu.edu> <54ED0439.1030904@redhat.com> <1424904034.21588.19.camel@mfleming-mobl1.ger.corp.intel.com> <20150226011319.GA24405@foober.ini.cmu.edu> In-Reply-To: <20150226011319.GA24405@foober.ini.cmu.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Gabriel L. Somlo" , Matt Fleming Cc: rjones@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On 02/26/15 02:13, Gabriel L. Somlo wrote: > 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. Such named blobs were exactly the idea we had with Matt when discussing this briefly on IRC. > > 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, Precisely; please do that. > 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. I too can try to review that, but I definitely expect my review not to be the "last word". :) > 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. Yup. > > > 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. You might not need a kernel driver for this. If you have ioport access (on x86), you can speak the fwcfg "protocol" directly. > 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, Right; as long as you stay with x86 guests only. > so patch 2/2 should stand as is (modulo Daniel's > suggestion to make it a separate binary from "qemu-ga", of course). Qga already implements a number of commands with fork() + execle(), so maybe you could separate out a small, "dumb" helper binary for the ioport access. Thanks Laszlo