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:

quoted

On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:

quoted

quoted

quoted

+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?

quoted

quoted

(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