From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY5CV-00082w-1A for qemu-devel@nongnu.org; Tue, 23 Feb 2016 00:07:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY5CR-0006UZ-RZ for qemu-devel@nongnu.org; Tue, 23 Feb 2016 00:07:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY5CR-0006UT-KL for qemu-devel@nongnu.org; Tue, 23 Feb 2016 00:07:51 -0500 Date: Tue, 23 Feb 2016 07:07:36 +0200 From: "Michael S. Tsirkin" Message-ID: <20160223070541-mutt-send-email-mst@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160222202623.GI16357@HEDWIG.INI.CMU.EDU> Subject: Re: [Qemu-devel] [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" 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 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? > > > (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. -- MST