Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg

[Laszlo Ersek]

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