On Mon, Oct 05, 2015 at 08:43:46AM -0400, Gabriel L. Somlo wrote:

On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote:

quoted

On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote:

quoted

On 05/10/2015 12:00, Mark Rutland wrote:

quoted

Some of the keys in the example look like they'd come from other sources
(e.g. the *-tables entries), while others look like kernel/bootloader
configuration options (e.g. etc/boot-fail-wait, bootorder) -- I'm
concerned about redundancy here.

The redundancy is because the firmware and the bootloader actually
_consume_ these fw_cfg strings to produce the others (the ACPI tables,
the kernel configuration options).

On the other hand, hiding some strings just because they ought to have
been consumed already makes little sense.

Sure. However, I'm concerned that providing redundant interfaces for
those could lead to people grabbing information from here (because it's
convenient) rather than the existing canonical locations, which means we
get more software that works on fewer systems for no good reason.

What I couldn't figure out was what _additional_ information this
provided; it looked like a mixed bag of details we could already get
from disparate sources. If that's all it does, then it seems to me like
it doesn't add any benefit and potentially makes things worse.

So what do we get from this interface that we cannot get elsewhere, and
why is this the best way of exposing it?

Starting with qemu 2.4, it is possible to insert arbitrary named
blobs into fw_cfg from the qemu command line. *Those* entries
might be interesting to userspace, which is why it might be handy
to access to fw_cfg blobs in general.

So this is a mechanism to pass arbitrary key:value pairs to a guest
userspace? What would those be used for, and why would this be the
correct location for that?

How do we avoid clashes between user-selected names and those we need to
pass actual FW data?

Mark.