From: mark.rutland@arm.com (Mark Rutland)
To: kernelnewbies@lists.kernelnewbies.org
Subject: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
Date: Mon, 5 Oct 2015 13:56:47 +0100 [thread overview]
Message-ID: <20151005125647.GL19064@leverpostej> (raw)
In-Reply-To: <20151005124346.GG1977@HEDWIG.INI.CMU.EDU>
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?
How do we avoid clashes between user-selected names and those we need to
pass actual FW data?
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: "Gabriel L. Somlo" <somlo-D+Gtc/HYRWM@public.gmane.org>
Cc: Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernelnewbies-7JyXY6prKcjpASu1u0TL5ti2O/JbrIOy@public.gmane.org,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
jordan.l.justen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
Date: Mon, 5 Oct 2015 13:56:47 +0100 [thread overview]
Message-ID: <20151005125647.GL19064@leverpostej> (raw)
In-Reply-To: <20151005124346.GG1977-h65ZQ0r4j6KKUezXOiBB2eW1CriLhL8O@public.gmane.org>
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?
How do we avoid clashes between user-selected names and those we need to
pass actual FW data?
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
gregkh@linuxfoundation.org, paul@pwsan.com, galak@codeaurora.org,
will.deacon@arm.com, agross@codeaurora.org, zajec5@gmail.com,
hanjun.guo@linaro.org, catalin.marinas@arm.com,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
kernelnewbies@kernelnewbies.org, matt.fleming@intel.com,
lersek@redhat.com, jordan.l.justen@intel.com, mst@redhat.com,
peter.maydell@linaro.org, leif.lindholm@linaro.org,
ard.biesheuvel@linaro.org, kraxel@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
Date: Mon, 5 Oct 2015 13:56:47 +0100 [thread overview]
Message-ID: <20151005125647.GL19064@leverpostej> (raw)
In-Reply-To: <20151005124346.GG1977@HEDWIG.INI.CMU.EDU>
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?
How do we avoid clashes between user-selected names and those we need to
pass actual FW data?
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: "Gabriel L. Somlo" <somlo@cmu.edu>
Cc: peter.maydell@linaro.org, paul@pwsan.com, zajec5@gmail.com,
catalin.marinas@arm.com, jordan.l.justen@intel.com,
kernelnewbies@kernelnewbies.org, gregkh@linuxfoundation.org,
agross@codeaurora.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, leif.lindholm@linaro.org,
qemu-devel@nongnu.org, ard.biesheuvel@linaro.org,
matt.fleming@intel.com, mst@redhat.com, hanjun.guo@linaro.org,
galak@codeaurora.org, Paolo Bonzini <pbonzini@redhat.com>,
linux-api@vger.kernel.org, lersek@redhat.com, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
Date: Mon, 5 Oct 2015 13:56:47 +0100 [thread overview]
Message-ID: <20151005125647.GL19064@leverpostej> (raw)
In-Reply-To: <20151005124346.GG1977@HEDWIG.INI.CMU.EDU>
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?
How do we avoid clashes between user-selected names and those we need to
pass actual FW data?
Mark.
next prev parent reply other threads:[~2015-10-05 12:56 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 23:28 [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device Gabriel L. Somlo
2015-10-03 23:28 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's " Gabriel L. Somlo
2015-10-03 23:28 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-04 1:34 ` kbuild test robot
2015-10-04 1:34 ` [Qemu-devel] " kbuild test robot
2015-10-04 1:34 ` kbuild test robot
2015-10-06 8:40 ` [Qemu-devel] " Stefan Hajnoczi
2015-10-06 8:40 ` Stefan Hajnoczi
2015-10-06 8:40 ` Stefan Hajnoczi
2015-10-06 12:53 ` Laszlo Ersek
2015-10-06 12:53 ` [Qemu-devel] " Laszlo Ersek
2015-10-06 12:53 ` Laszlo Ersek
2015-10-06 12:53 ` Laszlo Ersek
2015-10-06 17:54 ` Andy Lutomirski
2015-10-06 17:54 ` [Qemu-devel] " Andy Lutomirski
2015-10-06 17:54 ` Andy Lutomirski
2015-10-06 18:17 ` Gabriel L. Somlo
2015-10-06 18:17 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-06 18:17 ` Gabriel L. Somlo
2015-10-06 18:17 ` Gabriel L. Somlo
2015-10-03 23:28 ` [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver Gabriel L. Somlo
2015-10-03 23:28 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-04 7:54 ` Michael S. Tsirkin
2015-10-04 7:54 ` [Qemu-devel] " Michael S. Tsirkin
2015-10-04 7:54 ` Michael S. Tsirkin
2015-10-04 7:54 ` Michael S. Tsirkin
2015-10-04 20:24 ` Gabriel L. Somlo
2015-10-04 20:24 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-04 20:24 ` Gabriel L. Somlo
2015-10-04 20:24 ` Gabriel L. Somlo
2015-10-04 20:27 ` Gabriel L. Somlo
2015-10-04 20:27 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-04 20:27 ` Gabriel L. Somlo
2015-10-04 20:27 ` Gabriel L. Somlo
2015-10-03 23:28 ` [PATCH v3 3/4] kobject: export kset_find_obj() for module use Gabriel L. Somlo
2015-10-03 23:28 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` [PATCH v3 4/4] firmware: create directory hierarchy for sysfs fw_cfg entries Gabriel L. Somlo
2015-10-03 23:28 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-03 23:28 ` Gabriel L. Somlo
2015-10-05 10:00 ` [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device Mark Rutland
2015-10-05 10:00 ` [Qemu-devel] " Mark Rutland
2015-10-05 10:00 ` Mark Rutland
2015-10-05 10:00 ` Mark Rutland
2015-10-05 11:48 ` Paolo Bonzini
2015-10-05 11:48 ` [Qemu-devel] " Paolo Bonzini
2015-10-05 11:48 ` Paolo Bonzini
2015-10-05 11:48 ` Paolo Bonzini
2015-10-05 12:23 ` Mark Rutland
2015-10-05 12:23 ` [Qemu-devel] " Mark Rutland
2015-10-05 12:23 ` Mark Rutland
2015-10-05 12:23 ` Mark Rutland
2015-10-05 12:43 ` Gabriel L. Somlo
2015-10-05 12:43 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-05 12:43 ` Gabriel L. Somlo
2015-10-05 12:43 ` Gabriel L. Somlo
2015-10-05 12:56 ` Mark Rutland [this message]
2015-10-05 12:56 ` [Qemu-devel] " Mark Rutland
2015-10-05 12:56 ` Mark Rutland
2015-10-05 12:56 ` Mark Rutland
2015-10-05 13:21 ` Gabriel L. Somlo
2015-10-05 13:21 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-05 13:21 ` Gabriel L. Somlo
2015-10-05 13:21 ` Gabriel L. Somlo
2015-10-05 12:40 ` Gabriel L. Somlo
2015-10-05 12:40 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-05 12:40 ` Gabriel L. Somlo
2015-10-05 12:40 ` Gabriel L. Somlo
2015-10-05 12:50 ` Peter Maydell
2015-10-05 12:50 ` [Qemu-devel] " Peter Maydell
2015-10-05 12:50 ` Peter Maydell
2015-10-05 12:50 ` Peter Maydell
2015-10-05 13:13 ` Gabriel L. Somlo
2015-10-05 13:13 ` [Qemu-devel] " Gabriel L. Somlo
2015-10-05 13:13 ` Gabriel L. Somlo
2015-10-05 13:13 ` Gabriel L. Somlo
2015-10-05 13:18 ` Paolo Bonzini
2015-10-05 13:18 ` [Qemu-devel] " Paolo Bonzini
2015-10-05 13:18 ` Paolo Bonzini
2015-10-05 13:18 ` Paolo Bonzini
2015-11-04 20:48 ` Gabriel L. Somlo
2015-11-04 20:48 ` [Qemu-devel] " Gabriel L. Somlo
2015-11-04 20:48 ` Gabriel L. Somlo
2015-11-04 20:48 ` Gabriel L. Somlo
2015-10-05 13:05 ` Mark Rutland
2015-10-05 13:05 ` [Qemu-devel] " Mark Rutland
2015-10-05 13:05 ` Mark Rutland
2015-10-06 7:18 ` Laszlo Ersek
2015-10-06 7:18 ` [Qemu-devel] " Laszlo Ersek
2015-10-06 7:18 ` Laszlo Ersek
2015-10-06 7:18 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151005125647.GL19064@leverpostej \
--to=mark.rutland@arm.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.