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


Groups > linux.kernel > #1275507 > unrolled thread

[PATCH v5 0/4] SysFS driver for QEMU fw_cfg device

Started by"Gabriel L. Somlo" <somlo@cmu.edu>
First post2015-11-23 17:00 +0100
Last post2015-11-23 17:00 +0100
Articles 2 — 1 participant

Back to article view | Back to linux.kernel


Contents

  [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

#1275507 — [PATCH v5 0/4] SysFS driver for QEMU fw_cfg device

From"Gabriel L. Somlo" <somlo@cmu.edu>
Date2015-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]


#1275508 — [PATCH v5 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries

From"Gabriel L. Somlo" <somlo@cmu.edu>
Date2015-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