(missed some cc's) On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
