Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753664AbbHSJjF (ORCPT ); Wed, 19 Aug 2015 05:39:05 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:34332 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753602AbbHSJjA (ORCPT ); Wed, 19 Aug 2015 05:39:00 -0400 From: Ard Biesheuvel To: linux-kernel@vger.kernel.org, somlo@cmu.edu Cc: leif.lindholm@linaro.org, Ard Biesheuvel Subject: Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Date: Wed, 19 Aug 2015 11:38:29 +0200 Message-Id: <1439977109-20314-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2774 Lines: 62 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. -- 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/