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

[Ard Biesheuvel]

From: "Gabriel L. Somlo" <somlo@xxxxxxx>

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/