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