Re: [Qemu-devel] [PATCH v8 0/4] SysFS driver for QEMU fw_cfg device

[Greg KH]

On Wed, Feb 03, 2016 at 10:47:29PM +, Matt Fleming wrote:
> On Thu, 28 Jan, at 09:23:10AM, Gabriel L. Somlo wrote:
> > From: "Gabriel Somlo" 
> > 
> > Allow access to QEMU firmware blobs, passed into the guest VM via
> > the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
> > size, and fw_cfg key), as well as the raw binary blob data may be
> > accessed.
> > 
> > The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
> > selected based on overall similarity to the type of information
> > exposed under /sys/firmware/dmi/entries/...
> > 
> > This functionality is primarily intended to serve as a host->guest
> > configuration data transfer mechanism that is both:
> > 
> > - asynchronous: the host doesn't need to wait for the guest
> > to be ready to accept data (e.g., by starting
> > an agent daemon)
> > 
> > - out-of-band:  there is no need to commandeer a guest element
> > normally visible and available to the guest user
> > (e.g., kernel cmdline, mounting floppy/cdrom, etc.)
> > 
> > QEMU now allows arbitrary fw_cfg blobs to be added via the command line,
> > so it would be nice to make them easy to retrieve from within the guest
> > OS, and the niceset and easiest way I can think of is
> > 
> > cat /sys/firmware/qemu-fw-cfg/...//raw
> > 
> > New since v7:
> > 
> > - kbuild testbot complained about a warning on ia64, so limit
> >   the availability of fw_cfg in Kconfig to only architectures
> >   on which QEMU makes it available, which include:
> > 
> > (ARM || ARM64 || PPC_PMAC || SPARC || X86)
> 
> This is looking pretty good now. Does anyone have remaining
> objections before this gets merged?

All now merged in my tree, thanks.

greg k-h

Re: [Qemu-devel] [PATCH v8 0/4] SysFS driver for QEMU fw_cfg device

[Matt Fleming]

On Thu, 28 Jan, at 09:23:10AM, Gabriel L. Somlo wrote:
> From: "Gabriel Somlo" 
> 
> Allow access to QEMU firmware blobs, passed into the guest VM via
> the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
> size, and fw_cfg key), as well as the raw binary blob data may be
> accessed.
> 
> The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
> selected based on overall similarity to the type of information
> exposed under /sys/firmware/dmi/entries/...
> 
> This functionality is primarily intended to serve as a host->guest
> configuration data transfer mechanism that is both:
> 
> - asynchronous: the host doesn't need to wait for the guest
> to be ready to accept data (e.g., by starting
> an agent daemon)
> 
> - out-of-band:  there is no need to commandeer a guest element
> normally visible and available to the guest user
> (e.g., kernel cmdline, mounting floppy/cdrom, etc.)
> 
> QEMU now allows arbitrary fw_cfg blobs to be added via the command line,
> so it would be nice to make them easy to retrieve from within the guest
> OS, and the niceset and easiest way I can think of is
> 
> cat /sys/firmware/qemu-fw-cfg/...//raw
> 
> New since v7:
> 
>   - kbuild testbot complained about a warning on ia64, so limit
> the availability of fw_cfg in Kconfig to only architectures
> on which QEMU makes it available, which include:
> 
>   (ARM || ARM64 || PPC_PMAC || SPARC || X86)

This is looking pretty good now. Does anyone have remaining
objections before this gets merged?

[Qemu-devel] [PATCH v8 0/4] SysFS driver for QEMU fw_cfg device

[Gabriel L. Somlo]

From: "Gabriel Somlo" 

Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.

The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on overall similarity to the type of information
exposed under /sys/firmware/dmi/entries/...

This functionality is primarily intended to serve as a host->guest
configuration data transfer mechanism that is both:

- asynchronous: the host doesn't need to wait for the guest
to be ready to accept data (e.g., by starting
an agent daemon)

- out-of-band:  there is no need to commandeer a guest element
normally visible and available to the guest user
(e.g., kernel cmdline, mounting floppy/cdrom, etc.)

QEMU now allows arbitrary fw_cfg blobs to be added via the command line,
so it would be nice to make them easy to retrieve from within the guest
OS, and the niceset and easiest way I can think of is

cat /sys/firmware/qemu-fw-cfg/...//raw

New since v7:

- kbuild testbot complained about a warning on ia64, so limit
  the availability of fw_cfg in Kconfig to only architectures
  on which QEMU makes it available, which include:

(ARM || ARM64 || PPC_PMAC || SPARC || X86)

Thanks,
  --Gabriel

>New since v6:
>
>   - added architecture-specific default values for fw_cfg register
> offsets: DT and/or ACPI will only give us the base address and
> total size of the fw_cfg register set, but not individual register
> offsets *within* this total extent. The specific offsets are
> different across architectures, and this version adds #defines
> so that reasonable defaults can be used on each supported platform.
>
>>New since v5:
>>
>>  - fixed typos in documentation files (Patches 1/4 and 4/4
>>
>>  - printf/scanf type modifier for phys_addr_t now matches
>>arch-specific width (u32 vs. u64), avoiding compiler warnings.
>>(tested on i386 with and without PAE, and on armv7hl with and
>> without lpae -- the latter pair took quite a while on an
>> emulated QEMU guest :) )
>>
>>>New since v4:
>>>
>>> Documentation (Patches 1/4 and 4/4) now points to the authoritative
>>> file in the QEMU source tree for any details related to the "hardware
>>> interface" of the fw_cfg device; Only details specific to sysfs (1/4) 
>>> and DT (4/4) should stay in the kernel docs.
>>>
New (since v3):

Patch 1/4: Device probing now works with either ACPI, DT, or
   optionally by manually specifying a base, size, and
   register offsets on the command line. This way, all
   architectures offering fw_cfg can be supported, although
   x86 and ARM get *automatic* support via ACPI and/or DT.

   HUGE thanks to Laszlo Ersek  for
   pointing out drivers/virtio/virtio_mmio.c, as an example
   on how to pull this off !!!

   Stefan: I saw Marc's DMA patches to fw_cfg. Since only
   x86 and ARM will support it starting with QEMU 2.5, and
   since I expect to get lots of otherwise interesting (but
   otherwise orthogonal) feedback on this series, I'd like
   to stick with ioread8() across the board for now. We can
   always patch in DMA support in a backward compatible way
   later, once this series gets (hopefully) accepted :)

Patch 2/4: (was 3/4 in v3): unchanged. Exports kset_find_obj() so
   modules can call it.

Patch 3/4: (was 4/4 in v3): rebased, but otherwise the same.
   Essentially, creates a "human readable" directory
   hierarchy from "path-like" tokens making up fw_cfg
   blob names. I'm not really sure there's a way to make
   this happen via udev rules, but I have at least one
   potential use case for doing it *before* udev becomes
   available (cc: Andy Lutomirski ),
   so I'd be happy to leave this functionality in the
   kernel module. See further below for an illustration
   of this.

Patch 4/4: Updates the existing ARM DT documentation for fw_cfg,
   mainly by pointing at the more comprehensive document
   introduced with Patch 1/4 for details on the fw_cfg
   device interface, leaving only the specific ARM/DT
   address/size node information in place.

>  In addition to the "by_key" blob listing, e.g.:
>