Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

(missed some cc's)

On 19 August 2015 at 11:38, Ard Biesheuvel [off-list ref] wrote:

From: "Gabriel L. Somlo" <somlo-D+Gtc/HYRWM@public.gmane.org>

Hi Gabriel,

quoted

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?

quoted

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.