Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1275507 > unrolled thread
| Started by | "Gabriel L. Somlo" <somlo@cmu.edu> |
|---|---|
| First post | 2015-11-23 17:00 +0100 |
| Last post | 2015-11-23 17:00 +0100 |
| Articles | 2 — 1 participant |
Back to article view | Back to linux.kernel
[PATCH v5 0/4] SysFS driver for QEMU fw_cfg device "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-11-23 17:00 +0100
[PATCH v5 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries "Gabriel L. Somlo" <somlo@cmu.edu> - 2015-11-23 17:00 +0100
| From | "Gabriel L. Somlo" <somlo@cmu.edu> |
|---|---|
| Date | 2015-11-23 17:00 +0100 |
| Subject | [PATCH v5 0/4] SysFS driver for QEMU fw_cfg device |
| Message-ID | <qy1H4-3Pv-5@gated-at.bofh.it> |
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/...
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.
Thanks,
--Gabriel
>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 <lersek@redhat.com> 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 <luto@amacapital.net>),
> 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.:
>>
>> $ tree /sys/firmware/qemu_fw_cfg/
>> /sys/firmware/qemu_fw_cfg/
>> |-- by_key
>> | |-- 32
>> | | |-- key
>> | | |-- name ("etc/boot-fail-wait")
>> | | |-- raw
>> | | `-- size
>> | |-- 33
>> | | |-- key
>> | | |-- name ("etc/smbios/smbios-tables")
>> | | |-- raw
>> | | `-- size
>> | |-- 34
>> | | |-- key
>> | | |-- name ("etc/smbios/smbios-anchor")
>> | | |-- raw
>> | | `-- size
>> | |-- 35
>> | | |-- key
>> | | |-- name ("etc/e820")
>> | | |-- raw
>> | | `-- size
>> | |-- 36
>> | | |-- key
>> | | |-- name ("genroms/kvmvapic.bin")
>> | | |-- raw
>> | | `-- size
>> | |-- 37
>> | | |-- key
>> | | |-- name ("etc/system-states")
>> | | |-- raw
>> | | `-- size
>> | |-- 38
>> | | |-- key
>> | | |-- name ("etc/acpi/tables")
>> | | |-- raw
>> | | `-- size
>> | |-- 39
>> | | |-- key
>> | | |-- name ("etc/table-loader")
>> | | |-- raw
>> | | `-- size
>> | |-- 40
>> | | |-- key
>> | | |-- name ("etc/tpm/log")
>> | | |-- raw
>> | | `-- size
>> | |-- 41
>> | | |-- key
>> | | |-- name ("etc/acpi/rsdp")
>> | | |-- raw
>> | | `-- size
>> | `-- 42
>> | |-- key
>> | |-- name ("bootorder")
>> | |-- raw
>> | `-- size
>> |
>> ...
>>
>> Patch 3/4 also gets us a "human readable" "by_name" listing, like so:
>>
>> ...
>> |-- by_name
>> | |-- bootorder -> ../by_key/42
>> | |-- etc
>> | | |-- acpi
>> | | | |-- rsdp -> ../../../by_key/41
>> | | | `-- tables -> ../../../by_key/38
>> | | |-- boot-fail-wait -> ../../by_key/32
>> | | |-- e820 -> ../../by_key/35
>> | | |-- smbios
>> | | | |-- smbios-anchor -> ../../../by_key/34
>> | | | `-- smbios-tables -> ../../../by_key/33
>> | | |-- system-states -> ../../by_key/37
>> | | |-- table-loader -> ../../by_key/39
>> | | `-- tpm
>> | | `-- log -> ../../../by_key/40
>> | `-- genroms
>> | `-- kvmvapic.bin -> ../../by_key/36
>> `-- rev
>
Gabriel Somlo (4):
firmware: introduce sysfs driver for QEMU's fw_cfg device
kobject: export kset_find_obj() for module use
firmware: create directory hierarchy for sysfs fw_cfg entries
devicetree: update documentation for fw_cfg ARM bindings
.../ABI/testing/sysfs-firmware-qemu_fw_cfg | 100 +++
Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 +-
drivers/firmware/Kconfig | 19 +
drivers/firmware/Makefile | 1 +
drivers/firmware/qemu_fw_cfg.c | 714 +++++++++++++++++++++
lib/kobject.c | 1 +
6 files changed, 837 insertions(+), 36 deletions(-)
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]
| From | "Gabriel L. Somlo" <somlo@cmu.edu> |
|---|---|
| Date | 2015-11-23 17:00 +0100 |
| Subject | [PATCH v5 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries |
| Message-ID | <qy1H4-3Pv-23@gated-at.bofh.it> |
| In reply to | #1275507 |
From: Gabriel Somlo <somlo@cmu.edu>
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") to descriptively name the
various fw_cfg "blobs" passed into the guest.
This patch attempts, on a best effort basis, to create a
directory hierarchy representing the content of fw_cfg file
names, under /sys/firmware/qemu_fw_cfg/by_name.
Upon successful creation of all directories representing the
"dirname" portion of a fw_cfg file, a symlink will be created
to represent the "basename", pointing at the appropriate
/sys/firmware/qemu_fw_cfg/by_key entry. If a file name is not
suitable for this procedure (e.g., if its basename or dirname
components collide with an already existing dirname component
or basename, respectively) the corresponding fw_cfg blob is
skipped and will remain available in sysfs only by its selector
key value.
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Cc: Andy Lutomirski <luto@amacapital.net>
---
.../ABI/testing/sysfs-firmware-qemu_fw_cfg | 42 ++++++++
drivers/firmware/qemu_fw_cfg.c | 109 ++++++++++++++++++++-
2 files changed, 148 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
index 718fbac..3823804 100644
--- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
+++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
@@ -56,3 +56,45 @@ Description:
entry via the control register, and reading a number
of bytes equal to the blob size from the data
register.
+
+ --- Listing fw_cfg blobs by file name ---
+
+ While the fw_cfg device does not impose any specific naming
+ convention on the blobs registered in the file directory,
+ QEMU developers have traditionally used path name semantics
+ to give each blob a descriptive name. For example:
+
+ "bootorder"
+ "genroms/kvmvapic.bin"
+ "etc/e820"
+ "etc/boot-fail-wait"
+ "etc/system-states"
+ "etc/table-loader"
+ "etc/acpi/rsdp"
+ "etc/acpi/tables"
+ "etc/smbios/smbios-tables"
+ "etc/smbios/smbios-anchor"
+ ...
+
+ In addition to the listing by unique selector key described
+ above, the fw_cfg sysfs driver also attempts to build a tree
+ of directories matching the path name components of fw_cfg
+ blob names, ending in symlinks to the by_key entry for each
+ "basename", as illustrated below (assume current directory is
+ /sys/firmware):
+
+ qemu_fw_cfg/by_name/bootorder -> ../by_key/38
+ qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
+ qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
+ ...
+
+ Construction of the directory tree and symlinks is done on a
+ "best-effort" basis, as there is no guarantee that components
+ of fw_cfg blob names are always "well behaved". I.e., there is
+ the possibility that a symlink (basename) will conflict with
+ a dirname component of another fw_cfg blob, in which case the
+ creation of the offending /sys/firmware/qemu_fw_cfg/by_name
+ entry will be skipped.
+
+ The authoritative list of entries will continue to be found
+ under the /sys/firmware/qemu_fw_cfg/by_key directory.
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 618304a..9ac1ca7 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -318,9 +318,103 @@ static struct bin_attribute fw_cfg_sysfs_attr_raw = {
.read = fw_cfg_sysfs_read_raw,
};
-/* kobjects representing top-level and by_key folders */
+/*
+ * Create a kset subdirectory matching each '/' delimited dirname token
+ * in 'name', starting with sysfs kset/folder 'dir'; At the end, create
+ * a symlink directed at the given 'target'.
+ * NOTE: We do this on a best-effort basis, since 'name' is not guaranteed
+ * to be a well-behaved path name. Whenever a symlink vs. kset directory
+ * name collision occurs, the kernel will issue big scary warnings while
+ * refusing to add the offending link or directory. We follow up with our
+ * own, slightly less scary error messages explaining the situation :)
+ */
+static int fw_cfg_build_symlink(struct kset *dir,
+ struct kobject *target, const char *name)
+{
+ int ret;
+ struct kset *subdir;
+ struct kobject *ko;
+ char *name_copy, *p, *tok;
+
+ if (!dir || !target || !name || !*name)
+ return -EINVAL;
+
+ /* clone a copy of name for parsing */
+ name_copy = p = kstrdup(name, GFP_KERNEL);
+ if (!name_copy)
+ return -ENOMEM;
+
+ /* create folders for each dirname token, then symlink for basename */
+ while ((tok = strsep(&p, "/")) && *tok) {
+
+ /* last (basename) token? If so, add symlink here */
+ if (!p || !*p) {
+ ret = sysfs_create_link(&dir->kobj, target, tok);
+ break;
+ }
+
+ /* does the current dir contain an item named after tok ? */
+ ko = kset_find_obj(dir, tok);
+ if (ko) {
+ /* drop reference added by kset_find_obj */
+ kobject_put(ko);
+
+ /* ko MUST be a kset - we're about to use it as one ! */
+ if (ko->ktype != dir->kobj.ktype) {
+ ret = -EINVAL;
+ break;
+ }
+
+ /* descend into already existing subdirectory */
+ dir = to_kset(ko);
+ } else {
+ /* create new subdirectory kset */
+ subdir = kzalloc(sizeof(struct kset), GFP_KERNEL);
+ if (!subdir) {
+ ret = -ENOMEM;
+ break;
+ }
+ subdir->kobj.kset = dir;
+ subdir->kobj.ktype = dir->kobj.ktype;
+ ret = kobject_set_name(&subdir->kobj, "%s", tok);
+ if (ret) {
+ kfree(subdir);
+ break;
+ }
+ ret = kset_register(subdir);
+ if (ret) {
+ kfree(subdir);
+ break;
+ }
+
+ /* descend into newly created subdirectory */
+ dir = subdir;
+ }
+ }
+
+ /* we're done with cloned copy of name */
+ kfree(name_copy);
+ return ret;
+}
+
+/* recursively unregister fw_cfg/by_name/ kset directory tree */
+static void fw_cfg_kset_unregister_recursive(struct kset *kset)
+{
+ struct kobject *k, *next;
+
+ list_for_each_entry_safe(k, next, &kset->list, entry)
+ /* all set members are ksets too, but check just in case... */
+ if (k->ktype == kset->kobj.ktype)
+ fw_cfg_kset_unregister_recursive(to_kset(k));
+
+ /* symlinks are cleanly and automatically removed with the directory */
+ kset_unregister(kset);
+}
+
+/* kobjects & kset representing top-level, by_key, and by_name folders */
static struct kobject *fw_cfg_top_ko;
static struct kobject *fw_cfg_sel_ko;
+static struct kset *fw_cfg_fname_kset;
/* register an individual fw_cfg file */
static int fw_cfg_register_file(const struct fw_cfg_file *f)
@@ -347,6 +441,9 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f)
if (err)
goto err_add_raw;
+ /* try adding "/sys/firmware/qemu_fw_cfg/by_name/" symlink */
+ fw_cfg_build_symlink(fw_cfg_fname_kset, &entry->kobj, entry->f.name);
+
/* success, add entry to global cache */
fw_cfg_sysfs_cache_enlist(entry);
return 0;
@@ -401,18 +498,21 @@ static int fw_cfg_sysfs_probe(struct platform_device *pdev)
/* NOTE: If we supported multiple fw_cfg devices, we'd first create
* a subdirectory named after e.g. pdev->id, then hang per-device
- * by_key subdirectories underneath it. However, only
+ * by_key (and by_name) subdirectories underneath it. However, only
* one fw_cfg device exist system-wide, so if one was already found
* earlier, we might as well stop here.
*/
if (fw_cfg_sel_ko)
return -EBUSY;
- /* create by_key subdirectory of /sys/firmware/qemu_fw_cfg/ */
+ /* create by_key and by_name subdirs of /sys/firmware/qemu_fw_cfg/ */
err = -ENOMEM;
fw_cfg_sel_ko = kobject_create_and_add("by_key", fw_cfg_top_ko);
if (!fw_cfg_sel_ko)
goto err_sel;
+ fw_cfg_fname_kset = kset_create_and_add("by_name", NULL, fw_cfg_top_ko);
+ if (!fw_cfg_fname_kset)
+ goto err_name;
/* initialize fw_cfg device i/o from platform data */
err = fw_cfg_do_platform_probe(pdev);
@@ -441,6 +541,8 @@ err_dir:
err_rev:
fw_cfg_io_cleanup();
err_probe:
+ fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
+err_name:
fw_cfg_kobj_cleanup(fw_cfg_sel_ko);
err_sel:
return err;
@@ -450,6 +552,7 @@ static int fw_cfg_sysfs_remove(struct platform_device *pdev)
{
pr_debug("fw_cfg: unloading.\n");
fw_cfg_sysfs_cache_cleanup();
+ fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
fw_cfg_kobj_cleanup(fw_cfg_sel_ko);
fw_cfg_io_cleanup();
return 0;
--
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] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web