Re: [Qemu-devel] fw_cfg specification ?

[Gabriel L. Somlo]

On Wed, Mar 11, 2015 at 07:50:40PM +0100, Laszlo Ersek wrote:
> On 03/11/15 16:27, Gabriel L. Somlo wrote:
> > Hi,
> > 
> > I'm looking for the closest thing to an official spec for qemu's
> > fw_cfg device, and so far I have found this:
> > 
> > http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg00238.html
> > 
> > but it apparently never got committed to qemu (any idea why not?).
> 
> Must have fallen through the cracks. (Just speculating; in April 2011 I
> had been with RH for less than half a year, and learning Xen. :))
> 
> > Googling around didn't get me much further than that.
> > 
> > Is there anything better or more up to date floating around out
> > there somewhere ?
> 
> 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 was more interested in the "hardware" implementation details,
and the reasoning behind them.

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.

I don't quite get the part where

  struct FWCfgState {
    ...
    FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
    ...
  }

is accessed via 

  int arch = !!(key & FW_CFG_ARCH_LOCAL);
  ...
  s->entries[arch][key].foo = ...

I.e., what's the significance of arch==0 vs. arch==1 ?

Also, what's the significance of handling guest-initiated writes to
the data port ? Could the guest write larger chunks of data than the
current size of the selected entry ? Would the selected entry's size
grow accordingly ? Would it shrink if the guest (over)wrote less than
the current size ?

I know it's all going to start making sense eventually, if I stare at
the source long enough :) I'm just trying to speed up that process as
much as possible.

Right now, at a quick glance, qemu writes a bunch of stuff into the
fw_cfg data structure before starting the guest, and the guest (well,
mostly the guest's BIOS) does a bunch of things based on the
"breadcrumbs" it reads from the fw_cfg device.

But that doesn't seem to be the whole story...

> If you have a ton of time, you could try documenting fw_cfg yourself,
> but as I said, it's a moving target, so the description would either
> become stale quickly, or require people to keep it in sync with the
> source all the time. Updating documentation sucks *hard*.

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...

Thanks much,
--Gabriel