Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752844AbbHUDvl (ORCPT ); Thu, 20 Aug 2015 23:51:41 -0400 Received: from SMTP.ANDREW.CMU.EDU ([128.2.157.37]:56069 "EHLO smtp.andrew.cmu.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752263AbbHUDvj (ORCPT ); Thu, 20 Aug 2015 23:51:39 -0400 Date: Thu, 20 Aug 2015 23:47:57 -0400 From: "Gabriel L. Somlo" To: Ard Biesheuvel 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 Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Message-ID: <20150821034757.GA6982@GLSMBP.INI.CMU.EDU> References: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> <20150819204915.GA6164@GLSMBP.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.29.619 X-SMTP-Spam-Clean: 8% ( MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_IN_BODY 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 8% Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4034 Lines: 105 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) 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 :) > > DT on ARM is fine, and I'm certainly happy to learn how to do it (even > > though my main focus is, for now, x86). The unfortunate thing though > > is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into > > first adding it in on the host side, before I can rewrite the guest side > > driver to look it up in there :) > > > >> > I am not sure how relevant sun4 and ppc/mac are for what you are trying to > >> > accomplish, but perhaps it would be best to focus on x86 and ARM for now > >> > and do it correctly. If the probing is actually needed, you can always add > >> > it later. > > > > I guess that's the direction things seem to be headed, although it would > > make me a bit sad to leave out sun and ppc right from the very beginning :) > > > > Sorry to be blunt, but I am not convinced there is a need for this > driver anyway. See above (hopefully I'm being sufficiently persuasive :) ) In VMWare one would fetch similar "guestinfo" variables via something like FOO=$(vmware-tools --getinfo "FOO") but I thought exposing fw_cfg in /sys/firmware/... would make access to *any* blobs (including, but not limited to my particular use case) even easier and more generic than that. > > PS. If you have one .c file in the kernel which does any of the DT-on-arm > > boilerplate I'm supposed to immitate, I'd appreciate the shortcut :) > > > > Check out drivers/tty/serial/amba-pl011.c I'll check it out. Thanks much! --Gabriel -- 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/