Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932426AbbHXH4c (ORCPT ); Mon, 24 Aug 2015 03:56:32 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:33594 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753109AbbHXH4a (ORCPT ); Mon, 24 Aug 2015 03:56:30 -0400 MIME-Version: 1.0 In-Reply-To: <20150821034757.GA6982@GLSMBP.INI.CMU.EDU> References: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> <20150819204915.GA6164@GLSMBP.INI.CMU.EDU> <20150821034757.GA6982@GLSMBP.INI.CMU.EDU> Date: Mon, 24 Aug 2015 09:56:29 +0200 Message-ID: Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device From: Ard Biesheuvel To: "Gabriel L. Somlo" Cc: "linux-kernel@vger.kernel.org" , "Richard W.M. Jones" , Jordan Justen , "x86@kernel.org" , QEMU Developers , Gleb Natapov , Matt Fleming , kernelnewbies@kernelnewbies.org, Gerd Hoffmann , Paolo Bonzini , Laszlo Ersek , "gregkh@linuxfoundation.org" , ralf@linux-mips.org, zajec5@gmail.com, paul@pwsan.com, Kumar Gala , linux-api@vger.kernel.org, Leif Lindholm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3016 Lines: 78 On 21 August 2015 at 05:47, Gabriel L. Somlo wrote: > On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote: >> On 19 August 2015 at 22:49, Gabriel L. Somlo wrote: >> >> > From: "Gabriel L. Somlo" >> >> >> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/