From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753286AbcBXAD7 (ORCPT ); Tue, 23 Feb 2016 19:03:59 -0500 Received: from SMTP.ANDREW.CMU.EDU ([128.2.157.38]:42822 "EHLO smtp.andrew.cmu.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbcBXAD5 (ORCPT ); Tue, 23 Feb 2016 19:03:57 -0500 Date: Tue, 23 Feb 2016 19:03:13 -0500 From: "Gabriel L. Somlo" To: "Michael S. Tsirkin" Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, arnd@arndb.de, lersek@redhat.com, ralf@linux-mips.org, rmk+kernel@arm.linux.org.uk, eric@anholt.net, hanjun.guo@linaro.org, zajec5@gmail.com, sudeep.holla@arm.com, agross@codeaurora.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, qemu-devel@nongnu.org, imammedo@redhat.com, peter.maydell@linaro.org, leif.lindholm@linaro.org, ard.biesheuvel@linaro.org, pbonzini@redhat.com, kraxel@redhat.com, ehabkost@redhat.com, luto@amacapital.net, stefanha@gmail.com, revol@free.fr, matt@codeblueprint.co.uk, rth@twiddle.net Subject: Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device Message-ID: <20160224000313.GO16357@HEDWIG.INI.CMU.EDU> References: <1453990994-17801-1-git-send-email-somlo@cmu.edu> <1453990994-17801-2-git-send-email-somlo@cmu.edu> <20160221100557-mutt-send-email-mst@redhat.com> <20160221130614.GA4511@GLSMBP.INI.CMU.EDU> <20160222220756-mutt-send-email-mst@redhat.com> <20160222202623.GI16357@HEDWIG.INI.CMU.EDU> <20160223070541-mutt-send-email-mst@redhat.com> <20160223134700.GL16357@HEDWIG.INI.CMU.EDU> <20160223160555-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160223160555-mutt-send-email-mst@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.23.235416 X-SMTP-Spam-Clean: 8% ( MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 8% Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 23, 2016 at 04:14:46PM +0200, Michael S. Tsirkin wrote: > On Tue, Feb 23, 2016 at 08:47:00AM -0500, Gabriel L. Somlo wrote: > > On Tue, Feb 23, 2016 at 07:07:36AM +0200, Michael S. Tsirkin wrote: > > > On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wrote: > > > > On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote: > > > > > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote: > > > > > > > > +static void fw_cfg_io_cleanup(void) > > > > > > > > +{ > > > > > > > > + if (fw_cfg_is_mmio) { > > > > > > > > + iounmap(fw_cfg_dev_base); > > > > > > > > + release_mem_region(fw_cfg_p_base, fw_cfg_p_size); > > > > > > > > + } else { > > > > > > > > + ioport_unmap(fw_cfg_dev_base); > > > > > > > > + release_region(fw_cfg_p_base, fw_cfg_p_size); > > > > > > > > + } > > > > > > > > +} > > > > > > > > + > > > > > > > > +/* arch-specific ctrl & data register offsets are not available in ACPI, DT */ > > > > > > > > > > > > > > So for all arches which support ACPI, I think this driver > > > > > > > should just rely on ACPI. > > > > > > > > > > > > There was a discussion about that a few versions ago, and IIRC the > > > > > > conclusion was not to expect the firmware to contend for fw_cfg access > > > > > > after the guest kernel boots: > > > > > > > > > > > > https://lkml.org/lkml/2015/10/5/283 > > > > > > > > > > > > > > > > So it looks like NVDIMM at least wants to pass label data to guest - > > > > > for which fw cfg might be a reasonable choice. > > > > > > > > > > I suspect things changed - fw cfg used to be very slow but we now have > > > > > DMA interface which makes it useful for a range of applications. > > > > > > Comment on this? I'm really worried we'll release linux > > > without a way to access fw cfg from aml. > > > How about taking acpi lock around all accesses? > > > > You mean something like this (haven't tried compiling it yet, so it > > might be a bit more complicated, but just for the purpose of this > > conversation): > > > > diff --git a/drivers/firmware/qemu_fw_cfg.c > > b/drivers/firmware/qemu_fw_cfg.c > > index fedbff5..3462a2c 100644 > > --- a/drivers/firmware/qemu_fw_cfg.c > > +++ b/drivers/firmware/qemu_fw_cfg.c > > @@ -77,12 +77,18 @@ static inline u16 fw_cfg_sel_endianness(u16 key) > > static inline void fw_cfg_read_blob(u16 key, > > void *buf, loff_t pos, size_t > > count) > > { > > +#ifdef CONFIG_ACPI > > + acpi_os_acquire_mutex(acpi_gbl_osi_mutex, ACPI_WAIT_FOREVER); > > +#endif > > mutex_lock(&fw_cfg_dev_lock); > > iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl); > > while (pos-- > 0) > > ioread8(fw_cfg_reg_data); > > ioread8_rep(fw_cfg_reg_data, buf, count); > > mutex_unlock(&fw_cfg_dev_lock); > > +#ifdef CONFIG_ACPI > > + acpi_os_release_mutex(acpi_gbl_osi_mutex); > > +#endif > > } > > > > /* clean up fw_cfg device i/o */ > > Fundamentally yes. > > > I wouldn't particularly *mind* doing that, but I'd still like to hear > > from other QEMU devs on whether it's really necessary. > > It seems like a prudent thing to do IMHO, before this > goes out to users. > > [...] > > On balance, I think locking ACPI solves most problems so > if we just do that, I think what you did here is fine. Only trouble is, acpi_gbl_osi_mutex seems to be "private" to the acpi subsystem, and I'm not sure how well a patch to allow some random module to lock/unlock ACPI at its convenience would be received... So unless I'm missing something obvious (wouldn't be the first time), I think we're back to where *if* we *have* to do this [*], providing an AML blob-reader method in ACPI and punting to it from the guest-side kernel module (via #ifdef CONFIG_ACPI) would be the less painful alternative. [*] that is, mutual exclusion between kernel and firmware regarding fw_cfg is (back) on the table, for real this time... It would be good to know that it's the new consensus among QEMU folks, since I have a strong feeling I'd no longer be "Keeping It Simple" by moving in this direction. Thanks, --Gabriel