[Qemu-devel] [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
From: Gabriel Somlo so...@cmu.edu Make fw_cfg entries of type file available via sysfs. Entries are listed under /sys/firmware/fw_cfg/by_select, in folders named after each entry's selector key. Filename, selector value, and size read-only attributes are included for each entry. Also, a raw attribute allows retrieval of the full binary content of each entry. This patch also provides a documentation file outlining the guest-side hardware interface exposed by the QEMU fw_cfg device. Signed-off-by: Gabriel Somlo so...@cmu.edu --- Documentation/ABI/testing/sysfs-firmware-fw_cfg | 169 + drivers/firmware/Kconfig| 10 + drivers/firmware/Makefile | 1 + drivers/firmware/fw_cfg.c | 438 4 files changed, 618 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-fw_cfg create mode 100644 drivers/firmware/fw_cfg.c diff --git a/Documentation/ABI/testing/sysfs-firmware-fw_cfg b/Documentation/ABI/testing/sysfs-firmware-fw_cfg new file mode 100644 index 000..3a7e7f2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-fw_cfg @@ -0,0 +1,169 @@ +What: /sys/firmware/fw_cfg/ +Date: August 2015 +Contact: Gabriel Somlo so...@cmu.edu +Description: + Several different architectures supported by QEMU (x86, arm, + sun4*, ppc/mac) are provisioned with a firmware configuration + (fw_cfg) device, used by the host to provide configuration data + to the starting guest. While most of this data is meant for use + by the guest BIOS, starting with QEMU v2.4, guest VMs may be + started with arbitrary fw_cfg entries supplied directly on the + command line, which therefore may be of interest to userspace. + + === Guest-side Hardware Interface === + + The fw_cfg device is available to guest VMs as a pair (control + and data) of registers, accessible as either a IO ports or as + MMIO addresses, depending on the architecture. + + --- Control Register --- + + Width: 16-bit + Access: Write-Only + Endianness: LE (if IOport) or BE (if MMIO) + + A write to the control register selects the index for one of + the firmware configuration items (or blobs) available on the + fw_cfg device, which can subsequently be read from the data + register. + + Each time the control register is written, an data offset + internal to the fw_cfg device will be set to zero. This data + offset impacts which portion of the selected fw_cfg blob is + accessed by reading the data register, as explained below. + + --- Data Register --- + + Width: 8-bit (if IOport), or 8/16/32/64-bit (if MMIO) + Access: Read-Only + Endianness: string preserving + + The data register allows access to an array of bytes which + represent the fw_cfg blob last selected by a write to the + control register. + + Immediately following a write to the control register, the data + offset will be set to zero. Each successful read access to the + data register will increment the data offset by the appropriate + access width. + + Each fw_cfg blob has a maximum associated data length. Once the + data offset exceeds this maximum length, any subsequent reads + via the data register will return 0x00. + + An N-byte wide read of the data register will return the next + available N bytes of the selected fw_cfg blob, as a substring, + in increasing address order, similar to memcpy(), zero-padded + if necessary should the maximum data length of the selected + item be reached, as described above. + + --- Per-arch Register Details --- + + - + archaccess base ctrlctrldatadata + modeaddress offset endian offset width + max. + - + x86 IOport0x510 0 LE 18 + x86_64 IOport0x510 0 LE 18 + arm MMIO 0x902 8 BE 0 64 + sun4u IOport0x510 0 LE 18 + sun4m MMIO0xd0510 0 BE 28 + ppc/mac MMIO 0xf510 0 BE 28 +
Re: [Qemu-devel] [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Mon, Aug 10, 2015 at 12:31:18PM -0400, Gabriel L. Somlo wrote: From: Gabriel Somlo so...@cmu.edu Make fw_cfg entries of type file available via sysfs. Entries are listed under /sys/firmware/fw_cfg/by_select, in folders named after each entry's selector key. Filename, selector value, and size read-only attributes are included for each entry. Also, a raw attribute allows retrieval of the full binary content of each entry. This patch also provides a documentation file outlining the guest-side hardware interface exposed by the QEMU fw_cfg device. Signed-off-by: Gabriel Somlo so...@cmu.edu --- Documentation/ABI/testing/sysfs-firmware-fw_cfg | 169 + drivers/firmware/Kconfig| 10 + drivers/firmware/Makefile | 1 + drivers/firmware/fw_cfg.c | 438 4 files changed, 618 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-fw_cfg create mode 100644 drivers/firmware/fw_cfg.c diff --git a/Documentation/ABI/testing/sysfs-firmware-fw_cfg b/Documentation/ABI/testing/sysfs-firmware-fw_cfg new file mode 100644 index 000..3a7e7f2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-fw_cfg @@ -0,0 +1,169 @@ +What:/sys/firmware/fw_cfg/ /sys/firmware/qemu_fw/ ? fw_cfg is very vague and not descriptive at all. +Date:August 2015 +Contact: Gabriel Somlo so...@cmu.edu +Description: + Several different architectures supported by QEMU (x86, arm, + sun4*, ppc/mac) are provisioned with a firmware configuration + (fw_cfg) device, used by the host to provide configuration data + to the starting guest. While most of this data is meant for use + by the guest BIOS, starting with QEMU v2.4, guest VMs may be + started with arbitrary fw_cfg entries supplied directly on the + command line, which therefore may be of interest to userspace. + + === Guest-side Hardware Interface === + + The fw_cfg device is available to guest VMs as a pair (control + and data) of registers, accessible as either a IO ports or as + MMIO addresses, depending on the architecture. + + --- Control Register --- + + Width: 16-bit + Access: Write-Only + Endianness: LE (if IOport) or BE (if MMIO) + + A write to the control register selects the index for one of + the firmware configuration items (or blobs) available on the + fw_cfg device, which can subsequently be read from the data + register. + + Each time the control register is written, an data offset + internal to the fw_cfg device will be set to zero. This data + offset impacts which portion of the selected fw_cfg blob is + accessed by reading the data register, as explained below. + + --- Data Register --- + + Width: 8-bit (if IOport), or 8/16/32/64-bit (if MMIO) + Access: Read-Only + Endianness: string preserving + + The data register allows access to an array of bytes which + represent the fw_cfg blob last selected by a write to the + control register. + + Immediately following a write to the control register, the data + offset will be set to zero. Each successful read access to the + data register will increment the data offset by the appropriate + access width. + + Each fw_cfg blob has a maximum associated data length. Once the + data offset exceeds this maximum length, any subsequent reads + via the data register will return 0x00. + + An N-byte wide read of the data register will return the next + available N bytes of the selected fw_cfg blob, as a substring, + in increasing address order, similar to memcpy(), zero-padded + if necessary should the maximum data length of the selected + item be reached, as described above. + + --- Per-arch Register Details --- + + - + archaccess base ctrlctrldatadata + modeaddress offset endian offset width + max. + - + x86 IOport0x510 0 LE 18 + x86_64 IOport0x510 0 LE 18 + arm MMIO 0x902 8 BE 0 64 + sun4u IOport0x510 0 LE 18 +
Re: [Qemu-devel] [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Mon, Aug 10, 2015 at 11:30:54AM -0700, Greg KH wrote: On Mon, Aug 10, 2015 at 12:31:18PM -0400, Gabriel L. Somlo wrote: From: Gabriel Somlo so...@cmu.edu Make fw_cfg entries of type file available via sysfs. Entries are listed under /sys/firmware/fw_cfg/by_select, in folders named after each entry's selector key. Filename, selector value, and size read-only attributes are included for each entry. Also, a raw attribute allows retrieval of the full binary content of each entry. This patch also provides a documentation file outlining the guest-side hardware interface exposed by the QEMU fw_cfg device. Signed-off-by: Gabriel Somlo so...@cmu.edu --- Documentation/ABI/testing/sysfs-firmware-fw_cfg | 169 + drivers/firmware/Kconfig| 10 + drivers/firmware/Makefile | 1 + drivers/firmware/fw_cfg.c | 438 4 files changed, 618 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-fw_cfg create mode 100644 drivers/firmware/fw_cfg.c diff --git a/Documentation/ABI/testing/sysfs-firmware-fw_cfg b/Documentation/ABI/testing/sysfs-firmware-fw_cfg new file mode 100644 index 000..3a7e7f2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-fw_cfg @@ -0,0 +1,169 @@ +What: /sys/firmware/fw_cfg/ /sys/firmware/qemu_fw/ ? fw_cfg is very vague and not descriptive at all. How about /sys/firmware/qemu_fw_cfg/, then ? In the QEMU universe, fw_cfg is familiar. OTOH qemu_fw would not immediately ring a bell... +Date: August 2015 +Contact: Gabriel Somlo so...@cmu.edu +Description: + Several different architectures supported by QEMU (x86, arm, + sun4*, ppc/mac) are provisioned with a firmware configuration + (fw_cfg) device, used by the host to provide configuration data + to the starting guest. While most of this data is meant for use + by the guest BIOS, starting with QEMU v2.4, guest VMs may be + started with arbitrary fw_cfg entries supplied directly on the + command line, which therefore may be of interest to userspace. + + === Guest-side Hardware Interface === + + The fw_cfg device is available to guest VMs as a pair (control + and data) of registers, accessible as either a IO ports or as + MMIO addresses, depending on the architecture. + + --- Control Register --- + + Width: 16-bit + Access: Write-Only + Endianness: LE (if IOport) or BE (if MMIO) + + A write to the control register selects the index for one of + the firmware configuration items (or blobs) available on the + fw_cfg device, which can subsequently be read from the data + register. + + Each time the control register is written, an data offset + internal to the fw_cfg device will be set to zero. This data + offset impacts which portion of the selected fw_cfg blob is + accessed by reading the data register, as explained below. + + --- Data Register --- + + Width: 8-bit (if IOport), or 8/16/32/64-bit (if MMIO) + Access: Read-Only + Endianness: string preserving + + The data register allows access to an array of bytes which + represent the fw_cfg blob last selected by a write to the + control register. + + Immediately following a write to the control register, the data + offset will be set to zero. Each successful read access to the + data register will increment the data offset by the appropriate + access width. + + Each fw_cfg blob has a maximum associated data length. Once the + data offset exceeds this maximum length, any subsequent reads + via the data register will return 0x00. + + An N-byte wide read of the data register will return the next + available N bytes of the selected fw_cfg blob, as a substring, + in increasing address order, similar to memcpy(), zero-padded + if necessary should the maximum data length of the selected + item be reached, as described above. + + --- Per-arch Register Details --- + + - + archaccess base ctrlctrldatadata + modeaddress offset endian offset width + max. + - + x86 IOport0x510 0 LE 18 + x86_64 IOport
Re: [Qemu-devel] [PATCH 1/3] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote: Mainly, qemu's fw_cfg is a read-only device, so one wouldn't ever care to try writing anything to it. /sys/firmware/... feels like a fit because fw_cfg contains binary blobs originally meant to be used by the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of the host and set them up in guest memory before booting the guest kernel, as one of the many examples). The most similar example (and the existing driver I used as an example during implementation) is dmi-sysfs.c, which also exposes all the metadata for each smbios table as numeric (or string) read-only attributes, and has a raw attribute which allows dumping each table in its entirety. Same thing here -- I want to expose the name, size, and select key for each blob, but also allow access to the payload, i.e. the blob itself. That's great, and you can have these blobs be an attribute for a struct device. Just using a raw kobject as you are is hard, as you have seen, and messy. Making it a real device makes this all much easier and simpler. Now if you want to keep things in /sys/firmware/ that's another issue, and would have to stay as a kobject. so maybe it does need to remain, need to think about that... thanks, greg k-h
