lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160222202623.GI16357@HEDWIG.INI.CMU.EDU>
Date:	Mon, 22 Feb 2016 15:26:23 -0500
From:	"Gabriel L. Somlo" <somlo@....edu>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	gregkh@...uxfoundation.org, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, arnd@...db.de, lersek@...hat.com,
	ralf@...ux-mips.org, rmk+kernel@....linux.org.uk, eric@...olt.net,
	hanjun.guo@...aro.org, zajec5@...il.com, sudeep.holla@....com,
	agross@...eaurora.org, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	qemu-devel@...gnu.org, imammedo@...hat.com,
	peter.maydell@...aro.org, leif.lindholm@...aro.org,
	ard.biesheuvel@...aro.org, pbonzini@...hat.com, kraxel@...hat.com,
	ehabkost@...hat.com, luto@...capital.net, stefanha@...il.com,
	revol@...e.fr, matt@...eblueprint.co.uk, rth@...ddle.net
Subject: Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's
 fw_cfg device

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.
> 
> > (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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ