From patchwork Tue Feb 23 13:47:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Gabriel L. Somlo" X-Patchwork-Id: 8391631 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1DB3D9F372 for ; Tue, 23 Feb 2016 13:48:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 29956202EB for ; Tue, 23 Feb 2016 13:47:59 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11C8E2026D for ; Tue, 23 Feb 2016 13:47:58 +0000 (UTC) Received: from localhost ([::1]:57278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYDJl-0007on-Hp for patchwork-qemu-devel@patchwork.kernel.org; Tue, 23 Feb 2016 08:47:57 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYDJc-0007oR-NE for qemu-devel@nongnu.org; Tue, 23 Feb 2016 08:47:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYDJZ-0008Hf-Fy for qemu-devel@nongnu.org; Tue, 23 Feb 2016 08:47:48 -0500 Received: from smtp.andrew.cmu.edu ([128.2.157.39]:55330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYDJZ-0008HQ-Bf for qemu-devel@nongnu.org; Tue, 23 Feb 2016 08:47:45 -0500 Received: from HEDWIG.INI.CMU.EDU (HEDWIG.INI.CMU.EDU [128.2.16.51]) (user=somlo mech=LOGIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id u1NDl0cA020779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Feb 2016 08:47:02 -0500 Date: Tue, 23 Feb 2016 08:47:00 -0500 From: "Gabriel L. Somlo" To: "Michael S. Tsirkin" Message-ID: <20160223134700.GL16357@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160223070541-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: 2015.1.29.4820 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, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 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, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 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% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.39 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 128.2.157.39 Cc: mark.rutland@arm.com, peter.maydell@linaro.org, matt@codeblueprint.co.uk, stefanha@gmail.com, qemu-devel@nongnu.org, eric@anholt.net, kraxel@redhat.com, linux-api@vger.kernel.org, agross@codeaurora.org, pawel.moll@arm.com, zajec5@gmail.com, rmk+kernel@arm.linux.org.uk, lersek@redhat.com, devicetree@vger.kernel.org, ehabkost@redhat.com, arnd@arndb.de, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, leif.lindholm@linaro.org, robh+dt@kernel.org, pbonzini@redhat.com, rth@twiddle.net, ard.biesheuvel@linaro.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, luto@amacapital.net, hanjun.guo@linaro.org, sudeep.holla@arm.com, imammedo@redhat.com, revol@free.fr Subject: Re: [Qemu-devel] [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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): /* clean up fw_cfg device i/o */ I wouldn't particularly *mind* doing that, but I'd still like to hear from other QEMU devs on whether it's really necessary. > > > > (I even had a prototype version doing what you suggested, but per the above > > > > reference decided to drop it -- which IMHO is for the better, since otherwise > > > > I'd have had to ifdef between ACPI and non-ACPI versions of the driver -- > > > > see https://lkml.org/lkml/2015/11/4/534 ) > > > > > > I'm not sure why you have these ifdefs - they are on the host, are they > > > not? > > > > Think of those as "pseudocode" ifdefs, they're there to distinguish > > between AML that would be generated on MMIO vs. IOPORT systems > > (specifically, arm vs. x86, respectively) > > > > Some of the AML is the same, but obviously the _CRS, and > > OperationRegion + Field are different, and I wanted to point that out > > somehow :) > > > > Cheers, > > --Gabriel > > You can do ifs as well. Yeah, but the AML is generated from arch-specific locations in QEMU, so we'd be doing MMIO-only from e.g. hw/arm/virt-acpi-build.c, and IOPORT-only from hw/i386/acpi-build.c, etc. I wouldnt need to write a generic AML blob with 'if' statements and insert it the same way on all architectures, or would I ? Not sure what the best practice would be for that :) Speaking of AML, if we were to implement a "RDBL" (read-blob) method for fw_cfg in AML, and call it from the guest-side kernel module, we'll never be able to make it use DMA on ACPI systems. The way fw_cfg_read_blob is written now, we could patch that in at some later point. So that's an argument in favor of *at most* wrapping acpi_os_acquire_mutex() around the current fw_cfg_read_blob, rather than including an acpi-specific version implemented on top of an AML call. Thanks, --Gabriel 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 }