On 21 August 2015 at 05:47, Gabriel L. Somlo [off-list ref] wrote:

On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:

quoted

On 19 August 2015 at 22:49, Gabriel L. Somlo [off-list ref] wrote:

quoted

quoted

quoted

From: "Gabriel L. Somlo" <somlo-D+Gtc/HYRWM@public.gmane.org>

quoted

Several different architectures supported by QEMU are set up with a
"firmware configuration" (fw_cfg) device, used to pass configuration
"blobs" into the guest by the host running QEMU.

Historically, these config blobs were mostly of interest to the guest
BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
the command line, which makes them potentially interesting to userspace
(e.g. for passing early boot environment variables, etc.).

Does 'potentially interesting' mean you have a use case? Could you elaborate?

My personal one would be something like:

cat > guestinfo.txt << EOT
  KEY1="val1"
  KEY2="val2"
  ...
EOT

qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...

Then, from inside the guest:

  . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw

  do_something_with $KEY1 $KEY2
  ...

But I'm thinking this is only one of the many positive things one
could do with the ability to access random host-supplied blobs from
guest userspace :)

'random host-supplied blobs' sounds awfully like files in a file
system to me, and that is already supported by QEMU and works with any
guest OS unmodified. If you are in control of the command line, surely
you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
simply turns up as a volume.

That did come up, here's the start of original thread on the qemu mailing
list from a while back:

https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html

To recap, the main advantages to transfering data this way are:

        1. Asynchronous

           The host can simply pass data via the qemu command line, and
           not have to care if/when the guest is ready to accept the
           data (i.e. has made it far enough to e.g. start a guest agent)

How does that not apply to a file system?

        2. Out-of-band

           I don't have to take over a user-visible element such as a
           disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
           exist and are NOT actual Ethernet/TCP-IP network interfaces :)

OK that makes sense. Note that I am not the one you need to convince
that this is a good idea, but I would still like to understand better
why your use case requires this. Could you explain?

-- 
Ard.