From: Matt Fleming <matt.fleming@intel.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: mdroth@linux.vnet.ibm.com, rjones@redhat.com,
jordan.l.justen@intel.com, "Gabriel L. Somlo" <somlo@cmu.edu>,
qemu-devel@nongnu.org, gleb@cloudius-systems.com,
kraxel@redhat.com, pbonzini@redhat.com,
Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
Date: Wed, 15 Jul 2015 13:00:45 +0100 [thread overview]
Message-ID: <1436961645.25906.20.camel@intel.com> (raw)
In-Reply-To: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU>
On Mon, 2015-07-13 at 16:09 -0400, Gabriel L. Somlo wrote:
>
> 3. I'm currently only handling x86 and I/O ports. I could drop the
> fw_cfg_dmi_whitelist and just check the signature, using mmio where
> appropriate, but I don't have a handy-dandy set of VMs for those
> architectures on which I could test. Wondering if that's something
> we should have before I officially try to submit this to the kernel,
> or whether it could wait for a second iteration.
>
> Speaking of the kernel: My default plan is to subscribe to
> kernelnewbies@kernelnewbies.org and submit it there (this is after
> all baby's first kernel module :) but if there's a better route for
> pushing it upstream, please feel free to suggest it to me.
Congrats on your first kernel patch! Cc'ing kernelnewbies is OK but this
patches warrants a wider audience. Cc Greg Kroah-Hartman
(gregkh@linuxfoundation.org) since he polices things related to sysfs,
the x86 maintainers (x86@kernel.org), and linux-kernel@vger.kernel.org.
The closest thing we have to a Linux system firmware list is probably
linux-efi@vger.kernel.org.
By all means, mention that it's your first kernel patch when submitting
this.
Oh, you're also going to want to add documentation under
Documentation/ABI/testing/sysfs-firmware-fw_cfg as part of your patch
series.
> /* provide atomic read access to hardware fw_cfg device
> * (critical section involves potentially lengthy i/o, using mutex) */
> static DEFINE_MUTEX(fw_cfg_dev_lock);
Just a very small nitpick, but,
/*
* Multi-line comments should look like this
* in the kernel.
*/
> static int __init fw_cfg_sysfs_init(void)
> {
> int ret = 0;
> uint32_t count, i;
> char sig[FW_CFG_SIG_SIZE];
> struct fw_cfg_sysfs_entry *entry;
>
> /* only install on matching "hardware" */
> if (!dmi_check_system(fw_cfg_whitelist)) {
> pr_warn("Supported QEMU Standard PC hardware not found!\n");
> return -ENODEV;
> }
I would suggest deleting this warning because it's just noise if I build
this code into my kernel and boot it on non-qemu hardware.
> /* verify fw_cfg device signature */
> fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE);
> if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) != 0) {
> pr_warn("QEMU fw_cfg signature not found!\n");
> return -ENODEV;
> }
>
> /* create fw_cfg folder in sysfs */
> fw_cfg_kset = kset_create_and_add("fw_cfg", NULL, firmware_kobj);
> if (!fw_cfg_kset)
> return -ENOMEM;
>
> /* process fw_cfg file directory entry */
> mutex_lock(&fw_cfg_dev_lock);
> outw(FW_CFG_FILE_DIR, FW_CFG_PORT_CTL); /* select fw_cfg directory */
> insb(FW_CFG_PORT_DATA, &count, sizeof(count)); /* get file count */
> count = be32_to_cpu(count);
> /* create & register a sysfs node for each file in the directory */
> for (i = 0; i < count; i++) {
> /* allocate new entry */
> entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> if (!entry) {
> ret = -ENOMEM;
> break;
> }
>
> /* acquire file information from directory */
> insb(FW_CFG_PORT_DATA, &entry->f, sizeof(struct fw_cfg_file));
> entry->f.size = be32_to_cpu(entry->f.size);
> entry->f.select = be16_to_cpu(entry->f.select);
>
> /* register sysfs entry for this file */
> entry->kobj.kset = fw_cfg_kset;
> ret = kobject_init_and_add(&entry->kobj,
> &fw_cfg_sysfs_entry_ktype, NULL,
> /* NOTE: '/' represented as '!' */
> "%s", entry->f.name);
> if (ret)
> break;
If you take this error path, aren't you leaking 'entry'? It isn't yet on
the 'fw_cfg_entry_cache' list and so won't be freed in
fw_cfg_sysfs_cache_cleanup().
next prev parent reply other threads:[~2015-07-15 12:00 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 20:09 [Qemu-devel] RFC: guest-side retrieval of fw_cfg file Gabriel L. Somlo
2015-07-13 23:03 ` Eric Blake
2015-07-14 17:00 ` Gabriel L. Somlo
2015-07-15 11:06 ` Matt Fleming
2015-07-15 11:15 ` Laszlo Ersek
2015-07-14 9:43 ` Richard W.M. Jones
2015-07-14 18:23 ` Gabriel L. Somlo
2015-07-14 18:31 ` Gabriel L. Somlo
2015-07-14 18:48 ` Richard W.M. Jones
2015-07-14 18:51 ` Richard W.M. Jones
2015-07-14 19:16 ` Peter Maydell
2015-07-14 19:24 ` Gabriel L. Somlo
2015-07-14 19:24 ` Gerd Hoffmann
2015-07-16 0:43 ` Gabriel L. Somlo
2015-07-16 19:27 ` Eric Blake
2015-07-16 20:42 ` Gabriel L. Somlo
2015-07-14 11:38 ` Laszlo Ersek
2015-07-15 12:00 ` Matt Fleming [this message]
2015-07-20 21:19 ` Gabriel L. Somlo
2015-07-20 22:07 ` Laszlo Ersek
2015-07-25 23:21 ` Gabriel L. Somlo
2015-07-26 9:37 ` Laszlo Ersek
2015-07-15 14:08 ` Michael S. Tsirkin
2015-07-15 16:01 ` Igor Mammedov
2015-07-15 16:24 ` Michael S. Tsirkin
2015-07-16 1:21 ` Gabriel L. Somlo
2015-07-16 6:57 ` Igor Mammedov
2015-07-16 7:30 ` Michael S. Tsirkin
2015-07-16 9:50 ` Igor Mammedov
2015-07-16 10:25 ` Michael S. Tsirkin
2015-07-16 11:15 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1436961645.25906.20.camel@intel.com \
--to=matt.fleming@intel.com \
--cc=gleb@cloudius-systems.com \
--cc=gsomlo@gmail.com \
--cc=jordan.l.justen@intel.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=somlo@cmu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).