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
