From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753512AbbHSJmJ (ORCPT ); Wed, 19 Aug 2015 05:42:09 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:33542 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768AbbHSJmE (ORCPT ); Wed, 19 Aug 2015 05:42:04 -0400 MIME-Version: 1.0 In-Reply-To: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> References: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> Date: Wed, 19 Aug 2015 11:42:02 +0200 Message-ID: Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device From: Ard Biesheuvel To: "linux-kernel@vger.kernel.org" , Gabriel Somlo , "Richard W.M. Jones" , Jordan Justen , "x86@kernel.org" , QEMU Developers , gleb@cloudius-systems.com, Matt Fleming , kernelnewbies@kernelnewbies.org, Gerd Hoffmann , Paolo Bonzini , Laszlo Ersek , "gregkh@linuxfoundation.org" , ralf@linux-mips.org, zajec5@gmail.com, paul@pwsan.com, galak@codeaurora.org, linux-api@vger.kernel.org Cc: Leif Lindholm , Ard Biesheuvel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (missed some cc's) On 19 August 2015 at 11:38, Ard Biesheuvel wrote: > From: "Gabriel L. Somlo" > > Hi Gabriel, > >> 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? > >> In addition to cc-ing the people and lists indicated by get-maintainer.pl, >> I've added a few extra lists suggested by Matt Fleming on the qemu-devel >> list, as well as the qemu-devel list itself. >> >> Also cc-ing kernelnewbies, as this is my very first kenel contribution, >> so please go easy on me for whatever silly n00b mistakes I might have still >> missed, in spite of trying hard to do all my homework properly... :) >> >> The series consists of three patches: >> >> 1/3 - probes for the qemu fw_cfg device in locations known to work on >> the supported architectures, in decreasing order of "likelihood". >> >> While it *may* be possible to detect the presence of fw_cfg via >> acpi or dtb (on x86 and arm, respectively), there's no way I know >> of attempting that on sun4 and ppc/mac, so I've stuck with simply >> probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) >> in fw_cfg.c. I could use some advice on how else that could be >> done more elegantly, if needed. >> > > Sorry, but this is really out of the question, at least on ARM, but surely on > other architectures as well. You can't just go around and probe random memory > addresses. Perhaps QEMU tolerates it, but on anything that resembles a real > system, this will immediately blow up. Also, what happens if the QEMU memory > map changes? Add more probes addresses? > > It is not /that/ difficult to simply wire it up to the DT and ACPI > infrastructures, there are plenty of examples in the kernel tree how to > accomplish that. As a bonus, it removes all the arch specific knowledge > from your code, which means that if QEMU grows support for another DT or > ACPI based architecture, it will just work. > > 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. > > -- > Ard. >