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
