[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via f
Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg
Thu, 26 Feb 2015 10:45:10 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
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.
> 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