Date:	Mon, 5 Oct 2015 09:21:34 -0400
From:	"Gabriel L. Somlo" <somlo@....edu>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Paolo Bonzini <pbonzini@...hat.com>, gregkh@...uxfoundation.org,
	paul@...an.com, galak@...eaurora.org, will.deacon@....com,
	agross@...eaurora.org, zajec5@...il.com, hanjun.guo@...aro.org,
	catalin.marinas@....com, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org,
	matt.fleming@...el.com, lersek@...hat.com,
	jordan.l.justen@...el.com, mst@...hat.com,
	peter.maydell@...aro.org, leif.lindholm@...aro.org,
	ard.biesheuvel@...aro.org, kraxel@...hat.com, qemu-devel@...gnu.org
Subject: Re: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device

On Mon, Oct 05, 2015 at 01:56:47PM +0100, Mark Rutland wrote:
> 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:
> > > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote:
> > > > 
> > > > 
> > > > On 05/10/2015 12:00, Mark Rutland wrote:
> > > > > 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?

Yes to arbitrary host->guest arbitrary key:value pairs.
fw_cfg because it's asynchronous (host supplies the data at guest
start time, and no longer has to worry about whether and when guests
may or may not start some sort of agent in order to be able to accept
connections, etc); also because it's guest-os agnostic (no
piggy-backing on e.g. kernel command line). Drivers to make data
available to guest userspace can be written for any guest OS.

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

Internally supplied blobs (by QEMU) meant for the firmware are, by
convention, prefixed with "/etc/...". Command-line blobs are expected
to use "opt/...". QEMU issues a warning if a name is used on the
command line that doesn't begin with 'opt/'.

Thanks,
--Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists