On 21 August 2015 at 05:47, Gabriel L. Somlo <somlo@xxxxxxx> wrote: > On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote: >> On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@xxxxxxx> wrote: >> >> > From: "Gabriel L. Somlo" <somlo@xxxxxxx> >> >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
