Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1205376 > unrolled thread

[PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-08-11 20:50 +0200
    Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-08-19 11:40 +0200
      Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-08-19 11:50 +0200
        Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-08-19 23:00 +0200
          Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Leif Lindholm <leif.lindholm@linaro.org> - 2015-08-20 01:10 +0200
          Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-08-20 07:30 +0200
            Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-08-21 06:00 +0200
              Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-08-24 10:00 +0200
          Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device Christopher Covington <cov@codeaurora.org> - 2015-08-26 20:20 +0200
            Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-09-01 18:20 +0200

#1205376 — [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

From: "Gabriel Somlo" <somlo@cmu.edu>

This patch set makes QEMU fw_cfg blobs available for viewing (read-only)
via SysFS.

New since v1:

    1/3:

	- renamed sysfs path components:

		s/fw_cfg/qemu_fw_cfg/g, at Greg's suggestion
		
		s/by_select/by_key/g since it feels a bit more intuitive

	- attribute "select" renamed to "key", along the same train of
	  thought.

	- renamed actual source file from "fw_cfg.c" to "qemu_fw_cfg.c"
	  and doc file in Documentation/ABI/testing to
	  "sysfs-firmware-qemu_fw_cfg"

	- s/uintXX_t/uXX/g, at Greg's suggestion

	- using named identifiers to initialize access mode table
	  (static struct fw_cfg_access fw_cfg_modes[]) per Greg's
	  suggestion

	- removed redundant "capable(CAP_SYS_ADMIN)" checks (per Greg's
	  feedback)

    2/3:

	- EXPORT_SYMBOL(kset_find_obj) statement moved immediately
	  after kset_find_obj() definition.

Re. 'struct device' vs. straight-up kobject:

I dug around a bit, and found a bunch of stuff under /sys/devices
(such as e.g. /sys/devices/virtual/dmi and /sys/devices/platform/applesmc)

The first one is particularly interesting, as it presents a
somewhat different view of the same internal information displayed by
/sys/firmware/dmi/, only /sys/devices/virtual/dmi looks more "cooked",
in that it exposes individual fields of the several different DMI tables.

None of the subfolders of /sys/devices/... appears to facilitate access
to the "raw blobs" contained by the respective devices represented there.

Even applesmc (the other device with which I'm somewhat familiar) does
a lot of "cooking" of the values held by the device.

So, at the end of the day, I want the information I expose about fw_cfg
to look more like /sys/firmware/dmi than like /sys/devices/virtual/dmi
in that I have a bunch of cached metadata attributes for each of the
blobs, and want to offer access to the raw blob data, and there's no
rhyme or reason to the actual internals of any of the blobs, so offering
a "cooked" view like in /sys/devices/... doesn't feel like the best fit...

Obviously, I may be totally wrong... :)

Lastly, re. Greg's comment on patch 3/3:
> Shouldn't all of this be done in userspace with the symlinks and all?
> It seems like you are trying to duplicate the /dev/block/by-name and
> such.  Policy decisions like symlinks and naming should be done there,
> in userspace, and not directly in sysfs if at all possible.

OK, so here's the "pseudo-bash" equivalent of what this patch does:

	#upon successful qemu_fw_cfg.ko insertion

	BY_KEY="/sys/firmware/qemu_fw_cfg/by_key"
	BY_NAME="/sys/firmware/qemu_fw_cfg/by_name"

	mkdir -p $BY_NAME

	for KEY in $(ls $BY_KEY); do
		FILE=$(cat $BY_KEY/$KEY/name)
		[ mkdir -p $BY_NAME/$(dirname $FILE) ] || continue
		pushd $BY_NAME/$(dirname $FILE)
		ln -s $BY_KEY/$KEY $(basename $FILE)
		popd
	done

Note how it MAY fail to mkdir, in which case it skips to the next key,
or it MAY fail to create the symlink, in which case it just moves on
to the next key as well.

Again, the fw_cfg device doesn't have any notion of nested directories,
it just parrots back some random string someone choose as a name for a
given blob, but these strings typically contain slash-separated ASCII
which "looks like" it "could" be a path name :)

If there's a reasonable way to do this dynamically, immediately upon
insertion of the qemu_fw_cfg.ko module, patches 2/3 and 3/3 could be
dropped.

But before that, I'd appreciate a pointer to how/where this can be done
in userspace. Would it be available e.g. during early boot, early enough
to e.g. raw-dump an ASCII blob containing shell variable definitions (e.g.
to set hostname on the guest, etc ?)

Doing it as part of the qemu_fw_cfg.ko module itself has the advantage
of it being available immediately, without anything having to "watch"
for the module being inserted.

But if userspace is the standard, "canonical" place to do something like
this, I'd be happy to give it a try, once I find the right tree to bark
up on... :)

Thanks much,
   Gabriel


Old "cover-letter" blurb for v1:
> Several different architectures supported by QEMU are set up with a
> "firmware configuration" (fw_cfg) device, used to pass configuration
> "blobs" into the guest by the host running QEMU.
>
> Historically, these config blobs were mostly of interest to the guest
> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> the command line, which makes them potentially interesting to userspace
> (e.g. for passing early boot environment variables, etc.).
>
> In addition to cc-ing the people and lists indicated by get-maintainer.pl,
> I've added a few extra lists suggested by Matt Fleming on the qemu-devel
> list, as well as the qemu-devel list itself.
>
> Also cc-ing kernelnewbies, as this is my very first kenel contribution,
> so please go easy on me for whatever silly n00b mistakes I might have still
> missed, in spite of trying hard to do all my homework properly... :)
>
> The series consists of three patches:
>
>   1/3 - probes for the qemu fw_cfg device in locations known to work on
> 	the supported architectures, in decreasing order of "likelihood".
>
> 	While it *may* be possible to detect the presence of fw_cfg via
> 	acpi or dtb (on x86 and arm, respectively), there's no way I know
> 	of attempting that on sun4 and ppc/mac, so I've stuck with simply
> 	probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
> 	in fw_cfg.c. I could use some advice on how else that could be
> 	done more elegantly, if needed.
>
> 	Upon successfully detecting a present fw_cfg device, we set up
> 	/sys/firmware/fw_cfg/by_select entries for each blob available
> 	on the fw_cfg device.
>
>   2/3 - export kset_find_obj() (in lib/kobject.c) for use with modules,
> 	which will come in handy in patch #3, below.
>
>   3/3 - add a "user friendly" way of listing fw_cfg blobs by name rather
> 	than by unique selector key.
>
> 	Since fw_cfg blob names are traditionally set up to look like
> 	path names, it would be nice to mirror that fact when displaying
> 	them under /sys/firmware/fw_cfg in a "by_name" subdirectory.
>
> 	I'm using ksets to reflect subdirectories matching "dirname"
> 	tokens separated by '/' within each fw_cfg blob "filename",
> 	and symlinks into the "by_select" subdirectory for each "basename".
>
> 	Since the fw_cfg device doesn't enforce that blob names have
> 	well-behaved and non-conflicting names, it is possible (though
> 	unlikely) that there will be blobs named:
>
> 		"etc/foo/bar"
> 	and
> 		"etc/foo"
>
> 	where "foo" will try to be both a subdirectory AND a symlink under
> 	/sys/firmware/fw_cfg/by_name/etc/. In such an event, the latter
> 	fw_cfg blob will simply be skipped from having an entry created
> 	under the user-friendly "by_name" subdirectory, remaining listed
> 	only as an entry under the "by_select" subdirectory.
>
> I have tested this on x86_64 and armv7hl+lpae kernels. Builds and installs
> OK as both a module and linked directly into the kernel.

Gabriel Somlo (3):
  firmware: introduce sysfs driver for QEMU's fw_cfg device
  kobject: export kset_find_obj() to be used from modules
  firmware: fw_cfg: create directory hierarchy for fw_cfg file names

 .../ABI/testing/sysfs-firmware-qemu_fw_cfg         | 210 ++++++++
 drivers/firmware/Kconfig                           |  10 +
 drivers/firmware/Makefile                          |   1 +
 drivers/firmware/qemu_fw_cfg.c                     | 560 +++++++++++++++++++++
 lib/kobject.c                                      |   1 +
 5 files changed, 782 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
 create mode 100644 drivers/firmware/qemu_fw_cfg.c

-- 
2.4.3

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

[toc] | [next] | [standalone]

#1209743

From: "Gabriel L. Somlo" <somlo@cmu.edu>

Hi Gabriel,

> Several different architectures supported by QEMU are set up with a
> "firmware configuration" (fw_cfg) device, used to pass configuration
> "blobs" into the guest by the host running QEMU.
>
> Historically, these config blobs were mostly of interest to the guest
> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> the command line, which makes them potentially interesting to userspace
> (e.g. for passing early boot environment variables, etc.).
>

Does 'potentially interesting' mean you have a use case? Could you elaborate?

> In addition to cc-ing the people and lists indicated by get-maintainer.pl,
> I've added a few extra lists suggested by Matt Fleming on the qemu-devel
> list, as well as the qemu-devel list itself.
>
> Also cc-ing kernelnewbies, as this is my very first kenel contribution,
> so please go easy on me for whatever silly n00b mistakes I might have still
> missed, in spite of trying hard to do all my homework properly... :)
>
> The series consists of three patches:
>
>   1/3 - probes for the qemu fw_cfg device in locations known to work on
> 	the supported architectures, in decreasing order of "likelihood".
>
> 	While it *may* be possible to detect the presence of fw_cfg via
> 	acpi or dtb (on x86 and arm, respectively), there's no way I know
> 	of attempting that on sun4 and ppc/mac, so I've stuck with simply
> 	probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
> 	in fw_cfg.c. I could use some advice on how else that could be
> 	done more elegantly, if needed.
>

Sorry, but this is really out of the question, at least on ARM, but surely on
other architectures as well. You can't just go around and probe random memory
addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
system, this will immediately blow up. Also, what happens if the QEMU memory
map changes? Add more probes addresses?

It is not /that/ difficult to simply wire it up to the DT and ACPI
infrastructures, there are plenty of examples in the kernel tree how to
accomplish that. As a bonus, it removes all the arch specific knowledge
from your code, which means that if QEMU grows support for another DT or
ACPI based architecture, it will just work.

I am not sure how relevant sun4 and ppc/mac are for what you are trying to
accomplish, but perhaps it would be best to focus on x86 and ARM for now
and do it correctly. If the probing is actually needed, you can always add
it later.

-- 
Ard.

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

[toc] | [prev] | [next] | [standalone]

#1209751

(missed some cc's)

On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> From: "Gabriel L. Somlo" <somlo@cmu.edu>
>
> Hi Gabriel,
>
>> Several different architectures supported by QEMU are set up with a
>> "firmware configuration" (fw_cfg) device, used to pass configuration
>> "blobs" into the guest by the host running QEMU.
>>
>> Historically, these config blobs were mostly of interest to the guest
>> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> the command line, which makes them potentially interesting to userspace
>> (e.g. for passing early boot environment variables, etc.).
>>
>
> Does 'potentially interesting' mean you have a use case? Could you elaborate?
>
>> In addition to cc-ing the people and lists indicated by get-maintainer.pl,
>> I've added a few extra lists suggested by Matt Fleming on the qemu-devel
>> list, as well as the qemu-devel list itself.
>>
>> Also cc-ing kernelnewbies, as this is my very first kenel contribution,
>> so please go easy on me for whatever silly n00b mistakes I might have still
>> missed, in spite of trying hard to do all my homework properly... :)
>>
>> The series consists of three patches:
>>
>>   1/3 - probes for the qemu fw_cfg device in locations known to work on
>>       the supported architectures, in decreasing order of "likelihood".
>>
>>       While it *may* be possible to detect the presence of fw_cfg via
>>       acpi or dtb (on x86 and arm, respectively), there's no way I know
>>       of attempting that on sun4 and ppc/mac, so I've stuck with simply
>>       probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
>>       in fw_cfg.c. I could use some advice on how else that could be
>>       done more elegantly, if needed.
>>
>
> Sorry, but this is really out of the question, at least on ARM, but surely on
> other architectures as well. You can't just go around and probe random memory
> addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
> system, this will immediately blow up. Also, what happens if the QEMU memory
> map changes? Add more probes addresses?
>
> It is not /that/ difficult to simply wire it up to the DT and ACPI
> infrastructures, there are plenty of examples in the kernel tree how to
> accomplish that. As a bonus, it removes all the arch specific knowledge
> from your code, which means that if QEMU grows support for another DT or
> ACPI based architecture, it will just work.
>
> I am not sure how relevant sun4 and ppc/mac are for what you are trying to
> accomplish, but perhaps it would be best to focus on x86 and ARM for now
> and do it correctly. If the probing is actually needed, you can always add
> it later.
>
> --
> Ard.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210021

Hi Ard,

On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
> (missed some cc's)
> 
> On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > From: "Gabriel L. Somlo" <somlo@cmu.edu>
> >> Several different architectures supported by QEMU are set up with a
> >> "firmware configuration" (fw_cfg) device, used to pass configuration
> >> "blobs" into the guest by the host running QEMU.
> >>
> >> Historically, these config blobs were mostly of interest to the guest
> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> >> the command line, which makes them potentially interesting to userspace
> >> (e.g. for passing early boot environment variables, etc.).
> >>
> >
> > Does 'potentially interesting' mean you have a use case? Could you elaborate?

My personal one would be something like:

cat > guestinfo.txt << EOT
  KEY1="val1"
  KEY2="val2"
  ...
EOT

qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...

Then, from inside the guest:

  . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw

  do_something_with $KEY1 $KEY2
  ...

But I'm thinking this is only one of the many positive things one
could do with the ability to access random host-supplied blobs from
guest userspace :)

> >>   1/3 - probes for the qemu fw_cfg device in locations known to work on
> >>       the supported architectures, in decreasing order of "likelihood".
> >>
> >>       While it *may* be possible to detect the presence of fw_cfg via
> >>       acpi or dtb (on x86 and arm, respectively), there's no way I know
> >>       of attempting that on sun4 and ppc/mac, so I've stuck with simply
> >>       probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
> >>       in fw_cfg.c. I could use some advice on how else that could be
> >>       done more elegantly, if needed.
> >>
> >
> > Sorry, but this is really out of the question, at least on ARM, but surely on
> > other architectures as well. You can't just go around and probe random memory
> > addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
> > system, this will immediately blow up. Also, what happens if the QEMU memory
> > map changes? Add more probes addresses?
> >
> > It is not /that/ difficult to simply wire it up to the DT and ACPI
> > infrastructures, there are plenty of examples in the kernel tree how to
> > accomplish that. As a bonus, it removes all the arch specific knowledge
> > from your code, which means that if QEMU grows support for another DT or
> > ACPI based architecture, it will just work.

I was *hoping* a successful call to request_[mem_]region() will be
enough in the way of asking for permission before probing for the
fw_cfg registers, but I realize that might still not be polite enough :)

DT on ARM is fine, and I'm certainly happy to learn how to do it (even
though my main focus is, for now, x86). The unfortunate thing though
is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
first adding it in on the host side, before I can rewrite the guest side
driver to look it up in there :)

> > I am not sure how relevant sun4 and ppc/mac are for what you are trying to
> > accomplish, but perhaps it would be best to focus on x86 and ARM for now
> > and do it correctly. If the probing is actually needed, you can always add
> > it later.

I guess that's the direction things seem to be headed, although it would
make me a bit sad to leave out sun and ppc right from the very beginning :) 


Thanks,
--Gabriel

PS. If you have one .c file in the kernel which does any of the DT-on-arm
boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)

PS2. Do you happen to be in Seattle right now ? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210069

On Wed, Aug 19, 2015 at 04:49:15PM -0400, Gabriel L. Somlo wrote:
> Hi Ard,
> 
> On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
> > (missed some cc's)
> > 
> > On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > From: "Gabriel L. Somlo" <somlo@cmu.edu>
> > >> Several different architectures supported by QEMU are set up with a
> > >> "firmware configuration" (fw_cfg) device, used to pass configuration
> > >> "blobs" into the guest by the host running QEMU.
> > >>
> > >> Historically, these config blobs were mostly of interest to the guest
> > >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> > >> the command line, which makes them potentially interesting to userspace
> > >> (e.g. for passing early boot environment variables, etc.).
> > >>
> > >
> > > Does 'potentially interesting' mean you have a use case? Could you elaborate?
> 
> My personal one would be something like:
> 
> cat > guestinfo.txt << EOT
>   KEY1="val1"
>   KEY2="val2"
>   ...
> EOT
> 
> qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
> 
> Then, from inside the guest:
> 
>   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
> 
>   do_something_with $KEY1 $KEY2
>   ...
> 
> But I'm thinking this is only one of the many positive things one
> could do with the ability to access random host-supplied blobs from
> guest userspace :)

> > >>   1/3 - probes for the qemu fw_cfg device in locations known to work on
> > >>       the supported architectures, in decreasing order of "likelihood".
> > >>
> > >>       While it *may* be possible to detect the presence of fw_cfg via
> > >>       acpi or dtb (on x86 and arm, respectively), there's no way I know
> > >>       of attempting that on sun4 and ppc/mac, so I've stuck with simply
> > >>       probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
> > >>       in fw_cfg.c. I could use some advice on how else that could be
> > >>       done more elegantly, if needed.
> > >>
> > >
> > > Sorry, but this is really out of the question, at least on ARM, but surely on
> > > other architectures as well. You can't just go around and probe random memory
> > > addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
> > > system, this will immediately blow up. Also, what happens if the QEMU memory
> > > map changes? Add more probes addresses?
> > >
> > > It is not /that/ difficult to simply wire it up to the DT and ACPI
> > > infrastructures, there are plenty of examples in the kernel tree how to
> > > accomplish that. As a bonus, it removes all the arch specific knowledge
> > > from your code, which means that if QEMU grows support for another DT or
> > > ACPI based architecture, it will just work.
> 
> I was *hoping* a successful call to request_[mem_]region() will be
> enough in the way of asking for permission before probing for the
> fw_cfg registers, but I realize that might still not be polite enough :)

Either way, it would make sense to not probe in locations that
couldn't possibly work on the current platform. The cleanest way would
probably be a per-architecture probe function (or structure). But even
then, it needs to only probe when it is safe to do so.
 
> DT on ARM is fine, and I'm certainly happy to learn how to do it (even
> though my main focus is, for now, x86). The unfortunate thing though
> is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
> first adding it in on the host side, before I can rewrite the guest side
> driver to look it up in there :)

It is probaly the only non-hackish way to do it for arm*.

> > > I am not sure how relevant sun4 and ppc/mac are for what you are trying to
> > > accomplish, but perhaps it would be best to focus on x86 and ARM for now
> > > and do it correctly. If the probing is actually needed, you can always add
> > > it later.
> 
> I guess that's the direction things seem to be headed, although it would
> make me a bit sad to leave out sun and ppc right from the very beginning :) 
> 
> PS. If you have one .c file in the kernel which does any of the DT-on-arm
> boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
> 
> PS2. Do you happen to be in Seattle right now ? :)

Unfortunately, neither Ard nor myself is there. But Mark Rutland
should be around and someone useful to talk to about this.

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

[toc] | [prev] | [next] | [standalone]

#1210150

On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@cmu.edu> wrote:
> Hi Ard,
>
> On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
>> (missed some cc's)
>>
>> On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > From: "Gabriel L. Somlo" <somlo@cmu.edu>
>> >> Several different architectures supported by QEMU are set up with a
>> >> "firmware configuration" (fw_cfg) device, used to pass configuration
>> >> "blobs" into the guest by the host running QEMU.
>> >>
>> >> Historically, these config blobs were mostly of interest to the guest
>> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> >> the command line, which makes them potentially interesting to userspace
>> >> (e.g. for passing early boot environment variables, etc.).
>> >>
>> >
>> > Does 'potentially interesting' mean you have a use case? Could you elaborate?
>
> My personal one would be something like:
>
> cat > guestinfo.txt << EOT
>   KEY1="val1"
>   KEY2="val2"
>   ...
> EOT
>
> qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
>
> Then, from inside the guest:
>
>   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
>
>   do_something_with $KEY1 $KEY2
>   ...
>
> But I'm thinking this is only one of the many positive things one
> could do with the ability to access random host-supplied blobs from
> guest userspace :)
>

'random host-supplied blobs' sounds awfully like files in a file
system to me, and that is already supported by QEMU and works with any
guest OS unmodified. If you are in control of the command line, surely
you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
simply turns up as a volume.

>> >>   1/3 - probes for the qemu fw_cfg device in locations known to work on
>> >>       the supported architectures, in decreasing order of "likelihood".
>> >>
>> >>       While it *may* be possible to detect the presence of fw_cfg via
>> >>       acpi or dtb (on x86 and arm, respectively), there's no way I know
>> >>       of attempting that on sun4 and ppc/mac, so I've stuck with simply
>> >>       probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function)
>> >>       in fw_cfg.c. I could use some advice on how else that could be
>> >>       done more elegantly, if needed.
>> >>
>> >
>> > Sorry, but this is really out of the question, at least on ARM, but surely on
>> > other architectures as well. You can't just go around and probe random memory
>> > addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
>> > system, this will immediately blow up. Also, what happens if the QEMU memory
>> > map changes? Add more probes addresses?
>> >
>> > It is not /that/ difficult to simply wire it up to the DT and ACPI
>> > infrastructures, there are plenty of examples in the kernel tree how to
>> > accomplish that. As a bonus, it removes all the arch specific knowledge
>> > from your code, which means that if QEMU grows support for another DT or
>> > ACPI based architecture, it will just work.
>
> I was *hoping* a successful call to request_[mem_]region() will be
> enough in the way of asking for permission before probing for the
> fw_cfg registers, but I realize that might still not be polite enough :)
>

No, all request_mem_region() does is check whether the region in
question is not occupied yet by another driver. So your probing could
access unpopulated memory space, or MMIO space owned by a peripheral
whose driver is not loaded. Neither are allowable, I'm afraid.

> DT on ARM is fine, and I'm certainly happy to learn how to do it (even
> though my main focus is, for now, x86). The unfortunate thing though
> is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
> first adding it in on the host side, before I can rewrite the guest side
> driver to look it up in there :)
>
>> > I am not sure how relevant sun4 and ppc/mac are for what you are trying to
>> > accomplish, but perhaps it would be best to focus on x86 and ARM for now
>> > and do it correctly. If the probing is actually needed, you can always add
>> > it later.
>
> I guess that's the direction things seem to be headed, although it would
> make me a bit sad to leave out sun and ppc right from the very beginning :)
>

Sorry to be blunt, but I am not convinced there is a need for this
driver anyway.

> PS. If you have one .c file in the kernel which does any of the DT-on-arm
> boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
>

Check out drivers/tty/serial/amba-pl011.c

> PS2. Do you happen to be in Seattle right now ? :)

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

[toc] | [prev] | [next] | [standalone]

#1210845

On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
> On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@cmu.edu> wrote:
> >> > From: "Gabriel L. Somlo" <somlo@cmu.edu>
> >> >> Several different architectures supported by QEMU are set up with a
> >> >> "firmware configuration" (fw_cfg) device, used to pass configuration
> >> >> "blobs" into the guest by the host running QEMU.
> >> >>
> >> >> Historically, these config blobs were mostly of interest to the guest
> >> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> >> >> the command line, which makes them potentially interesting to userspace
> >> >> (e.g. for passing early boot environment variables, etc.).
> >> >>
> >> >
> >> > Does 'potentially interesting' mean you have a use case? Could you elaborate?
> >
> > My personal one would be something like:
> >
> > cat > guestinfo.txt << EOT
> >   KEY1="val1"
> >   KEY2="val2"
> >   ...
> > EOT
> >
> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
> >
> > Then, from inside the guest:
> >
> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
> >
> >   do_something_with $KEY1 $KEY2
> >   ...
> >
> > But I'm thinking this is only one of the many positive things one
> > could do with the ability to access random host-supplied blobs from
> > guest userspace :)
> >
> 
> 'random host-supplied blobs' sounds awfully like files in a file
> system to me, and that is already supported by QEMU and works with any
> guest OS unmodified. If you are in control of the command line, surely
> you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
> simply turns up as a volume.

That did come up, here's the start of original thread on the qemu mailing
list from a while back:

https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html

To recap, the main advantages to transfering data this way are:

	1. Asynchronous

	   The host can simply pass data via the qemu command line, and
	   not have to care if/when the guest is ready to accept the
	   data (i.e. has made it far enough to e.g. start a guest agent)

	2. Out-of-band

	   I don't have to take over a user-visible element such as a
	   disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
	   exist and are NOT actual Ethernet/TCP-IP network interfaces :)

> > DT on ARM is fine, and I'm certainly happy to learn how to do it (even
> > though my main focus is, for now, x86). The unfortunate thing though
> > is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
> > first adding it in on the host side, before I can rewrite the guest side
> > driver to look it up in there :)
> >
> >> > I am not sure how relevant sun4 and ppc/mac are for what you are trying to
> >> > accomplish, but perhaps it would be best to focus on x86 and ARM for now
> >> > and do it correctly. If the probing is actually needed, you can always add
> >> > it later.
> >
> > I guess that's the direction things seem to be headed, although it would
> > make me a bit sad to leave out sun and ppc right from the very beginning :)
> >
> 
> Sorry to be blunt, but I am not convinced there is a need for this
> driver anyway.

See above (hopefully I'm being sufficiently persuasive :) )

In VMWare one would fetch similar "guestinfo" variables via something like

	FOO=$(vmware-tools --getinfo "FOO")

but I thought exposing fw_cfg in /sys/firmware/... would make access to
*any* blobs (including, but not limited to my particular use case) even
easier and more generic than that.

> > PS. If you have one .c file in the kernel which does any of the DT-on-arm
> > boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
> >
> 
> Check out drivers/tty/serial/amba-pl011.c

I'll check it out.

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

[toc] | [prev] | [next] | [standalone]

#1211878

On 21 August 2015 at 05:47, Gabriel L. Somlo <somlo@cmu.edu> wrote:
> On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
>> On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@cmu.edu> wrote:
>> >> > From: "Gabriel L. Somlo" <somlo@cmu.edu>
>> >> >> Several different architectures supported by QEMU are set up with a
>> >> >> "firmware configuration" (fw_cfg) device, used to pass configuration
>> >> >> "blobs" into the guest by the host running QEMU.
>> >> >>
>> >> >> Historically, these config blobs were mostly of interest to the guest
>> >> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> >> >> the command line, which makes them potentially interesting to userspace
>> >> >> (e.g. for passing early boot environment variables, etc.).
>> >> >>
>> >> >
>> >> > Does 'potentially interesting' mean you have a use case? Could you elaborate?
>> >
>> > My personal one would be something like:
>> >
>> > cat > guestinfo.txt << EOT
>> >   KEY1="val1"
>> >   KEY2="val2"
>> >   ...
>> > EOT
>> >
>> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
>> >
>> > Then, from inside the guest:
>> >
>> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
>> >
>> >   do_something_with $KEY1 $KEY2
>> >   ...
>> >
>> > But I'm thinking this is only one of the many positive things one
>> > could do with the ability to access random host-supplied blobs from
>> > guest userspace :)
>> >
>>
>> 'random host-supplied blobs' sounds awfully like files in a file
>> system to me, and that is already supported by QEMU and works with any
>> guest OS unmodified. If you are in control of the command line, surely
>> you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
>> simply turns up as a volume.
>
> That did come up, here's the start of original thread on the qemu mailing
> list from a while back:
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html
>
> To recap, the main advantages to transfering data this way are:
>
>         1. Asynchronous
>
>            The host can simply pass data via the qemu command line, and
>            not have to care if/when the guest is ready to accept the
>            data (i.e. has made it far enough to e.g. start a guest agent)
>

How does that not apply to a file system?

>         2. Out-of-band
>
>            I don't have to take over a user-visible element such as a
>            disk drive. Same reason VSOCK (or VMWare VMCI for that matter)
>            exist and are NOT actual Ethernet/TCP-IP network interfaces :)
>

OK that makes sense. Note that I am not the one you need to convince
that this is a good idea, but I would still like to understand better
why your use case requires this. Could you explain?

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

[toc] | [prev] | [next] | [standalone]

#1214093

Hi Gabriel,

On 08/19/2015 04:49 PM, Gabriel L. Somlo wrote:
> Hi Ard,
> 
> On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
>> (missed some cc's)
>>
>> On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> From: "Gabriel L. Somlo" <somlo@cmu.edu>
>>>> Several different architectures supported by QEMU are set up with a
>>>> "firmware configuration" (fw_cfg) device, used to pass configuration
>>>> "blobs" into the guest by the host running QEMU.
>>>>
>>>> Historically, these config blobs were mostly of interest to the guest
>>>> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>>>> the command line, which makes them potentially interesting to userspace
>>>> (e.g. for passing early boot environment variables, etc.).
>>>>
>>>
>>> Does 'potentially interesting' mean you have a use case? Could you elaborate?
> 
> My personal one would be something like:
> 
> cat > guestinfo.txt << EOT
>   KEY1="val1"
>   KEY2="val2"
>   ...
> EOT
> 
> qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
> 
> Then, from inside the guest:
> 
>   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
> 
>   do_something_with $KEY1 $KEY2
>   ...
> 
> But I'm thinking this is only one of the many positive things one
> could do with the ability to access random host-supplied blobs from
> guest userspace :)

I do this with kernel parameters:

host:
qemu-system-aarch64 -append="KEY1=val1 KEY2=val2"

guest:
KEY1=`sed -nr s/.*KEY1=([^ ]+).*/\1/ /proc/cmdline`
KEY2=`sed -nr s/.*KEY2=([^ ]+).*/\1/ /proc/cmdline`

do_something_with $KEY1 $KEY2

In practice it's just script=hostfile, where hostfile is available to the
guest via a 9P passthrough filesystem mount.

While quite architecture specific, I've also previously used an
"angel-cmdline" tool for similar purposes. Peter's recent semihosting patches
support such a tool for AArch64. (On AArch32 upstream QEMU disallows
semihosting from userspace.)

Before I had 9P on all the simulators I regularly ran, I used a semihosting
based "angel-load" tool.

Regards,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1216948

Hi Christopher,

On Wed, Aug 26, 2015 at 02:15:03PM -0400, Christopher Covington wrote:
> On 08/19/2015 04:49 PM, Gabriel L. Somlo wrote:
> > On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
> >> On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>> From: "Gabriel L. Somlo" <somlo@cmu.edu>
> >>>> Several different architectures supported by QEMU are set up with a
> >>>> "firmware configuration" (fw_cfg) device, used to pass configuration
> >>>> "blobs" into the guest by the host running QEMU.
> >>>>
> >>>> Historically, these config blobs were mostly of interest to the guest
> >>>> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
> >>>> the command line, which makes them potentially interesting to userspace
> >>>> (e.g. for passing early boot environment variables, etc.).
> >>>>
> >>>
> >>> Does 'potentially interesting' mean you have a use case? Could you elaborate?
> > 
> > My personal one would be something like:
> > 
> > cat > guestinfo.txt << EOT
> >   KEY1="val1"
> >   KEY2="val2"
> >   ...
> > EOT
> > 
> > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
> > 
> > Then, from inside the guest:
> > 
> >   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
> > 
> >   do_something_with $KEY1 $KEY2
> >   ...
> > 
> > But I'm thinking this is only one of the many positive things one
> > could do with the ability to access random host-supplied blobs from
> > guest userspace :)
> 
> I do this with kernel parameters:
> 
> host:
> qemu-system-aarch64 -append="KEY1=val1 KEY2=val2"
> 
> guest:
> KEY1=`sed -nr s/.*KEY1=([^ ]+).*/\1/ /proc/cmdline`
> KEY2=`sed -nr s/.*KEY2=([^ ]+).*/\1/ /proc/cmdline`
> 
> do_something_with $KEY1 $KEY2
> 
> In practice it's just script=hostfile, where hostfile is available to the
> guest via a 9P passthrough filesystem mount.
> 
> While quite architecture specific, I've also previously used an
> "angel-cmdline" tool for similar purposes. Peter's recent semihosting patches
> support such a tool for AArch64. (On AArch32 upstream QEMU disallows
> semihosting from userspace.)
> 
> Before I had 9P on all the simulators I regularly ran, I used a semihosting
> based "angel-load" tool.

Someone (maybe it was you) did suggest this during an early thread on
the QEMU dev list. I had considered this, then thought about
piggybacking on smbios (e.g. the type 40 "additional information"
table), but then realized "wait, smbios is currently being inserted
into the guest via fw_cfg, so maybe direct fw_cfg blob transfer *is*
the most asynchronous and out-of-band way I can do this... :)

True, writing a fw_cfg driver is still Linux-specific (leaves out
Windows, which is something I still care about), but dumping a fw_cfg
blob using 'cat' or 'cp' on linux has a certain appeal :)

Yeah, the immediate use case I have personally can be worked around
with kernel command line args, in a slightly less out-of-band, but
still quite serviceable way. I'm thinking a fw_cfg driver is just a
flexible way to make other use cases possible in a (IMHO) neat and
clean way...

Plus, it got me to learn about kobjects, now studying DTs on ARM, so
it's fun ;)

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web