Re: [Qemu-devel] fw_cfg specification ?

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> >> I won't say "better", but it is "committed": check
> >> "Documentation/devicetree/bindings/arm/fw-cfg.txt" in the kernel tree.
> >> It is intentionally vague on the set of keys and fw_cfg files that qemu
> >> provides, because that's a moving target. You can only rely on the qemu
> >> source for those.
> > 
> > The fw_cfg interface from the guest's perspective is pretty
> > straightforward: select something on the control port, read a blob
> > from the data port.

I think just commiting Jordan's patch as-is would be a good start.
Then we can go from there adding missing bits.

It's also easier to refuse patches without doc updates if there actually
is documentation in the first place ;)

> > For instance, I get there's a total of 0x30 entries
> > (FWCfgEntry entries), the last 0x10 of which have 
> > "file names" and are referenced from the "FWCfgFiles *files"
> > structure.

That's basically referencing stuff by name rather than magic numbers.
It's used for all new stuff.  There is a simliar interface named 'cbfs'
between coreboot and seabios.

> No. Please see the fw_cfg_write() function. Only the same size can be
> written, and the write callback runs when that's completed.
> 
> In any case, I'm unaware of *any* instance when an fw_cfg blob is
> rewritten by the guest.

> In fact, such *write* callbacks are registered in qemu with
> fw_cfg_add_callback(), and I can't see any calls to that function. It's
> dead code, apparently.

Guess we should just drop the code then.

> There is though a bit more to the story: the (recent) read callbacks.
> Qemu sometimes decides to re-generate a "bunch of stuff" in the fw_cfg
> blobs. See the commit message here:

That is used for acpi.  acpi initialization goes like this:

  (1) firmware initializes the hardware as it pleases.
  (2) firmware fetches acpi tables from qemu, and the read callback
      is used to update the addresses in the acpi tables according
      to the initialization done by the firmware (acpi pci device,
      mmconfig xbar, ...)

Main reason to do it this way is we don't need paravirtual interfaces to
pass around those addresses.

> > Once I start getting what's going on (e.g., w.r.t. the questions above)
> > I wouldn't mind just adding *comments* to the source, for the next guy
> > who, like me, is trying to get the lay of the land, but I'm not there
> > yet...

I'd suggest to update the doc file created by the old patch instead.

cheers,
  Gerd